GMP: IBM mainframe build results

[Tim Van Holder]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool.config
Type: application/xml
Size: 7639 bytes
Desc: not available
Url : http://gmplib.org/list-archives/gmp-bugs/attachments/20070713/ec64f447/attachment-0001.rdf