Re: GMP: IBM mainframe build results

[Ralf Wildenhues]

* 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?

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

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

Well, yes, that was sort of what I was trying to say:

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.  ;-)

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

OK, this should be fixed in a newer Libtool release.

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

Hope that helps.

Cheers, and thanks,
Ralf