Re: support for SunPRO C/C++ on Linux

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Wed, May 10, 2006 at 09:34:42PM CEST:
> 
> > > +         if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; 
> > > then
> >
> > If that LC_ALL=C was really necessary, then that is a bug.
> 
> It may not be necessary within the context of a configure script. I put it
> there because I tested the English output only, not the Japanese or Chinese
> or Thai one... Had forgotten that autoconf already disables i18n.

Ah, ok.  That settles this then, thanks.

> > Any reason not to simplify this to something like this?
> >         case `$CC -V 2>&1 >/dev/null` in
> >         *Sun\ C*)
> 
> Yes. HP-UX /bin/sh is known to dump core in
> 
>           case `command that produces more than 1 KB of output` in
> 
> and I don't know how much output other compilers generate when given the -V
> option.

They might generate a lot: IBM compilers dump their 100KB worth of help
on an unknown option or other issues -- this really bloats config.log
output a lot (maybe we should think of limiting that in Autoconf..).

But say, why is that HP-UX shell issue not listed in the Autoconf
portability section?  FWIW, I can't reproduce it on some HP-UX systems;
the oldest I have access to is an HP-UX 10.20.  It'd be good to know
about the impact of this -- do you have pointers to bug reports?  (Also
note that the shell selection algorithm of Autoconf-2.59c will select
/usr/bin/posix/sh there.)

> > > +         _LT_AC_TAGVAR(whole_archive_flag_spec,
> > > $1)='${wl}--whole-archive`new_convenience=; for conv in
> > > +$convenience\"\"; do test -z \"$conv\" ||
> > > new_convenience=\"$new_convenience,$conv\"; done; $echo
> > > \"$new_convenience\"`+${wl}--no-whole-archive'
> >
> > Are you sure the compiler driver won't reorder arguments here?
> 
> I used this backquoted glue-with-commas construct precisely because the
> compiler driver did reorder the arguments. Earlier I used
> 
>     ${wl}--whole-archive$convenience ${wl}--no-whole-archive
> 
> which had the effect of passing to the compiler driver flags like
> 
>     -Wl,--whole-archive .libs/libfoo.a .libs/libbar.a -Wl,--no-whole-archive
> 
> and the compiler driver passed these options to the linker:
> 
>     --whole-archive --no-whole-archive .... .libs/libfoo.a .libs/libbar.a
> 
> The patch I submitted now passes to the compiler driver flags
> 
>     -Wl,--whole-archive,.libs/libfoo.a,.libs/libbar.a -Wl,--no-whole-archive
> 
> and the linker gets these options:
> 
>     --whole-archive .libs/libfoo.a .libs/libbar.a --no-whole-archive
> 
> So in general this should make --whole-archive actually work.

IIRC, on Solaris, this:
| _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract`for conv in 
$convenience\"\"; do test -n \"$conv\" && 
new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` 
${wl}-z ${wl}defaultextract'

caused some problems somewhere; cf. for example this thread:
http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00040.html
and note that with C++, your patch sets ${wl} to `-Qoption ld ' as well,
not to `-Wl,'.

Also, consider this: in a (maybe partially) static linking case, the
objects from the convenience archive require some symbol from a library
specified later.  If the driver reorders, we may be out of luck here, as
the needed library may happen to end up listed earlier.  OTOH, the
driver on Solaris knows '-z allextract' and understands what to do with
the following arguments.  So that had a chance of actually working
across Solaris versions (the driver happens to also reorder differently
across versions).

Now, if the driver understands --whole-archive/--no-whole-archive on
GNU/Linux, I think that should be used plainly, without ${wl}.  If it
doesn't, then, depending on how it reorders, we should file a bug
report.

> The only drawback of this approach is if no other object file is used, i.e.
> the whole contents to be linked is inside --whole-archive, the compiler driver
> refuses to do the link because it complains about no object files to link.
> I don't know if it is a real use-case of libtool;

Yes, that is a real problem for some packages out there that just
combine a bunch of convenience archives to some larger shared library.

> if so, probably a fix could
> be to add $convenience at the end of whole_archive_flag_spec, so that the
> compiler sees the libraries too. (The linker would then see them twice, the
> first time with --whole-archive, the second time without. That should be ok,
> I hope?)

Ouch, that seems quite expensive. I don't currently know about a problem
with your suggested workaround, but I've been suggesting users to add a
dummy object instead (or just not wrap all objects into convenience
archives).  BTW, letting libtool add a dummy object itself is very
tricky to do right, so I prefer to avoid that.

(This problem was also fixed on Solaris by the approach described above.)

> > only the CVS HEAD
> > Libtool testsuite exposes the known failures fully.
> 
> Do you have two test cases, one for a whole library plus some other objects,
> and one for two libraries and no other objects?

Yes; and for each language.  See tests/convenience.at.

> > Related question:
> > are you volunteering for the forward-port of the patch?  (If not, I can
> > do it, but it'll take longer then.)
> 
> No. Generally I submit patches relative to the latest release. Everything
> beyond that is IMO the maintainer's job.

Fine with me.  I'll only apply when both patches are done though, in
order to maintain sanity.

> (I hope that this attitude will
> convince some people to make releases more frequently ;-)).

Oh, sure.

> > Do you happen to know whether Sun changed their minds and offered this
> > compiler suite for free (as in beer) now?  So that I could integrate it
> > into testing..
> 
> Yes, it is available for download

Thanks for the hint!

Cheers,
Ralf