[Top][All Lists]
[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/