Re: GMP: IBM mainframe build results

[Ralf Wildenhues]

Hello Tim,

* Tim Van Holder wrote on Fri, Jul 13, 2007 at 10:49:06AM CEST:
> [cc'ing the libtool list because of the issues marked [LIBTOOL] below;

Thanks.

> these may or may not already be resolved in more recent libtools - the
> version included with gmp is 1.5.6 according to ltmain.sh (1.220.2.94)]
> 
> I just finished building gmp 4.2.1 under OpenMVS ("370-ibm-openedition",
> the Unixy subsystem of z/OS). [...]

> - [LIBTOOL?] there is no separate linker executable, and
>   configure/libtool don't handle this case ('no acceptable LD found in
>   path'), so configure needs to be told LD is $CC (or $CXX if the C++
>   wrappers are needed). Not a big deal, but it would be nice if this
>   test would fall back on $CC if no separate linker is found.

The failure is useful in that it exposes if libtool is unable to find
the right linker on other systems.  The change could make the failure
silent, leading to weird followup issues later on.

> - [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

also the depmode configure has settled on.  Thanks.

> - 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'.  :-/

> - OpenMVS has no obstacks, so the obstack-related functionality in
>   printf is disabled, which is fine. However, so much of the ob*.c
>   sources is #ifdef'ed out that the compilation unit ends up being empty
>   (only config.h is included, and that has only preprocessor stuff).
>   This causes a warning, which due to the required -Werror-like
>   behaviour (see above) stops the build. Simply moving the stdarg/vararg
>   #includes out of the obstack-available test makes things compile
>   smoothly.

You could add a dummy symbol, or exclude the file from compilation when
it's not needed (AC_LIBOBJ comes handy, or Automake conditionals).

> - [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.

> - [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)?

I'd be interested in EBCDIC-related failures of current Libtool on this
host.

Cheers,
Ralf