On Tue, 29 Apr 2003, Rich Gray wrote:

> Hi Curl people,
>
> Some of our systems were still running a patched curl 6.5.2, so updating
> them all was long overdue.

Hi Rich, it has been a while since your last "portability-craze", but I
always enjoy and appreciate your reports and hard work on them.

> I got all twelve of our Unix platforms to compile, despite that fact that
> some of them are very ancient.

I consider this a huge success.

> A summary of all platforms is below, followed by some detail on systems
> where there were glitches, FYI. On a couple, the test stuff did not build.

Right. The test suite is a lot less portable than curl and libcurl. It is
usually not a problem.

> I went on a very long wild goose chase on our DG-UX system (the oldest,
> slowest, out of disk system.) Finally figured out that instead of
> ./configure, I had to invoke configure as
> /absolutepathtocurl-7.10.4/configure! Very strange.

Gosh. I can see how it took you a while before you tried that... :-)

> All all builds were run --disable-shared. Running strip on the resulting
> binaries produced significant, if not HUGE reductions in size on various
> platforms. Several platforms compiled a 1.5ish meg curl which strip took
> down to a few hundred k. Couldn't find a configure switch for stripping,
> despite the fact that configure seemed to look for it. I just did it
> manually, no big deal. Does seem like a --strip would be in order,
> defaulted to do so. --disable-strip would provide current behavior.
> (IIRC, on the systems I'm familiar with, the -s linker switch means strip,
> even if there is not a strip program.)

configure detects the command and sets up for use in the 'make install-strip'
target, which exists and does the same as 'make install' but runs strip on
the executable too. That's why it doesn't happen when you just build curl.

> On the subject of configure switches, I dug around for quite a while before
> re-discovering the list of switches is in configure, displayed with
> -h/--help. Might I suggest adding mention of that at the top of
> docs/INSTALL so that builders can review the entire list before proceding.

I added this yesterday after I first read your mail, and that's why it
appears on the web version now (which is using the CVS version of the
docs/INSTALL file).

> Lastly, am I doing this the hard way? I compiled on each system by copying
> over the tar file, extracting it, configure & make. Could I put the sources
> on a shared file system then on each target system, cd to an empty
> directory and /pathtosharedcurldir/configure --disable-shared? Does it
> automatically figure out --srcdir? I never "install" curl, just do the
> make and grab src/curl.

You can build curl in a separate dir, re-using the same shared source dir
each time, yes. The configure script detects the source dir itself and uses
it accordingly.

> rs6000-ibm-aix3.2.5 :-/ Had to add sys/select.h to multi.h
> as previously discussed on this list.

I've forgot about this one. I'll fix.

> BTW, I could not vi configure on this system due to the length of line 475,
> ac_subst_vars='<*LOTS* OF STUFF>'. Had to break it on another system to be
> able to edit it on the DG-UX box.

Argh. That line is entirely generated by autoconf. I figure a bug report
should be sent off their way.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf