GMP: IBM mainframe build results
Tim Van Holder
tim.vanholder at anubex.com
Fri Jul 13 16:11:43 CEST 2007
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7639 bytes
Desc: not available
Url : http://gmplib.org/list-archives/gmp-bugs/attachments/20070713/ec64f447/attachment-0001.rdf
More information about the gmp-bugs