Ralf Wildenhues wrote: >> - [LIBTOOL] by default, the compilers require that files come last on >> the command line, and many versions of libtool (including the one >> included with GMP) break this rule when configure has determined -c >> and -o can both be used (it puts the -o last). To work around this, >> the envvar _CC/C89/CXX_CCMODE needs to be set to 1. > > This we can probably fix. Please post > ./libtool --config
Attached as libtool.config. > also the depmode configure has settled on. Thanks. No depmode - the compiler has no -M option or equivalent, which is a serious PITA when trying to fix portability issues (change a header and you're forced to make clean to make sure you catch all clients of that header - and when a compile takes hours, that's not fun). >> - I didn't build the C++ wrappers, but because they use the .cc >> extension, the _CXX_CXXSUFFIX envvar would need to be set to "cc" to >> succeed (by default, the compiler only accepts foo.C as a C++ source). > > Yuck. MSVC needs .cpp, so to avoid having to set this, Autoconf would > need a further test for $ac_ext in the C++ case. Also, it's not > feasible to expect that user code change their file names on the fly, so > I assume that since your compiler can be taught (by _CXX_CXXSUFFIX) it > is better to stick with '.cpp'. :-/ As far as I can tell, autoconf makes no attempt to detect the extension at all - what's worse, the extension it tries seems to be version-dependent; for gmp and libxml2 it uses .cc for its conftest files (so I had set $_CXX_CXXSUFFIX in my .profile to make the problem go away), but I'm trying to configure libiconv now, where autoconf uses .cpp. I suppose this is really an autoconf failing - it should perhaps try cc, cpp and C and use whichever the compiler accepts. In any case, this was a remark solely intended for GMP's platform notes; the user can be reasonably expected to set the envvar appropriately. >> - [LIBTOOL] MAJOR: The system 'ar' does not store paths, only basenames, >> and during the (piecewise) link of libgmp.la, multiple files with the >> same basename are given to ar, resulting in messages like: >> ar: FSUM9942 "mpn/mul.o" ignored, same basename as "mpq/mul.o". >> I made a little script that copied all relevant objects to a single >> directory (replacing / by _ so I got files like mpf_fits_sint.o) in >> order to easily (re)create a complete libgmp.a. >> I would consider this a libtool bug; adding the same file (or files >> with the same basename) to a library multiple times works fine as long >> as it is not in a single invocation of ar. So perhaps the libtool >> configury should detect this issue and avoid including multiple files >> with the same basename during piecewise linking. > > This has most definitely seen bugfixing since 1.5.6. We'd be interested > in issues occurring with 1.5.24 or CVS HEAD here. OK - but since I don't have autotools set up, I can't easily update the libtool in use by GMP (and since it would take >10 hours for me to get a result if I did, I'm not that inclined to try either). If a future version of GMP uses such a newer libtool, and I have cause to build that on OpenMVS, I'll let you know what I get though. >> - [LIBTOOL] During installation, the "libraries have been installed in" >> message is shown, but the shell's print builtin (used in $echo) shows >> an error for the line of dashes: >> print: ./libtool 6200: FSUM6241 Unknown option "--" >> print: ./libtool 6200: Usage: print [-nprRsu[n]] [arg ...] >> Preceding the string with -- makes this go away ($echo -- "--..."). > > Again, seeing the exact libtool config would help here. What shell is > the one chosen as $SHELL (ksh version? Use 'set -o emacs; CTRL-v' to > find out version string)? There is only the One True IBM Shell /bin/sh - it has pretty decent ksh/bash-like features though. CTRL-V is out of the question - input is from a z/OS prompt that is fed to the shell, so such characters don't get through. "ident /bin/sh" suggests it's a build from around March 2003, if that matters. > I'd be interested in EBCDIC-related failures of current Libtool on this > host. libtool didn't seem to have any EBCDIC issues - at least not as part of this build. I haven't tried to configure/build/check libtool itself.
libtool.config
Description: application/xml
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
