GMP: IBM mainframe build results

[Tim Van Holder]

Ralf Wildenhues wrote:
> * Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST:
>> 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.
> 
> Thanks.  I needed to think a bit more about this.  If I understand you
> correctly, then the failure occurs at 'make' time rather than at
> 'configure' time, right?  And it's the linking steps of *programs* that
> fail rather than compilation (with -c; automake always puts the source
> file last when compiling), and neither the generation of libraries,
> because you only generate static ones with ar.  Right?

Both compiles and links are affected.

For the linking, automake puts the -o at the end itself, so it is
at least partially to blame. Then again, libtool does already move
the -o to a place before the list of libraries, so it could just as
easily move it before the object file name too.

For the compilation, the relevant bit in ltmain.sh is (line 989 in the
first ltmain.sh that comes to hand):

      if test "$pic_mode" != yes; then
	# Don't build PIC code
	command="$base_compile $qsrcfile"
      else
	command="$base_compile $qsrcfile $pic_flag"
      fi
      if test "$compiler_c_o" = yes; then
	command="$command -o $obj"
      fi

If this is changed to

      command=$base_compile
      if test "$pic_mode" = yes; then
	command="$base_compile $pic_flag"
      fi
      if test "$compiler_c_o" = yes; then
	command="$command -o $obj"
      fi
      command="$command $qsrcfile"

I believe that it will retain its current functionality while also
guaranteeing the source file comes last. Currently, even without -c -o
being able to be used together, it would still put -fPIC or whatever at
the end -- not an issue for OpenMVS (no PIC flag detected), but it could
cause similar invocation troubles on some other host.

> Could you post an actual of this failing command, including commands
> that generated it, if any?

These are from libiconv, not GMP, but that shouldn't matter.

Linking:

/bin/sh ../libtool --mode=link /bin/c89  iconv_no_i18n.o
../srclib/libicrt.a ../lib/libiconv.la -o iconv_no_i18n
mkdir .libs
chmod 777 .libs
/bin/c89 iconv_no_i18n.o -o iconv_no_i18n  ../srclib/libicrt.a
../lib/.libs/libiconv.a
FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p,
.I, or .a), or a corresponding data set name, instead of -o.

Compiling:

/bin/sh ../libtool --mode=compile /bin/c89 -I. -I. -I.. -I./..
-I../include -g -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED
-DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
-DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\"
-DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
-Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./relocatable.c
 /bin/c89 -I. -I. -I.. -I./.. -I../include -g -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED -DLIBDIR=\"/usr/local/lib\"
-DBUILDING_LIBCHARSET -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY
-DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC
-Dset_relocation_prefix=libcharset_set_relocation_prefix
-Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./relocatable.c -o
relocatable.o
FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p,
.I, or .a), or a corresponding data set name, instead of -o.

>>> 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).
> 
> Well you can enable trying the slow dependency extractors with
>    ./configure --enable-dependency-tracking
> 
> then also things like makedepend or "parsing" preprocessor output (by
> the depcomp script) will be tried.

I can try - but things are very slow as they are, and I'm loathe to
introduce even more slowdown. Still, it would help for packages where I
need to do nontrivial porting work. Thanks.

> Autoconf changed from '.cc' to '.cpp' exactly because nobody could
> report a compiler that failed with '.cpp', but there was a report that
> MSVC would mess up with '.cc'.  It's your report now that made me (at
> least) aware of a compiler that needed '.cc'.  The fact that you have a
> compiler that understands only '.cc' should be reported to bug-autoconf.
> (I assume the above is long-winded for violent agreement.  ;-)

It is (and the compiler by default works for neither .cc nor .cpp - it
needs .C). I'll file a report with autoconf when I have time; my current
workaround is viable so it's not a blocking issue.

>>>> - [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:
> [...]
>>> 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.
> 
> One thing you can do that's more time-efficient is to download
> libtool-1.5.24, build it, go back to your gmp build tree where
> everything is already built that's needed for libgmp.la, enter
> the directory where libgmp.la is created and
>   env LIBTOOL=/path/to/libtool-1.5.24-build/libtool make -e libgmp.la
> 
> (Bourne shell notation) which should work.

I'll try that when I can fit it in.