On Fri, 13 Aug 1999 00:07:10 +0100, Duncan Simpson wrote:
>
>Arnd Hanses posted:
><stuff snipped, current subject GNU autoconf>
>>
>> Provided, box isn't too modern. New vendor patches (or new glibc) break
>> configure tests, 'till someone is so kind as to provide the fix (which
>> in turn breaks other tests, elsewhere, etc.)
>>
>Sort of strange... I have used linux since 0.99pl13, libc 4 (the old a.out
>days). I now used linux 2.2.x, glibc 2.1 (ELF) and gcc 2.95 and autoconf has
>never failed
I saw problems with types, when several math functions changed (random;
rand; rand48; etc.).
> yet except precisely once due to a bash difference.
Should it depend on this? Normally you'll use a native ksh or csh, no
bash.
>My fixed
Yes, many people did a great work to fix all those many problems.
>version worked on both the old and new bash. The complete list of upgrades and
>changes is beyond any number of vendor patches.
Don't underestimate brain damaged vendors.... (sgi is a nice example)
>Autoconf generated scripts
>handled all these changes with no remaking or fixing.
>
>> Well, at least here they told me:
>>
>> Never even think about gcc or auto*xy on (not so good) old sgi
>> xl-8 (irix), ibm rs6000/580 (aix), hp 9000/755 (hp-ux), or even on
>> stone-age cd 4360 (ep/ix). At least there, you're stuck with native
>> compilers.
>>
>Contary to popular rumor configure scripts can use native compilers and even
>work using acc (Solaris' *very strict* ANSI compliler). These doom sayers are
>basically completely and utterly out of touch with reality and wrong.
Note, especially the sgi above is a notorious probblem: Under constant
'technical renovation' and kind o' playground for vendor's patch
kindergarden... Their monopolistic 'power compiler' will always reject
'non-scalable' code, or what they believe it is and they don't seem to
believe in scalability of configure tests.
>In
>reality tedious effort has been made to make autoconf compatible with all the
>brain damage out there and works fine on all the systems you cite and even
>with acc (before acc breaks the build process by insisting that foo.cc is not
>C++, due to unique and apparently unfixable acc brain damage).
Certainly.
>> >The cygnus cygwin stuff supports configure that works 100%. no suprise.
><lots more snipped>
>>Well, they are the maintainers and have an commercial interest, to sell
>>their cygwin; no surprise.
>>
>I think this was actually to mimise their headaches, as cygnus tools use GNU
>autoconf. While they might sell you cygwin stuff on a CD the tools are
>actually GPL and you can download them free (modulo disc space, bandwidth
>costs, etc).
>Some of the GNUPro stuff may be more commercial, although I know some of the
>major components are free software (GPL or otherwise).
Headache was here: They strictly rejected all those great efforts to
make autoconf work correctly on OS/2-emx. They prefer selling their win
products...
>
>I have personally downloaded and installed the full version free. It beats the
>hell out of attempting to use M$'s supposedly BSD compatible sockets, which
>dies on a *most* code (including code not using the dark corners). As for the
>direness and lack of features of nmake do not inquire.
Severely lacking is still dmake (very popular among scientific programs
and on OS/2) support and support for non-Bourne compatible shells (note
that 'imake' in contrast works here) in autoconf.
Greets,
Arnd
