bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [2.2.7a] (patch) runtime-linking and soname-equivalent together on A


From: Michael Haubenwallner
Subject: Re: [2.2.7a] (patch) runtime-linking and soname-equivalent together on AIX
Date: Mon, 08 Dec 2008 23:19:41 +0100

Hi Ralf,

On Mon, 2008-12-08 at 08:10 +0100, Ralf Wildenhues wrote:

> I have a number of questions; reordering your mail:

I'll answer them piecewise as I get time to (unfortunately I expect new
patches to grow within the next 2-3 months)

> > +   _LT_TAGVAR(lt_prog_compiler_shared_as_static, $1)='${wl}-bstatic'
> > +   _LT_TAGVAR(lt_prog_compiler_shared_as_shared, $1)='${wl}-bdynamic'
> 
> What is the semantic difference between these switches and this proposal
> <http://thread.gmane.org/gmane.comp.gnu.libtool.patches/6727/focus=6730>?
> If the difference is too small, we should apply the other patch first
> and adjust your patch accordingly, no?

Haven't seen this thread before. Agreed, it is related, but it depends
on how the per-deplib-flags would interfere with -static-libtool-libs
and -static, as - unlike other platforms - the '-bstatic' flag allows
(and is necessary when not -static) to statically link a shared-only
library.
So the search for a statically-linkable library would need to know that
shared-only libraries can match too when '$shared_as_static' is set.

> The patch is quite large, it would be nice if it were possible to split
> it logically.
> 
> I still haven't grasped whether, and if, how, this patch creates a flag
> day for Libtool users on AIX.

> More generally, why does your
> patch mix the two (more or less) unrelated items of changing the
> default, and changing the semantics of shared items in static libs?

I'll look if it is even possible to physically split the patch into the
soname- and the rtldefault-thing, to make it easier to identify (and
avoid) the need for a flag day.

> Thanks also for doing all the testing.  Out of curiosity, have you
> tested or are you able to test AIX 4.3.3?  (I can do so otherwise.)

I can search more hard for an aix4.* inside my company, but I don't
expect to really find a useable one any more. And we don't have 6.1 yet.

> Generally, it would be nice to have somebody with good AIX experience
> comment on this.

Of course. See also:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=171833&tstart=15
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=230222&tstart=0

> A couple of nits inline.

Will fix them when it is time for new patches.

> > +   test "$#" -lt 1 || shift
> 
> What is this line for?  The '-lt 1' looks wrong, maybe -le, or
>   test $# -gt 1 && shift

Good catch - strange, why didn't hit me that?

> > +         # AIX can link 'shared objects' statically:
> > +         test "$use_static_libs" != no &&
> > +           test "$use_static_libs" != all &&
> > +           test -n "$link_shared_as_static_flag" &&

> (several instances).  Also, the logic seems quite redundant, with
> several repetitions.

Yes, but how best to reduce the redundant tests? New function, some
variable?

> > +#ifdef RTLD_MEMBER
> > +  if (filename && strchr(filename, '(') && strchr(filename, ')'))
> 
> Sure you don't want to start looking for the closing parenthesis _after_
> the position of the opening one?

Have thought on that and not found worth the effort, because setting
RTLD_MEMBER does not require but allow for loading an archive member.
Eventually, we could set RTLD_MEMBER even unconditionally on AIX.
And when the name is wrong, let dlopen complain.

> > +   # We add -bnortllib after $compiler_flags, because we might have
> > +   # inherited -brtl from $LDFLAGS or $inherited_linker_flags, which

> I'm not so sure whether letting users inherit flags is such a great
> idea.  It would be more elegant to be able to do without.

You specifically mean $inherited_linker_flags here?
Agreed, am unsure too, need to rethink.

> > +   cmds="${cmds}"'~test "x${allow_undefined}" = "xno" || undefs=`dump -Tv 
> > ${output_objdir}/${soname} | $SED -n '"'"'s/.* EXTref  *\.\.  *\([[^ ]]*\) 
> > *$/ \${wl}-u\1/p'"'"' | \$NL2SP`'
> 
> We shouldn't use 'dump' unadorned like this.  No idea whether there are
> cross compiling setups where $host is AIX but $build is not, but for
> them, this should be factorized.

Have thought on that, but then found 'dump' being used to find the
aix_libpath already, and left it alone.

> > --- a/tests/lt_dladvise.at
> > +++ b/tests/lt_dladvise.at
> > @@ -318,8 +318,9 @@ dlpreloadable='preload'
> >  # are reporting not able to accept the global hint to lt_dlopenadvise().   
> >  #
> >  # 
> > ------------------------------------------------------------------------- #
> >  
> > -case $host_os in
> > -cygwin* | mingw* | cegcc*)
> > +eval `$LIBTOOL --config | grep '^allow_undefined_flag=`
> > +case $host_os:$allow_undefined_flag in
> > +cygwin* | mingw* | cegcc* | *:unsupported)
> >    # These hosts do not support linking without -no-undefined
> >    CPPFLAGS="$CPPFLAGS -DHAVE_UNDEFINED_SYMBOLS=0"
> >    ;;
> 
> Doesn't this fix a bug already?  If yes, then this can be applied as a
> separate patch.

Maybe yes - just haven't found another platform (any more?) that
actually configures to allow_undefined_flag=unsupported.
Why don't cygwin/mingw/cegcc do so?

Thank you!

So far,
/haubi/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]