Re: Linking just some static

[Ralf Wildenhues]

* Jan Engelhardt wrote on Tue, Feb 17, 2009 at 12:56:39AM CET:
> On Monday 2009-02-16 19:56, Ralf Wildenhues wrote:
> >
> >
> >Can you try out the patch, and report back?
> 
> It works, but does not yet deal with some cases.
> 
> My first try was:
> 
>   p1_LDADD = -Bstatic libours.la -Bdynamic libtheirs.la
> 
> automake then responded:
> 
>   Makefile.am:11: linker flags such as `-Bstatic' belong in `p1_LDFLAGS'

This needs fixing in Automake, of course.  This belongs in *LDADD.

> I had naturally added -Bstatic to p1_LDADD because that is where all
> the libraries are. Moving it to p1_LDFLAGS means that I give up
> part of the dependency tracking — `make p1` will then not built
> libours.la beforehand.

Exactly.

> The other issue is that since -Bstatic is passed verbatim down to ld,
> I get an error:

>   /bin/sh ./libtool  --tag=CC   --mode=link gcc -Wall -g -O2
>   -Bstatic libours.la -Bdynamic libtheirs.la  -o p1 p1.o  
> 
>   libtool: link: gcc -Wall -g -O2 -o .libs/p1 p1.o   -Wl,-Bstatic
>   ./.libs/libours.a /usr/lib/libHX.so -ldl -Wl,-Bdynamic ./.libs/libtheirs.so 
> 
>   /usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/bin/ld:
>   attempted static link of dynamic object `/usr/lib/libHX.so'
> 
> The (simplified) Makefile goes like:
> 
>   libours_la_LIBADD = -lHX
>   p1_LDFLAGS = -Bstatic libours.la -Bdynamic libtheirs.la
> 
> [libHX is a library for which I do not have a static .a version installed.]

> What I had in mind though was not what libtool currently does
> (namely, passing -Bstatic/dynamic to the linker verbatim), but something
> more along the lines of the libtool "-static" flag, that is, the
> linker to be called with
> 
>   gcc -Wall -g -O2 -o .libs/p1 p1.o .libs/libours.a /usr/lib/libHX.so
>   -ldl .libs/libtheirs.so

OK so I guess the patch still has a bug in that it may require, not only
prefer, static libraries with -Bstatic.

There was some discussion over whether "require" or "prefer" semantics
were desirable in the referenced thread, and there is no general
consensus on which meaning to implement (or whether to try and go for
both).

So it's back to the drawing and testing board for the patch.  One of
the problems is that
- for the "prefer one type of library but not the other" we might have
  to drop the switches for libraries which don't match,
- for the "require one type of library" we might have to test library
  types on systems where we didn't really care about it before (AIX).
  And we might have to use different switches (HP-UX, which has four
  switches for prefer/require static/shared).
  

Sigh.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Linking just some static

[Jan Engelhardt]

On Monday 2009-02-23 10:45, Ralf Wildenhues wrote:
>[...]
>So it's back to the drawing and testing board for the patch.  One of
>the problems is that
>- for the "prefer one type of library but not the other" we might have
>  to drop the switches for libraries which don't match,
>- for the "require one type of library" we might have to test library
>  types on systems where we didn't really care about it before (AIX).
>  And we might have to use different switches (HP-UX, which has four
>  switches for prefer/require static/shared).
>  

I do believe my request is not really related to ld,
but much more so with libtool.

libfoo_la_LIBADD = -lm
p1_LDADD = -static-deepness=1 libfoo.la -static-deepness=0 libbar.la

should yield (on a system that supports shared libs, and where such
are enabled through configure etc.etc.)

ld -o p1 libfoo.a $(source libfoo.la; echo
$dependency_libs) .libs/libbar.so

Deepness related to the dependency tree:
(level 1)   libfoo.la
(level 2)   \_ libm
(level 3)  \_ libc

"-Bstatic" would be equivalent to -static-deepness=Infty, plus
it's impractical for libtool to support -static-deepness >= 2 < Infty,
but that would be fine for me.


___
http://lists.gnu.org/mailman/listinfo/libtool

ltdl weirdness

[Matěj Týč]

Hello all,
I am using libltdl in my project and I experience some unexpected things.

First of all, if I have some undefined references in my module, the
module can't be loaded using lt_dlopen neither using its ext variant.
The reason for that is stated as "could not find the file", but this
is not the case. If I correct those undefined references, everything
statrts to work. BTW the 'dltest' tool had helped me, although it is a
pity that it doesn't support loading symbols from executables that
would load the module.

Next, if the executable is compiled with -export-dynamic, things that
were compiled in really provide symbols that would be missing in the
module. However, things that were linked in as external libs don't
seem to be exported. Is this expected behaviour? However, there is a
difference between having nothing and between having linked external
symbols in executable compiled using -export-dynamic flag -- the first
case results in the inability to open the module (see the first
problem), whereas the latter results in runtime error.
Any suggestions regarding good practices?
Regards,
Matej


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: ltdl weirdness

[Bob Friesenhahn]

On Mon, 23 Feb 2009, Matj  Tý wrote:


Hello all,
I am using libltdl in my project and I experience some unexpected things.

First of all, if I have some undefined references in my module, the
module can't be loaded using lt_dlopen neither using its ext variant.
The reason for that is stated as "could not find the file", but this
is not the case. If I correct those undefined references, everything
statrts to work. BTW the 'dltest' tool had helped me, although it is a
pity that it doesn't support loading symbols from executables that
would load the module.


This bug was reported quite some time ago and is not yet corrected. 
It is due to an incorrect overwrite of the error message by the module 
"preopen" code.



Next, if the executable is compiled with -export-dynamic, things that
were compiled in really provide symbols that would be missing in the
module. However, things that were linked in as external libs don't
seem to be exported. Is this expected behaviour? However, there is a


Yes, this is now the expected behavior.  Older libltdl allowed 
libraries required by loaded modules and module symbols to become part 
of the global namespace.  As of libtool 2.2.X, this is no longer the 
default. Libltdl is designed to be a module loader rather than a 
shared library loader.



difference between having nothing and between having linked external
symbols in executable compiled using -export-dynamic flag -- the first
case results in the inability to open the module (see the first
problem), whereas the latter results in runtime error.
Any suggestions regarding good practices?


It is necessary for all symbols to be already available in the using 
program or library, or referenced by the module as a dependency, when 
the module is loaded.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
http://lists.gnu.org/mailman/listinfo/libtool

Re: cmdline_wrap.at

[Tim Rice]

Hi Ralf,

On Sat, 21 Feb 2009, Ralf Wildenhues wrote:

> Hi Tim,
> 
> * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
> > 
> > I'm trying to understand the cmdline_wrap.at test.
> > I've added this patch to fix the 2 template tests that were failing
> > on UnixWare 7.1.4
> 
> Can you post the verbose output of the test both without and with the
> patch?  Thanks.
>   gmake check-local TESTSUITEFLAGS='-k "simple template test" -v -d -x'

Sure, attched as x.tst-without-patch & x.tst-with-patch
I've also attached the curent patch I'm using as uw-template.patch
It's just a s/CXX/CC/ of the old one.

> > so now the only failure is the "low max_cmd_len" test.
> 
> OK, cool.
> 
> > I guess I don't really know what cmdline_wrap.at is trying to acomplish.
> > And I'm puzzled why the "simple template test" fails inside cmdline_wrap
> > but not outside of it.
> 
> Well, it tries to simulate a very long command line, so long that its
> expansion by libtool will exceed the kernel command line length limit.
> It does this by setting the limit very low, which libtool internally
> compares against.  So then the wrapping code branches are exercised,
> which create intermediate libraries or objects.
> 
> How long is the actual command line length limit on your system?
> If it is >1MB or unlimited, then this is unlikely to ever be a problem
> in practice, and you can ignore the failure.  But some systems have
> pretty low limits.

On my system it is 131072 but it is a kernel tunable and the default
out of the box is 32k.
 
> The test case tries to re-run all kinds of other tests in our testsuite
> (exactly those that only exercise the $LIBTOOL script), for best
> possible code coverage.
> 
> The output of the failing/passing of the test above may help analyze the
> failure of the cmdline_wrap test.

John Wolfe was looking at this too (using 2.2.6) and here is what
he had to say
--
I know why test 73 (small command line) test fails on #62 (C++
templates).  

   - one of the link lines (second) linking against a .la, gets
broken up and .o's are collected in a relocatable object using.
 
 /bin/ld -r

 Ergo the problem, the prelink phase is skipped.  It is not a
problem with the archive being built, since $AR can accumulate
object files, 1 file at a time.
 So the CC -Tprelink_objects is accomplished as expected  - just
before the $AR.
 The prelinker command echo can be seen in the log.

 For shared objects, what is needed is to get a CC -Tprelink_objects
done on the libobjs before they are added to the relocatable object.

 The /bin/ld cannot be replaced with $CC since the C++ compiler
driver will link in startup modules also.  Soon get a multiple
defined symbol.
--

Thanks.

> 
> Thanks!
> Ralf
> 

-- 
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net--- libltdl/m4/libtool.m4.old   2009-02-18 18:54:38.0 -0800
+++ libltdl/m4/libtool.m4   2009-02-22 20:54:26.786787091 -0800
@@ -6219,6 +6219,8 @@
   CC*)
_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib 
$libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G 
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs 
$compiler_flags'
+   _LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
+   $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
;;
  *)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib 
$libobjs $deplibs $compiler_flags'
abs_srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd /home2/src/gnu/libtool-2.x && 
pwd`; cd tests; \
CONFIG_SHELL="/bin/ksh" /bin/ksh $abs_srcdir/tests/testsuite \
  MAKE="gmake" CC="cc" CFLAGS="-g" CPP="cc -E" CPPFLAGS="" LD="/usr/bin/ld" 
LDFLAGS="" LIBS="" LN_S="ln -s" NM="/usr/bin/nm -p" RANLIB=":" STRIP="strip" 
lt_INSTALL="/home2/src/gnu/libtool-2.x/libltdl/config/install-sh -c" OBJEXT="o" 
EXEEXT="" SHELL="/bin/ksh" CONFIG_SHELL="/bin/ksh" CXX="CC" CXXFLAGS="-g" 
CXXCPP="CC -E" F77="" FFLAGS="" FC="" FCFLAGS="" GCJ="" GCJFLAGS="-g -O2" 
_lt_pkgdatadir="/home2/src/gnu/libtool-2.x" 
LIBTOOLIZE="/usr/local/src/gnu/libtool-2.x/libtoolize" 
LIBTOOL="/usr/local/src/gnu/libtool-2.x/libtool" 
tst_aclocaldir="/home2/src/gnu/libtool-2.x/libltdl/m4" -k "simple template 
test" -v -d -x
## -- ##
## libtool 2.2.7a test suite. ##
## -- ##
73. template.at:27: testing ...
/home2/src/gnu/libtool-2.x/tests/template.at:28: { test -n "$CXX" && test 
"X$CXX" != Xno; } || (exit 77)
+ test -n CC
+ test XCC != Xno
/home2/src/gnu/libtool-2.x/tests/template.at:28: test "X$CXX" != Xg++ || (g++ 
-v >/dev/null 2>&1) || (exit 77)
+ test XCC != Xg++
+ cat
+ 1> aclib.h 0<<
+ cat
+ 1> aclib.cpp 0<<
+ cat
+ 1> alib.h 0<<
+ cat
+ 1> alib.cpp 0<<
+ cat
+ 1> prog.cpp 0<<
/home2/src/gnu/libtool-2.x/tests/template.at:79: $LIBTOOL --tag=CXX 
--mod