Re: Disable --whole-archive when using convenience archives

[Ralf Wildenhues]

[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/10586 ]

Hello Alon,

* Alon Bar-Lev wrote on Mon, Mar 22, 2010 at 08:00:19PM CET:
> It is find if you don't want to solve this, but please acknowledge
> that you don't.

> So far I did not get any response regarding this issue.

I'm really sorry I dropped the ball on this for so long.

> >> /bin/sh ./libtool --tag=CC   --mode=link i686-w64-mingw32-gcc
> >> -prefer-pic -g -O2  -rpath /usr/local/lib -static  -o liba.la
> >> liba_la-a.lo
> >> libtool: link: warning: undefined symbols not allowed in
> >> i686-w64-mingw32 shared libraries
> >> libtool: link: i686-w64-mingw32-ar cru .libs/liba.a  liba_la-a.o
> >> libtool: link: i686-w64-mingw32-ranlib .libs/liba.a
> >> libtool: link: ( cd ".libs" && rm -f "liba.la" && ln -s "../liba.la" 
> >> "liba.la" )
> >> /bin/sh ./libtool --tag=CC   --mode=link i686-w64-mingw32-gcc  -g -O2
> >> -module -shared -avoid-version -no-undefined -export-symbols
> >> ./libb.exports  -o libb.la -rpath /usr/local/lib b.lo liba.la
> >>
> >> *** Warning: This system can not link to static lib archive liba.la.
> >> *** I have the capability to make that library automatically link in when
> >> *** you link to this library.  But I can only do this if you have a
> >> *** shared version of the library, which you do not appear to have.
> >> *** But as you try to build a module library, libtool will still create
> >> *** a static module, that should work as long as the dlopening application
> >> *** is linked with the -dlopen flag to resolve symbols at runtime.
> >> libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o
> >> libtool: link: i686-w64-mingw32-ranlib .libs/libb.a
> >> libtool: link: ( cd ".libs" && rm -f "libb.la" && ln -s "../libb.la" 
> >> "libb.la" )
> >> make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool'

I can reproduce this issue with your example tarball, thanks.  At a
glance it looks like a libtool bug to me, but I'm not sure what would be
the right thing to do (without setting deplib check to pass_all for
mingw).

Thanks,
Ralf


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

Re: link-time optimization

[Ralf Wildenhues]

Hello Simon, Török, Åke,

* Simon Richter wrote on Wed, Mar 24, 2010 at 12:11:13PM CET:
> I'm trying to use link time optimization with gcc 4.5, which somewhat
> works :), but requires the compiler flags to be passed to the linking
> step as well. libtool however removes them from the command line.

Let's address three reports in one go.

I'm still working on a patch to support -flto in libtool, it needs
changes in several places.

> Is there any harm in passing them to the linking step?

Yes.  Let me answer with a patch to add a FAQ and FAQ entry.
OK to commit?

Thanks,
Ralf

Add FAQ, and FAQ entry for flags stripped at library link time.

* doc/libtool.texi (FAQ, Stripped link flags): New nodes.
(Wrapper executables): Replace bug address with macro.
(Compile mode, Link mode): Document `-Wc,' and `-Xcompiler '
semantics better.
* libltdl/config/ltmain.m4sh (func_mode_link): Rewrite comment
for the flags that are passed through.
Prompted by reports from Simon Richter ,
Török Edwin  and
Åke Sandgren .

diff --git a/doc/libtool.texi b/doc/libtool.texi
index f07eaf2..f0dd24b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -95,6 +95,7 @@ version @value{VERSION}.
 * Dlopened modules::@code{dlopen}ing libtool-created libraries.
 * Using libltdl::   Libtool's portable @code{dlopen} wrapper 
library.
 * Trace interface:: Libtool's trace interface.
+* FAQ:: Frequently Asked Questions
 * Troubleshooting:: When libtool doesn't work as advertised.
 * Maintaining:: Information used by the libtool maintainer.
 * GNU Free Documentation License:: License for this manual.
@@ -186,6 +187,10 @@ Using libltdl
 * Module loaders for libltdl::  Creating user defined module loaders.
 * Distributing libltdl::How to distribute libltdl with your package.
 
+Frequently Asked Questions
+
+* Stripped link flags:: Dropped flags when creating a library
+
 Troubleshooting
 
 * Libtool test suite::  Libtool's self-tests.
@@ -886,7 +891,7 @@ employ command line options that begin with @code{--lt-}. 
(In fact, the
 wrapper executable will detect any command line options that begin with
 @code{--lt-} and abort with an error message if the option is not
 recognized). If this presents a problem, please contact the Libtool
-team at @email{bug-libtool@@gnu.org}.
+team at @value{BUGADDR}.
 
 These command line options include:
 
@@ -1414,7 +1419,9 @@ linking.
 
 @item -Wc,@var{flag}
 @itemx -Xcompiler @var{flag}
-Pass a flag directly to the compiler.
+Pass a flag directly to the compiler.  With @code{-Wc,}, multiple flags
+may be separated by commas, whereas @code{-Xcompiler } passes through
+commas unchanged.
 @end table
 
 @node Link mode
@@ -1602,7 +1609,9 @@ supplies the same interface (@pxref{Linking with dlopened 
modules}).
 
 @item -Wc,@var{flag}
 @itemx -Xcompiler @var{flag}
-Pass a linker-specific flag directly to the compiler.
+Pass a linker-specific flag directly to the compiler.  With @code{-Wc,},
+multiple flags may be separated by commas, whereas @code{-Xcompiler }
+passes through commas unchanged.
 
 @item -Wl,@var{flag}
 @itemx -Xlinker @var{flag}
@@ -4946,6 +4955,46 @@ autoconf --trace 'LT_SUPPORTED_TAG:$1'
 @end defmac
 
 
+...@node FAQ
+...@chapter Frequently Asked Questions about libtool
+
+This chapter covers some questions that often come up on the mailing
+lists.
+
+...@menu
+* Stripped link flags:: Dropped flags when creating a library
+...@end menu
+
+...@node Stripped link flags
+...@section Why does libtool strip link flags when creating a library?
+
+When creating a shared library, but not when compiling or creating
+a program, @command{libtool} drops some flags from the command line
+provided by the user.  This is done because flags unknown to
+...@command{libtool} may interfere with library creation or require
+additional support from @command{libtool}, and because omitting
+flags is usually the conservative choice for a successful build.
+
+If you encounter flags that you think are useful to pass, as a
+work-around you can prepend flags with @code{-Wc,} or @code{-Xcompiler }
+to allow them to be passed through to the compiler driver
+(@pxref{Link mode}).  Another possibility is to add flags already
+to the compiler command at @command{configure} run time:
+
+...@example
+./configure CC='gcc -m64'
+...@end example
+
+If you think @command{libtool} should let some flag through by default,
+here's how you can test such an inclusion: grab the Libtool development
+tree, edit the @file{ltmain.m4sh} file in the @file{libltdl/config}
+subdirectory to pass through the flag (search for @samp{Flags to be
+passed through}), re-bootstrap and build with the flags in question
+added to @code{LDFLAGS}, @code{CFLAGS}, @code{CXXFLAGS}, etc. on the
+...@command{configure} command line as appropriate.  Run the testsuite
+as described in the @file{README} file and rep

Re: Libtool breaks linking order

[Ralf Wildenhues]

Hello Guillaume,

* Guillaume Rousse wrote on Mon, Mar 29, 2010 at 03:00:01PM CEST:
> When building nfs-utils, I have a strange linking order issue with
> libtool (2.2.6b).
> 
> The makefile.am reads:
> gssd_LDADD =../../support/nfs/libnfs.a \
>   $(RPCSECGSS_LIBS) $(GSSGLUE_LIBS) $(KRBLIBS)
> 
> (Full file available at
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/Makefile.am;h=95a2bd0f8c6cc21247d71549680b04a52f01772e;hb=HEAD)
> 
> Note than $(GSSGLUE_LIBS) appears before $(KRBLIBS).
> 
> With the following values:
> GSSGLUE_LIBS = -lgssglue -ldl
> KRBLIBS = -L/usr/lib64 -O2 -g -pipe -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> -fstack-protector-all -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv
> -ldl
> 
> libtool is invocated correctly:
> /bin/sh ../../libtool --tag=CC   --mode=link gcc -Wall
> -Wstrict-prototypes  -pipe -O2 -g -pipe -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> -fstack-protector-all  -I/usr/include/gssglue-O2 -g -pipe -Wformat
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
> --param=ssp-buffer-size=4 -fstack-protector-all  -Wl,--as-needed
> -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -o svcgssd svcgssd-context.o
> svcgssd-context_mit.o svcgssd-context_heimdal.o svcgssd-context_lucid.o
> svcgssd-context_spkm3.o svcgssd-gss_util.o svcgssd-gss_oids.o
> svcgssd-err_util.o svcgssd-svcgssd.o svcgssd-svcgssd_main_loop.o
> svcgssd-svcgssd_mech2file.o svcgssd-svcgssd_proc.o
> ../../support/nfs/libnfs.a  -lgssglue -ldl   -lnfsidmap -L/usr/lib64 -O2
> -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all
> -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -ltirpc
> 
> Note than -lgssglue comes before -lgssapi_krb5.
> 
> However, libtool changes this to
> libtool: link: gcc -Wall -Wstrict-prototypes -pipe -O2 -g -pipe -Wformat
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
> --param=ssp-buffer-size=4 -fstack-protector-all -I/usr/include/gssglue
> -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all
> -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-O1 -o svcgssd
> svcgssd-context.o svcgssd-context_mit.o svcgssd-context_heimdal.o
> svcgssd-context_lucid.o svcgssd-context_spkm3.o svcgssd-gss_util.o
> svcgssd-gss_oids.o svcgssd-err_util.o svcgssd-svcgssd.o
> svcgssd-svcgssd_main_loop.o svcgssd-svcgssd_mech2file.o
> svcgssd-svcgssd_proc.o -O2 -g -pipe -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> -fstack-protector-all ../../support/nfs/libnfs.a
> /usr/lib64/libnfsidmap.so -L/usr/lib64 -lgssapi_krb5 -lkrb5 -lk5crypto
> -lcom_err -lresolv /usr/lib64/libtirpc.so -lnsl /usr/lib64/libgssglue.so
> -ldl -lpthread
> 
> Note than -lgssglue has been turned into /usr/lib64/libgssglue.so, and
> moved after -lgssapi_krb5, which wasn't modified. From --debug output
> (attached), this behaviour difference seems to be caused the the
> presence of a .la file for libgssglue.so, and not for libgssapi_krb5.
> 
> All in all, it breaks resulting binary, because libgssglue should be
> linked before libgssapi_krb5, as both contains the same symbol with
> incompatible ABI, and only the one from libgssglue should be used.
> 
> See this discussion for details:
> http://linux-nfs.org/pipermail/nfsv4/2010-March/012201.html

The problem comes from /usr/lib64/libtirpc.la
It lists gssglue as deplib.

If you were linking statically, then it might be necessary to list
libgssglue.a after libtirp.a.  This is what libtool can know from the
.la files, and the reason for libtool to list gssglue after libtirp.  It
cannot know from the .la files that you are playing dirty unportable (to
non-ELF systems) tricks with symbols in gssglue overriding symbols from
gssapi_krb5.

One workaround would be to (temporarily) remove /usr/lib64/libtirpc.la.
Another one would be to add libgssapi_krb5 to the deplibs of libtirpc
(but I don't know how well that fits the model of these libraries).

Hope that helps.

Cheers,
Ralf


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

Re: link-time optimization

[Ralf Wildenhues]

Hello Simon,

* Simon Richter wrote on Mon, Mar 29, 2010 at 01:12:08PM CEST:
> On Sun, Mar 28, 2010 at 05:33:44PM +0200, Ralf Wildenhues wrote:
> 
> > * doc/libtool.texi (FAQ, Stripped link flags): New nodes.
> > (Wrapper executables): Replace bug address with macro.
> > (Compile mode, Link mode): Document `-Wc,' and `-Xcompiler '
> > semantics better.
> 
> Hmm, -Wc is difficult to use because the compiler does not handle it --
> hence I cannot pass it to the configure script. Manually patching
> config.status to use "-Wc,-flto" works fine though (this is a project
> where all building goes through libtool, so it's possible).

The patch also documents that you can use CC='gcc -flto' as an
alternative workaround.  Besides, I am working on proper -flto
support in libtool so you don't have to use either workaround.

If that wasn't clear from my previous message, please help me
rewrite the patch so that it becomes crystal clear.

Thanks,
Ralf


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

Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

Hello gcc and libtool lists,

Summary: both Autoconf-generated configure tests as well as some Libtool
construct invoke undefined behavior.  Question is how to deal with it,
and whether GCC, as QoI, may want to define behavior in these cases.


1) Autoconf-generated configure tests often fake the prototype of some
function; e.g., AC_CHECK_FUNC([func]) uses
  char func();

and tries to link that.  Using this is undefined according to C99, if
func has a different actual prototype, and when all system libraries are
LTO'ed, gcc -flto may even detect this kind of inconsistency and could
act accordingly (nasal demons and such).


2) libtool has a feature that makes it extract symbol lists from
objects and turn them into fake declarations and function/object
pointers: fake static preloaded modules.

It currently works by running nm or a similar tool over the object, then
converting the output with a couple of sed script or so
(global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
synthesized extra source file that then contains code like this:

extern int func();
extern char variable;

typedef struct {
  const char *name;
  void *address;
} lt_dlsymlist;

extern const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[];
const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{  { "@PROGRAM@", (void *) 0 },
  {"func", (void *) &func},
  {"variable", (void *) &variable},
  {0, (void *) 0}
};

This is invoking undefined behavior in a couple of respects:

a) Pointers to functions are stored in pointer-to-void variables.
This could be fixed with an incompatible API change to using a union of
object and function pointer, I guess.

b) The symbols 'func' and 'variable' likely have the wrong prototypes,
i.e., elsewhere, they might be declared as

  void func(int, double);
  double variable[42];

instead.  I haven't come across any actual issues with this yet, except
now LTO may rightfully complain about it.


Question is, what can we do about this?  We could ensure to never pass
-flto or -fwhopr to the compilation of the libtool symfile object, and
remove it from some or all link tests done in configure.  That's ugly.
Would that even be sufficient though?  Conversely, would GCC developers
be willing to agree that, when GCC detects such inconsistencies, it
wouldn't take adverse advantage of it (e.g., by turning off LTO in this
case, or similar)?

Other possibilities for Autoconf would be to work toward a new set of
checking macros (or extensions of current one) where the configure.ac
author passes a full prototype for each function to check (Autoconf
could keep a list of known prototypes for often-checked functions).
I'm not sure how to fix the libtool symfile in a C99-conforming way.

Thanks for reading this far.

Cheers,
Ralf


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

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

* Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
> On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
> > 1) Autoconf-generated configure tests often fake the prototype of some
> > function; e.g., AC_CHECK_FUNC([func]) uses
> >  char func();
> >
> > and tries to link that.  Using this is undefined according to C99, if
> > func has a different actual prototype, and when all system libraries are
> > LTO'ed, gcc -flto may even detect this kind of inconsistency and could
> > act accordingly (nasal demons and such).
> 
> I suppose autoconf cannot do this for C++ functions then, because
> of mangling issues?

Correct.  For C++ libraries, it is more typical to just write a complete
test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.

FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
declarations given by the user (in order to support overloaded
basename, for example).

> Note that the only thing GCC with LTO might do here is to issue
> a diagnostic (which of course might confuse the configure script),
> but we cannot really reject such programs (as such errors are
> unfortunately very common) and thus defer any problems to
> link- and/or runtime.

That's almost exactly the kind of semantics I would like to see.
Can we get this documented in the manual?  Something like this.
Note that it would explicitly contradict one of the design goals
listed in lto.pdf, which is that conflicting declarations might
provoke an error; so really GCC developers should make a conscious
design decision here.


* doc/invoke.texi (Optimize Options): Document that LTO
won't remove object access purely due to incompatible
declarations.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2226cad..85f9c5f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7294,6 +7294,12 @@ regular (non-LTO) compilation.  This means that if your 
build process
 was mixing languages before, all you need to add is @option{-flto} to
 all the compile and link commands.
 
+If LTO encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to ISO C99 6.2.7), it might produce a warning, but
+this fact alone will not cause an access to an object to be optimized
+away.
+
 If object files containing GIMPLE bytecode are stored in a library
 archive, say @file{libfoo.a}, it is possible to extract and use them
 in an LTO link if you are using @command{gold} as the linker (which,


(In practice, Autoconf does not support -Werror at configure time; this
issue only reinforces that.)

> > b) The symbols 'func' and 'variable' likely have the wrong prototypes,
> > i.e., elsewhere, they might be declared as
> >
> >  void func(int, double);
> >  double variable[42];
> >
> > instead.  I haven't come across any actual issues with this yet, except
> > now LTO may rightfully complain about it.
> 
> Same issue as above.  We try to handle it - there might be bugs
> in the current implementation of LTO though.

Bugs are no problem as long as they are acknowledged as such.  I desire
future compatibility, i.e., being fairly certain autotools don't regress
just because of a good improvement in some other tool.  Dealing with
existing cruft is abundant in autotools.

> > Question is, what can we do about this?  We could ensure to never pass
> > -flto or -fwhopr to the compilation of the libtool symfile object, and
> > remove it from some or all link tests done in configure.  That's ugly.
> > Would that even be sufficient though?  Conversely, would GCC developers
> > be willing to agree that, when GCC detects such inconsistencies, it
> > wouldn't take adverse advantage of it (e.g., by turning off LTO in this
> > case, or similar)?
> >
> > Other possibilities for Autoconf would be to work toward a new set of
> > checking macros (or extensions of current one) where the configure.ac
> > author passes a full prototype for each function to check (Autoconf
> > could keep a list of known prototypes for often-checked functions).
> > I'm not sure how to fix the libtool symfile in a C99-conforming way.
> 
> I'd say wait and see.  What would be nice to have is a few testcases
> that cover the autoconf cases in the GCC testsuite (feel free to
> just file them into bugzilla).

I have been doing just that for the failures I've found so far.  I'll
add some more for stuff that ought to work.

> We really do not want to break
> working setups with LTO - any fancy ODR violation diagnostics
> should IMHO be optional, only things that LTO does not get
> correct are currently diagnosed IIRC.

That's a good sentiment.  autotools shouldn't stand on slippery
slope more than it has to.

Thanks,
Ralf


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

how to "parse" gcc -v output

[Ralf Wildenhues]

Hello gcc and libtool lists,

Both Autoconf and Libtool have macros which "parse" output of 'gcc -v'
for some link commands.  Yes, I know, almost by definition this is not
"parseable" text, but GCC does not provide a stable API that allows to
find out
- which libraries it needs to link shared modules against, or
- which libraries are needed to let g++ link mixed C++/Fortran code,
so in practice there is no other choice (unless the user provides this
information).

In some situations, esp. when -flto is used, -v output consists of many
parts.  Libtool needs to know which parts it can drop, or needs to look
at.  Can we be fairly confident that, iff there is a line matching
  '^ [^ ].*collect'

it will pick the one line that contains the verbose driver invocation
that lets us pick up init/fini objects as well as compiler libs to link
against?  I.e., can we assume the leading space to be stable, and the
'collect2' name to be fairly stable across GCC versions and systems?
It seems to work with all versions starting from 2.95 on those systems
where collect2 is used (the 2.7.2.3 I can still find here matches
'^ [^ ].*ld ').  If we don't find such a line, then picking the first
line with a single leading space seems prudent.  That would e.g. match
linking with ld on FreeBSD.

If not, can you suggest a different approach?  Should we be using -###
instead?  Looking for the first line with leading space and containing
' -L' (I think Alexandre Oliva suggested that a while ago)?

I'm willing to add API to a future GCC if that's the only viable way
(that way at least we have a fixed set of past and present versions to
match).

Thanks,
Ralf


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

Re: link-time optimization

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sun, Mar 28, 2010 at 05:33:44PM CEST:
> 
> I'm still working on a patch to support -flto in libtool, it needs
> changes in several places.

I have a preliminary(!) patch set here for LTO support in libtool.
DO NOT submit this to your favorite distribution, it is not ready
for general consumption yet.

Several upstream issues to fix here:

- gold bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
  (common symbols not emitted with -fuse-linker-plugin)
- GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43576
  (ICE w/ partial linking)
- GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43542
  (segfault if __gnu_lto_v1 is referenced)
- gold bug http://sourceware.org/bugzilla/show_bug.cgi?id=11182
  (names in linker scripts in subdirs are relative to subdir)
- GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
  (-fwhopr ICE with TU that contains no function)

The patch set works around 43542.  You need to wait until gold has bug
42757 fixed, or use the patch from that PR, or not use (a compiler that
uses) gold for linking, because this bug causes a configure test to
fail.

Issues we need to coordinate with upstream:

- conflicting declarations in symlist files, see also
http://thread.gmane.org/gmane.comp.gcc.devel/112638 for this.

- Do not parse too much from 'gcc -shared -v' output into
postdep_objects, by grepping for the interesting line;
see also http://thread.gmane.org/gmane.comp.gcc.devel/112719 for this.

Especially the second issue will likely require a rework of the first
patch in the series.


With this patch series, using GCC + BFD ld and -flto in all compile
flags, the only test failure is 18 'duplicate convenience archive names'
due to GCC bug 43576.

Using gold instead also lets pdemo-make fail after pdemo-conf, as well as
most of the inner tests run from cmdline_wrap.at (105. Run tests with
low max_cmd_len), all due to gold bug 11182.

I'll reply (on libtool-patches@) with the actual patches.

Thanks,
Ralf


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

[PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.

[Ralf Wildenhues]

On some systems, lt_preloaded_symbols may not be declared
const due to relocation issues.  C99 requires qualification to
match for compatible declarations, so ensure we declare
const'ness in the same way everywhere; link-time optimization
may otherwise rightfully complain about inconsistencies.
Since ltdl.h may not depend upon config.h, rely on system
defines for choosing const'ness.

* NEWS: Update.
* doc/libtool.texi (Dlpreopening): Document this issue.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms):
[__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
according to system defines.  Remove old shell cruft.  Use
LT_DLSYM_CONST for lt_${my_prefix}_LTX_preloaded_symbols.
* libltdl/libltdl/lt_system.h (LT_DLSYM_CONST): Likewise,
define LT_DLSYM_CONST according to system defines.
* tests/demo/foo.h (LT_DLSYM_CONST): Likewise.
* tests/pdemo/foo.h (LT_DLSYM_CONST): Likewise.
* tests/demo/dlmain.c (lt_dlsymlist): Use LT_DLSYM_CONST.
* tests/pdemo/longer_file_name_dlmain.c (lt_dlsymlist):
Likewise.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Likewise
for configure test code.
* libltdl/ltdl.c (preloaded_symbols): Use LT_DLSYM_CONST.
* libltdl/ltdl.h (LTDL_SET_PRELOADED_SYMBOLS): Likewise.

Signed-off-by: Ralf Wildenhues 
---

Hello,

this patch addresses the const-ness of the symlist variable.

I would like things to be consistent across ltmain, libtool.m4 (where we test
symbol-pipe functionality), and ltdl.h, and since the latter can't depend on
config.h, I guess the best bet is to hard-code using system defines.

Question is whether
  *cygwin* | *mingw* | *cegcc* | *osf5*

matches
  defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
  defined(__osf__)

well enough?

OK to commit?

Thanks,
Ralf

 ChangeLog |   26 ++
 NEWS  |3 +++
 doc/libtool.texi  |3 +++
 libltdl/config/ltmain.m4sh|   33 ++---
 libltdl/libltdl/lt_system.h   |   14 +-
 libltdl/ltdl.c|2 +-
 libltdl/ltdl.h|2 +-
 libltdl/m4/libtool.m4 |   14 +-
 tests/demo/dlmain.c   |2 +-
 tests/demo/foo.h  |   14 +-
 tests/pdemo/foo.h |   14 +-
 tests/pdemo/longer_file_name_dlmain.c |2 +-
 12 files changed, 102 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c082cee..245452b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,31 @@
 2010-04-04  Ralf Wildenhues  
 
+   Uniform const'ness of symlist variable lt_preloaded_symbols.
+   On some systems, lt_preloaded_symbols may not be declared
+   const due to relocation issues.  C99 requires qualification to
+   match for compatible declarations, so ensure we declare
+   const'ness in the same way everywhere; link-time optimization
+   may otherwise rightfully complain about inconsistencies.
+   Since ltdl.h may not depend upon config.h, rely on system
+   defines for choosing const'ness.
+   * NEWS: Update.
+   * doc/libtool.texi (Dlpreopening): Document this issue.
+   * libltdl/config/ltmain.m4sh (func_generate_dlsyms):
+   [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
+   according to system defines.  Remove old shell cruft.  Use
+   LT_DLSYM_CONST for lt_${my_prefix}_LTX_preloaded_symbols.
+   * libltdl/libltdl/lt_system.h (LT_DLSYM_CONST): Likewise,
+   define LT_DLSYM_CONST according to system defines.
+   * tests/demo/foo.h (LT_DLSYM_CONST): Likewise.
+   * tests/pdemo/foo.h (LT_DLSYM_CONST): Likewise.
+   * tests/demo/dlmain.c (lt_dlsymlist): Use LT_DLSYM_CONST.
+   * tests/pdemo/longer_file_name_dlmain.c (lt_dlsymlist):
+   Likewise.
+   * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Likewise
+   for configure test code.
+   * libltdl/ltdl.c (preloaded_symbols): Use LT_DLSYM_CONST.
+   * libltdl/ltdl.h (LTDL_SET_PRELOADED_SYMBOLS): Likewise.
+
Fix incompatible struct declarations.
* doc/libtool.texi (Dlpreopening): Remove broken documentation
of lt_dlsymbol and lt_dlsymlist.  Document typedef lt_dlsymlist
diff --git a/NEWS b/NEWS
index f220f28..1ffbf74 100644
--- a/NEWS
+++ b/NEWS
@@ -27,6 +27,9 @@ New in 2.2.8 2010-??-??: git version 2.2.7a, Libtool team:
 options that begin with '--lt-*' from the argument list before launching
 (uninstalled) programs. Any '--lt-*' option on the command line not
 recognized by the wrapper will result in an error.
+  - The type of the symbol lists variables (lt_*_LTX_preloaded_symbols) has
+been fixed in the manual and in a couple of tests to match the actual
+implementation.
 
 * Changes in supported systems or compilers:
 
diff --git a/doc/libtool.texi b/doc/li

[PATCH 4/4] Add $pic_flag to archive_cmds and archive_expsym_cmds.

[Ralf Wildenhues]

* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)

[GNU ld, netbsd]: Add $pic_flag if ELF.
[GNU ld, solaris]: Likewise.
[GNU ld, default case]: Likewise.
[!GNU ld, freebsd, dragonfly]: Add $pic_flag.
[!GNU ld, GCC, hpux9]: Add $pic_flag.
[!GNU ld, GCC, hpux10]: Replace -fPIC with $pic_flag
[!GNU ld, GCC, hpux11, !hppa*64]: Replace -fPIC with $pic_flag.
[!GNU ld, GCC, irix5, irix6, nonstopux]: Add $pic_flag.
[!GNU ld, GCC, osf4, osf5]: Likewise.
[!GNU ld, GCC, solaris]: Likewise.
(_LT_LANG_CXX_CONFIG) 
[hpux9]: Add $pic_flag if $GXX.
[hpux10, hpux11, !hppa*64]: Replace -fPIC with $pic_flag.
[irix5, irix6]: Add $pic_flag if $GXX.
[osf4, osf5]: Likewise.
[solaris]: Add $pic_flag if $GXX and not GCC 2.7.

Signed-off-by: Ralf Wildenhues 
---

Hello,

This untested patch cleans up a number of hard-coded -fPIC
entries in archive_cmds and archive_expsym_cmds settings,
and adds $pic_flag to all that use GCC on ELF systems.
However, the patch may also change the link command lines
for some non-GCC compilers as well.  It needs testing.


In _LT_LANG_CXX_CONFIG, hpux10|hpux11, GXX, hppa*64* case,
the -fPIC there is probably bogus and can be removed, but
that can be another patch (and I haven't tested that either.)

Thanks,
Ralf

 ChangeLog |   20 
 libltdl/m4/libtool.m4 |   48 
 2 files changed, 44 insertions(+), 24 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 245452b..b7918e4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,25 @@
 2010-04-04  Ralf Wildenhues  
 
+   Add $pic_flag to archive_cmds and archive_expsym_cmds.
+   * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
+   
+   [GNU ld, netbsd]: Add $pic_flag if ELF.
+   [GNU ld, solaris]: Likewise.
+   [GNU ld, default case]: Likewise.
+   [!GNU ld, freebsd, dragonfly]: Add $pic_flag.
+   [!GNU ld, GCC, hpux9]: Add $pic_flag.
+   [!GNU ld, GCC, hpux10]: Replace -fPIC with $pic_flag
+   [!GNU ld, GCC, hpux11, !hppa*64]: Replace -fPIC with $pic_flag.
+   [!GNU ld, GCC, irix5, irix6, nonstopux]: Add $pic_flag.
+   [!GNU ld, GCC, osf4, osf5]: Likewise.
+   [!GNU ld, GCC, solaris]: Likewise.
+   (_LT_LANG_CXX_CONFIG) 
+   [hpux9]: Add $pic_flag if $GXX.
+   [hpux10, hpux11, !hppa*64]: Replace -fPIC with $pic_flag.
+   [irix5, irix6]: Add $pic_flag if $GXX.
+   [osf4, osf5]: Likewise.
+   [solaris]: Add $pic_flag if $GXX and not GCC 2.7.
+
Uniform const'ness of symlist variable lt_preloaded_symbols.
On some systems, lt_preloaded_symbols may not be declared
const due to relocation issues.  C99 requires qualification to
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index ef587b9..da976ba 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4534,8 +4534,8 @@ _LT_EOF
_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable $libobjs $deplibs 
$linker_flags -o $lib'
wlarc=
   else
-   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
$wl$export_symbols -o $lib'
+   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs 
$deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
$wl$export_symbols -o $lib'
   fi
   ;;
 
@@ -4553,8 +4553,8 @@ _LT_EOF
 
 _LT_EOF
   elif $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; 
then
-   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
$wl$export_symbols -o $lib'
+   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs 
$deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
$wl$export_symbols -o $lib'
   else
_LT_TAGVAR(ld_shlibs, $1)=no
   fi
@@ -4600,8 +4600,8 @@ _LT_EOF
 
 *)
   if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
-   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
$wl$export_symbols -o $lib'
+   _LT_TAGVAR(archive_cmds, $1)='

Re: how to "parse" gcc -v output

[Ralf Wildenhues]

* Joseph S. Myers wrote on Sun, Apr 04, 2010 at 11:40:19AM CEST:
> On Sun, 4 Apr 2010, Ralf Wildenhues wrote:
> 
> > - which libraries it needs to link shared modules against, or
> > - which libraries are needed to let g++ link mixed C++/Fortran code,
> > so in practice there is no other choice (unless the user provides this
> > information).
> [...]
> > I'm willing to add API to a future GCC if that's the only viable way
> > (that way at least we have a fixed set of past and present versions to
> > match).
> 
> For both of the above, at least on ELF systems, the correct thing to do is 
> to make GCC (used by any of the drivers "gcc", "g++", etc.) do the right 
> thing by default: link with the libraries required by the objects being 
> linked in, using those appropriate for shared libraries if -shared is 
> passed, and respecting options such as -static-libstdc++.  That is, make 
> the driver/collect2 combination smart enough that libtool does not need to 
> query this information.

How would g++ know that part of the objects were from Fortran sources?
Maybe from a different (non-GCC) Fortran compiler, that needs a
different set of libraries at link time?  I don't see how this
information can fully be embedded in GCC.

Also, in order to actually be able to run programs, libtool needs to
also be able to ask for paths missing in the run paths, so they can be
added to the program *if the user so desires* and if they are not in the
default run path.

Until these are available, the other information are still useful to,
and needed for, Libtool and Autoconf.

Thanks,
Ralf


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

Re: link-time optimization

[Ralf Wildenhues]

* Török Edwin wrote on Sun, Apr 04, 2010 at 06:03:35PM CEST:
> On 04/04/2010 11:54 AM, Ralf Wildenhues wrote:
> > I have a preliminary(!) patch set here for LTO support in libtool.

> Thanks a lot for the patches, they worked fine so far!

Thanks for testing.

> I'd have one more request: please add "-use-gold-plugin" to the list of
> flags passed through to support LLVM's LTO described here:
> http://llvm.org/docs/GoldPlugin.html

Yes.  I'm not sure whether I mentioned it before, but I didn't manage to
build a working llvm/clang from its svn last weekend (I tried about
three revisions and all of them failed to build with syntax errors, so I
gave up for the moment).  Do they not have a checkin policy that code
needs to compile at least?  Anyway, it's good that you did some testing
here.  Can you please also test the Libtool package with this:

> ./configure
> CC=/home/edwin/llvm2.7/llvm-gcc-4.2-2.7-x86_64-linux/bin/llvm-gcc
> CXX=/home/edwin/llvm2.7/llvm-gcc-4.2-2.7-x86_64-linux/bin/llvm-g++
> CFLAGS="-O4 -use-gold-plugin" CXXFLAGS="-O4 -use-gold-plugin"

and run its testsuites and report results (see README for how)?  Thanks.

> ac_cv_c_fpu_bigendian=no

How come you need to use that, and which Autoconf version do you use?
This sounds like it needs to be addressed in Autoconf.  Thanks.

> Everything worked fine, and make check passed too!
> (Now of course it didn't LTO the entire program because
> -fuse-linker-plugin triggers PR41584)

AFAIK -fuse-linker-plugin does not trigger PR 41584, only -fwhopr does.
Did you mean one of the other ones?

Cheers,
Ralf


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

Re: Linking specific library as static

[Ralf Wildenhues]

* Alon Bar-Lev wrote on Sun, Apr 11, 2010 at 04:56:23PM CEST:
> How can I link statically with a specific library?

Search the libtool lists for 'per-deplib static' and you will find a
proposed patch that should still mostly apply.  There were smaller
issues left to do IIRC.

Cheers,
Ralf


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

Re: libtool versioning

[Ralf Wildenhues]

Hello Jef,

* Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST:
> On 02/05/10 03:33, Bob Friesenhahn wrote:
> >On Sun, 2 May 2010, Jef Driesen wrote:
> >
> >>I'm trying to understand the libtool current:revision:age versioning scheme.
> >>I think I understand how it works, but I noticed that filename of the shared
> >>library seems to get different numbers (current-age.age.revision). Is that
> >>expected?
> >
> >The filename generation is dependent on the OS.  It is usually best
> >not to pay any attention to the filenames at all unless you are
> >switching from some other existing numbering scheme and need to avoid
> >a collision.  I keep these notes in my configure script (taken from
> >various libtool related documentation) so that I remember how things
> >work:
> 
> The reason why I found the filename confusing, is because in the
> article I was looking at, they make it look like the libtool version
> c:r:a ends up in the filename as "libfoo.so.c.r.a".
> 
> http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

I'm adding John in Cc:, he should be able to say more about this.

> I have seen this a couple of other places as well.

Like, the GNU Libtool manual?  Have you looked there?

> As a newbe to the
> libtool versionning scheme, it took me a while to figure out what
> was really going on. Very confusing.
> 
> ># Here are a set of rules to help you update your library version
> ># information:
> >#
> >#  1. Start with version information of `0:0:0' for each libtool library.
> >#  2. Update the version information only immediately before a public
> ># release of your software. More frequent updates are unnecessary, and
> ># only guarantee that the current interface number gets larger faster.
> >#  3. If the library source code has changed at all since the last update,
> ># then increment revision (`c:r:a' becomes `c:r+1:a').
> >#  4. If any interfaces have been added, removed, or changed since the last
> ># update, increment current, and set revision to 0.
> >#  5. If any interfaces have been added since the last public release, then
> ># increment age.
> >#  6. If any interfaces have been removed since the last public release,
> ># then set age to 0.
> 
> Shouldn't step #6 included "changed" as well as "removed"? If you
> change the interface (for example modifying function parameters),
> backwards compatibility is broken too. But only "removed" is listed
> here.

Well, it is listed in step 4 already.

> Personally, I think the last three steps are easier to understand
> when written as if cases, rather than steps:
> 
> 1. Interface unchanged: C:R+1:A
> 2. Interface changed in a backwards compatible way: C+1:0:A+1
> 3. Interface changed and backwards compatibility is broken: C+1:0:0

The git master version of Libtool is hopefully a bit easier to
understand, it has an alternate description added, which is similar to
yours:


Cheers,
Ralf


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

Re: libtool versioning

[Ralf Wildenhues]

Hello,

* Matěj  Týč wrote on Mon, May 03, 2010 at 05:45:26PM CEST:
> If I have understood correctly, the whole LTversion stuff has only one
> purpose - to inform users what have they installed.

Wrong.  It provides a fairly portable abstraction of different
versioning schemes implemented in different operating systems/libc's.
By definition, libtool cannot do better than what the native system
provides.  In cases where the native system provides even less than what
the libtool versioning is able to express, such as w32, it has to resort
to library renaming to get even a chance of a kind of "versioning".

Cheers,
Ralf


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

Re: libtool versioning

[Ralf Wildenhues]

* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST:
> Yes, I have read the libtool manual, but it doesn't contain much
> info about the resulting filename. Most of the info is about the
> c:r:a scheme for input, not the output.

Yes, because the output file name is a per-system detail that you should
not have to care about.

> >>>#  1. Start with version information of `0:0:0' for each libtool library.
> >>>#  2. Update the version information only immediately before a public
> >>># release of your software. More frequent updates are unnecessary, and
> >>># only guarantee that the current interface number gets larger faster.
> >>>#  3. If the library source code has changed at all since the last update,
> >>># then increment revision (`c:r:a' becomes `c:r+1:a').
> >>>#  4. If any interfaces have been added, removed, or changed since the last
> >>># update, increment current, and set revision to 0.
> >>>#  5. If any interfaces have been added since the last public release, then
> >>># increment age.
> >>>#  6. If any interfaces have been removed since the last public release,
> >>># then set age to 0.
> >>
> >>Shouldn't step #6 included "changed" as well as "removed"? If you
> >>change the interface (for example modifying function parameters),
> >>backwards compatibility is broken too. But only "removed" is listed
> >>here.
> >
> >Well, it is listed in step 4 already.
> 
> Sure, but if interfaces have been changed, but not removed, the
> algorithm stops at step #4,

Read the algorithm without any implicit stops in mind, and it will work.

Anyway, your point is good that this is hard to understand, and we've
addressed that in git master.

Cheers,
Ralf


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

Re: Rebooting the release process

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, May 04, 2010 at 09:59:16AM CEST:
>  1. Check that the current HEAD is not totally broken on any of the
>  20-some architectures I have access to.  And supply or solicit fixes
>  for any of those platforms anyone still cares about.

there is probably not even need to do that.  One thing that would be
nice to have fixed is:

- the libltdl 2.2.4(?) regression that prevents proper error messages
  for failed loading of modules.

Somebody noted (off-list) that our bootstrap leaves information specific
from the person doing a release in the resulting tarball.  Specifically,
you should not have set $GREP, $EGREP, $FGREP, $SED, and some other
variables set in the bootstrap script, to some system-specific value,
because that will make them end up in the generated libtool script as
default value (and also a couple of other scripts).  These may cause
errors for others.  This is probably a bug in the bootstrap script or in
libltdl/config/general.m4sh, I haven't analyzed.

Cheers,
Ralf


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

Re: libtool versioning

[Ralf Wildenhues]

* Peter Rosin wrote on Tue, May 04, 2010 at 10:05:37AM CEST:
> Den 2010-05-03 22:03 skrev Ralf Wildenhues:
[...]
> >>>>>#  3. If the library source code has changed at all since the last 
> >>>>>update,
> >>>>># then increment revision (`c:r:a' becomes `c:r+1:a').
> >>>>>#  4. If any interfaces have been added, removed, or changed since the 
> >>>>>last
> >>>>># update, increment current, and set revision to 0.
> >>>>>#  5. If any interfaces have been added since the last public release, 
> >>>>>then
> >>>>># increment age.
> >>>>>#  6. If any interfaces have been removed since the last public release,
> >>>>># then set age to 0.
> >>>>
> >>>>Shouldn't step #6 included "changed" as well as "removed"? If you
> >>>>change the interface (for example modifying function parameters),
> >>>>backwards compatibility is broken too. But only "removed" is listed
> >>>>here.
> >>>
> >>>Well, it is listed in step 4 already.
> >>
> >>Sure, but if interfaces have been changed, but not removed, the
> >>algorithm stops at step #4,
> >
> >Read the algorithm without any implicit stops in mind, and it will work.
> >
> >Anyway, your point is good that this is hard to understand, and we've
> >addressed that in git master.
> 
> Errrm, is that really so? I tend to agree with Jef here...

I take it that your response is to my "... it will work" sentence, not
the paragraph below that.

> The algorithm *could* be interpreted such that e.g. the interface change
> "int foo(void)" -> "int foo(int)" is an interface addition of int foo(int)
> and an interface remove of int foo(void), thus triggering both #5 and #6.
> But in that case "changed" need not be mentioned in #4 either. So, because
> "changed" is mentioned in #4, it also needs to be explicitly mentioned
> in #6.

Ah, ok.  Yes, you're right.  Feel free to commit a patch to
s/removed/& or changed/  in 6.

Thanks for perservering!
Ralf


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

Re: Rebooting the release process

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Wed, May 05, 2010 at 07:17:38AM CEST:
> On 5 May 2010, at 00:55, Ralf Wildenhues wrote:
> 
> > Somebody noted (off-list) that our bootstrap leaves information specific
> > from the person doing a release in the resulting tarball.  Specifically,
> > you should not have set $GREP, $EGREP, $FGREP, $SED, and some other
> > variables set in the bootstrap script, to some system-specific value,
> > because that will make them end up in the generated libtool script as
> > default value (and also a couple of other scripts).  These may cause
> > errors for others.  This is probably a bug in the bootstrap script or in
> > libltdl/config/general.m4sh, I haven't analyzed.
> 
> Okay thanks.  I'll take a look, though I don't think it's something that
> would make 2.2.8 from HEAD worse than 2.2.6a in the wild, so I think it
> can afford to wait until we've reved.

Well, it's trivial to *avoid* by working around, when you do a release:
  unset GREP FGREP SED ...
  PATH=/some/suitable/tools/bin:$PATH
  export PATH

so please remember to do that, in case the bug isn't fixed beforehand.

Thanks,
Ralf


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

Re: When to bump library api version (current)

[Ralf Wildenhues]

Hello,

* Adam Mercer wrote on Thu, May 20, 2010 at 06:43:38AM CEST:
> On Wed, May 19, 2010 at 23:36, Daniel Herring wrote:
> > ISTM that this is not an ABI change; the addition of const only affects the
> > code being called, and in a manner compatible with the non-const version
> > (assuming calling code did not expect this parameter to be changed).
> 
> This was my thinking as well, I just wanted to double check as I don't
> want to have an incompatible library api bump unless I really need
> one.

For what it's worth, I wouldn't treat this as an incompatible API bump.
I would mention it to my users though, because when they use function
pointers and assign your library function, the change will show up.

> > That said, C++ compilers do change the name mangling based on constness; so
> > the above argument depends on your code being plain C.
> 
> This code is plain C. Although code written in C++ will link against
> this library but AFAIK that won't be an issue?

No, it won't.  You have to use 'extern "C"' in the headers of course.

Cheers,
Ralf

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

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Ralf Wildenhues]

Hello,

please don't Cc: autotools-announce on discussions.  Thanks.

* Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST:
> If I read your response correctly, all is needed is to set:
> lt_cv_deplibs_check_method="pass_all"
> For mingw hosts.
> 
> But I am no expert in libtool, and it is a complex set of macros.
> All I know that in the final result libtool script setting:
> deplibs_check_method="pass_all"
> 
> Makes it work.

But breaks other things on this system.

Cheers,
Ralf

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

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Ralf Wildenhues]

* Adam Mercer wrote on Fri, May 21, 2010 at 07:23:38PM CEST:
> Just updated one of my projects to use libtool-2.2.7b and configure
> now fails with:
> 
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
> 
> in configure.ac I was checking for a C++ compiler if a given option
> was used, i.e.:
> 
> # boinc requires a c++ compiler
> if test "${boinc}" = "true" ; then
>   AC_PROG_CXX
> fi
> 
> Always checking for a C++ compiler makes the error go away. Are
> conditional checks like this bad?

FWIW, this is caused/exposed by (quoting NEWS):

  - Fix long standing bug that caused compiler checks for Fortran and
C++ compilers to run twice.

I think the fix is right, and you've found a good workaround already,
too.  However, it might cause issues for quite a few more packages out
there.  I'm not sure what the best thing to do would be, but at the
least documenting it more prominently would seem prudent.

Cheers,
Ralf

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

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Ralf Wildenhues]

* Alon Bar-Lev wrote on Sat, May 22, 2010 at 11:13:50AM CEST:
> On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues wrote:
> > * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST:
> >> If I read your response correctly, all is needed is to set:
> >> lt_cv_deplibs_check_method="pass_all"
> >> For mingw hosts.
> >>
> >> But I am no expert in libtool, and it is a complex set of macros.
> >> All I know that in the final result libtool script setting:
> >> deplibs_check_method="pass_all"
> >>
> >> Makes it work.
> >
> > But breaks other things on this system.
> 
> Can you please outline [logically] a solution for achieving this
> without breaking other things?
> If you give me a hint I can check it out and produce another solution.

Not easy, because I haven't analyzed the issues that show up when
setting pass_all.  I know it breaks a few testsuite tests (and I fear
it breaks more things that we don't test in our testsuite), but it's
been a while and I haven't been taking good notes back then.  It might
be that some of the libtool logic is flawed wrt. the w32 semantics.

> Linking between DLL and static library is valid in this platform.

There were some arguing that it shouldn't be done out of
consistency/portability reasons: users could come to expect that this
would be possible everywhere.  I'm not sure where I stand here;
certainly, the testsuite failures encountered provide the more stringent
argument.

> Maybe accept "current ar archive" file type will perform better?

Sorry, I don't understand this suggestion.

Thanks,
Ralf

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

Re: Question about relink_command

[Ralf Wildenhues]

Hello,

* Gary V. Vaughan wrote on Mon, May 31, 2010 at 05:53:26PM CEST:
> AFAIK Linux binaries/libraries can be built in the build tree with
> no hardcoded references to other objects in the build tree, so they
> can always be copied into the install tree and continue working
> (although libtool has to wrap build tree binaries in a script to
> make sure that running them there picks up build tree libraries in
> preference to install tree libraries).

Yes.  While the above is true, there is another factor that comes into
play on GNU/Linux systems: we exploit the fact that we can hard-code
the paths to uninstalled deplibs in order to start uninstalled programs
without a wrapper script (I think).  That however means that uninstalled
libraries or programs with uninstalled dependencies will get relinked.

Similar reasoning applies to a couple of other systems IIRC.  Also, some
other systems beside HP-UX have the problem of hard-coding uninstalled
paths by default.

Cheers,
Ralf

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

Re: Building shared libraries at configuration time

[Ralf Wildenhues]

Hello Ludovic,

Bob has already addressed the rest of this I think, so:

* Ludovic Courtès wrote on Tue, Jun 01, 2010 at 01:15:32AM CEST:
> So it seems that the right test, when compiling natively, involves
> building a shared library and an executable linked against it, and
> running that executable.  That’s where you come in.  ;-)
> 
> How can libtool’s knowledge of compilers and linkers be leveraged from
> ‘configure’ to write such a test?

Use LT_OUTPUT after the other libtool macros in configure.ac, at which
point you have a ./libtool script you can use in further hand-written
configure tests.  In case you still need this.

Cheers,
Ralf

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

Re: Building shared libraries at configuration time

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Tue, Jun 01, 2010 at 04:48:48PM CEST:
[ __thread ]
> 
> You will likely find that 'valgrind' is not particularly friendly or
> helpful to diagnose memory problems in applications using this
> extension.

Is that still the case with valgrind 3.5?  Its testsuite contains tests
for __thread.  You might want to report a bug with a testcase that is
not supported well.

Cheers,
Ralf

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

Re: rewrite of ltdl and c++

[Ralf Wildenhues]

Hello,

* Peter O'Gorman wrote on Thu, Jun 10, 2010 at 05:12:41PM CEST:
> On 06/10/2010 09:45 AM, Gary V. Vaughan wrote:
> >>I think it would be better in c++.
> >
> >No, that would mean you have to jump through hoops to use it from C.

> It's simple to write a library in C++ but make its public interface
> C. There are many projects that use what I would describe as sane
> C++ (unfortunately there are also many that use every possible
> feature).

Linking a C-only project against a C++ library is quite error-prone if
you only use the C compiler.  I'm with Gary here.

Cheers,
Ralf

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

Re: pr-msvc-support merge

[Ralf Wildenhues]

Hello,

* Gary V. Vaughan wrote on Thu, Jun 10, 2010 at 04:35:41PM CEST:
> On 10 Jun 2010, at 20:55, Peter Rosin wrote:
> > However, I guess the situation is very much the same as with
> > $CC and the compile script and that seems to work. I just don't
> > understand exactly how.

That's pretty much an awful hack inside AM_PROG_CC_C_O, which overrides
$CC if need be.

> > Does it work because the CC make variable is
> > not the same thing as the CC shell variable?
> > 
> > *looks around a bit*
> > 
> > No, that's not it, one instance of the libtool script has
> > 
> > CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl"
> > 
> > and I only said CC=cl when I configured...
> 
> I don't know how it works either, but I think you're right to mirror
> the way automake handles CC.  Hopefully Eric or Ralf will jump in and
> correct me if I'm off base.

See above.  It'd be nice to not have many more of those, if we can help
it; but it seems to not bother too many users in practice, and if it's
confined to MSVC ...

> >>> Your way is also a bit over the top of my head. I don't know how to
> >>> create the infrastructure in the build system, so I'm going to need
> >>> help with that...
> >> 
> >> With the idea of contributing the script back to Automake for use in
> >> its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so
> >> let's just encapsulate it in a self-contained script to be installed
> >> alongside mdate-sh, depcomp and the like.  It looks pretty straight-
> >> forward actually.

This sounds like a good idea to me.

> > Hmm, does this mean that everything about getting support for MS lib
> > as archiver ends up in Automake?
> 
> Mostly, but libtool will make use of it too in projects that use both.
> And I think that libtool should pull the latest copy and distribute it
> in it's release tarballs too, since we also want libtool to be useful
> in non-automake projects (even non-Autoconf projects actually).

That sounds good to me, too.

It's just that if you need to transport information from configure to
such a script that things get a bit hairy.  We do it with 'depcomp' by
setting variables in the commands that run it, but IIUC you would prefer
that makefiles continue to work without changes.

> > One thing that I "fear" about not having the support built into libtool
> > is that projects might need to invoke some extra macro (copy-paste-fix
> > AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they
> > needed to support some oldish toolchain many years ago, but how many
> > maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script
> > at this point?
> 
> From (what I remember of) the inner workings of Automake, it's not
> difficult to teach the automake invocation to notice the use of
> _LIBRARIES or _LTLIBRARIES as it scans the Makefile.ams, and then
> AC_REQUIRE the necessary macros from AM_INIT_AUTOMAKE.

Right.

Cheers,
Ralf

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

Re: pr-msvc-support merge

[Ralf Wildenhues]

* Peter Rosin wrote on Sat, Jun 12, 2010 at 12:49:18AM CEST:
> Ok, let's take a step back. This is no longer really merging
> work from the branch, so since A) using MS lib as archiver isn't
> essential for MSVC support (at least I don't think so, I can't
> remember any case where binutils ar hasn't worked for me, but
> ar creates archives that are different so I don't really like
> the situation) and B) by the looks of it it will have little to
> do with patching libtool anyway, I think it might be better
> to leave the archiver work behind for a bit.

That's fine with me, too.

> By bringing a standalone script to the automake list that will
> (at the moment, and for the foreseeable future) only be of use
> if you want to use MS lib as archiver, but will still add
> another file to "all" packages, I feel that there is a risk that
> the benefit will be deemed too small when compared to the cost.
> ltmain is already large and a few extra lines will not be noticed
> by that many people.

Might be true, yes.  We could introduce Automake options for w32
support, but I can see why you are not keen to go that way, as it
would prevent support out of the box.

> The above may sound as if I'm opposed to moving the script to
> automake, but I'm not. I'm mostly afraid of the script ending up
> where the cccl script - or should I say script_s_ - ended up.

Well, I sort of figured that the 'compile' script could end up absorbing
quite a bit of the cccl functionality so to make it unneeded.  But hey,
let's be honest, somebody would have to do this work, because I don't
have the resources to do it.

> Attaching a very rough first cut, but I don't intend to work on
> this at the moment as explained at the top. I'll post a mail
> addressing the next patch on the branch soonish instead.

Thanks.  I hope Gary keeps up the momentum on this (and I'll try hard to
not be a blocker ;-)

Cheers,
Ralf

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

Re: pr-msvc-support merge

[Ralf Wildenhues]

[ adding automake-patches; this is
  http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=10954 ]

* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:
> Den 2010-06-12 10:05 skrev Ralf Wildenhues:
> >Well, I sort of figured that the 'compile' script could end up absorbing
> >quite a bit of the cccl functionality so to make it unneeded.  But hey,
> >let's be honest, somebody would have to do this work, because I don't
> >have the resources to do it.
> 
> Do you think something along these lines would be acceptable? It would
> remove the need of some patches on the pr-msvc-support branch...

The patch looks pretty good to me already, but is lacking additions for
ChangeLog, NEWS, and maybe doc/ and tests/ too.

Wrt. test suite exposure, here's my overall take on this for Automake:
Generally, the suite should try to cover each and every single code bit,
even error cases, as much as is feasible without big hassles.  Of
course, that'll only be realistic if you take the union of test suite
runs over all sorts of systems (but if some system-specific part can be
emulated elsewhere, that's great of course).  As a first step, if you
tell me that the patch fixes some failures of existing tests on some
system with
  env CC=cl make check

then that is fine with me too; as far as we have this information, it
should be noted in the log entry.

I understand the Automake test suite takes very long on MinGW.  As
long as patches are MSVC-specific, you don't need to run the whole
suite for every single patch.  Make good use of 'recheck' and
subsetting, as described in tests/README; for example, if you're only
ever dealing with C code handling,
  cd $top_srcdir/tests && set `grep -l CC *.test` && cd -
  make -k check TESTS="$*"

should cut load by two thirds already.

If there are tests that evoke popups or other things requiring
interactivity, then we should invent a 'required' name for that
and a helper make rule to run only those tests, or the complement,
similar to how is done in Libtool (do you use that there BTW?).

Wrt. 'compile' not being used by default in packages not using
AM_PROG_CC_C_O: don't worry about that for the moment.  It is a trivial
first approximation to install the 'compile' script somewhere and use
  ./configure CC='/usr/local/bin/compile cl'

Don't be tempted to add AM_PROG_CC_C_O to projects not needing it
otherwise.  If Automake support for MSVC is significantly improved,
at that point it could for example just install the compile script by
default in any project using C, and have AC_PROG_CC already trigger
the "is this MSVC?" check without AM_PROG_CC_C_O.

Wrt. avoiding the uname fork&exec, that can for example be optimized
by passing an option to the compile script before the compiler argument.
This too can come later, when we know better what set of information is
needed in 'compile'.

Some nits and questions:

> +  case $path_conv in
> + mingw)
> +   path=`cmd //C echo "$path " | sed -e 's/"\(.*\) " *\$/\1/'`

I fail to understand what this sed script is for.  Help?

> + cygwin)
> +   path=`cygpath -w "$path"`

IIUC cygpath is pretty much required to be present on Cygwin
installations, right?  Can it fail though?  Should $path retain its old
value if it does?  Don't we want -m rather than -w for forward slashes
(which IIUC even MSVC programs should support) to avoid quoting issues?
  path=`cygpath -m "$path" || echo "$path"`

> + wine)
> +   path=`winepath -w "$path"`

winepath OTOH may not be present, so this should definitely fall back to
the unconverted path I think.  And maybe the path_conv-setting code
check for presence of winepath.

> +# func_cl_wrapper cl arg...
> +# Adjust compile command to suite cl
> +func_cl_wrapper ()
> +{
> +  # Assume a capable shell
> +  for arg
> +  do
> +if test -n "$eat"; then
> +  eat=
> +else
> +  case $1 in
> + -o)
> +   # configure might choose to run compile as `compile cc -o foo foo.c'.
> +   eat=1
> +   case $2 in
> + *.o | *.obj)
> +   func_path_conv "$2"
> +   set x "$@" -Fo"$path"
> +   shift
> +   ;;
> + *)
> +   func_path_conv "$2"
> +   set x "$@" -Fe"$path"
> +   shift
> +   ;;
> +   esac
> +   ;;
> + -I*)
> +   func_path_conv "${1#-I}"
> +   set x "$@" -I"$path"
> +   shift
> +   ;;
> + -l*)
> +   set x "$@" "${1#-l}.lib"
> +   shift
>

Re: upgrading from 2.2 to 2.2.8

[Ralf Wildenhues]

Hello Sam,

* Sam Steingold wrote on Wed, Jun 16, 2010 at 07:04:31PM CEST:
> I upgraded my libtool.m4 from 2.2 to 2.2.8 and now aclocal fails:
[...]
> apparently, I must include some other files in addition to libtool.m4:
> 
>   4 argz.m4  28 ltdl.m4 8 ltsugar.m4  4 ltversion.m4
> 256 libtool.m4   12 ltoptions.m44 ltversion.in8 lt~obsolete.m4
> 
> which ones?

Those that libtoolize, given the appropriate options, will install for
you, or tell you to use.  `info Libtool LT_INIT' and the 'Invoking
libtoolize' have more information on AC_CONFIG_MACRO_DIR and
ACLOCAL_AMFLAGS you might want to set beforehand.

This isn't really different between 2.2 and 2.2.8, BTW, that already
happened when we moved from 1.5.x.

> why did you make this change?

Because we, too, prefer cleaning up things every now and then.

Hope that helps.

Cheers,
Ralf

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

Re: Blackfin and version scripts

[Ralf Wildenhues]

Hello Russ, all,

* Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST:
> I would dearly, dearly love for libtool to pick up a --version-script
> option that would pass in the full version script on platforms with
> linkers that understand it, turn it into a symbol export list on platforms
> that only support that,

is this doable programmatically?  Without a full version script parser?

> and suppress it entirely if the linker doesn't
> have any relevant capabilities.  That would save me a ton of maintenance
> burden on some of my packages, and it would then be easy to add a feature
> like the above as well.

Can somebody try to come up with a more detailed set of semantics, so we
can judge a bit better whether this is feasible?  If it is, any
volunteers on implementing this?

Do you know the gnulib module lib-symbol-versions?  (No, it's not a
complete solution.)

Thanks,
Ralf

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

Re: Blackfin and version scripts

[Ralf Wildenhues]

Hello Werner, all,

* Werner Koch wrote on Tue, Jun 22, 2010 at 11:42:43AM CEST:
> Mike and Robin found a build problem with libgcrypt on Blackfin using
> the GNU toolchain: Libgcrypt as most other GnuPG related libraries tries
> to keep a well defined ABI and thus use a version script to guarantee
> that.  The version script is passed to libtool this way:
> 
>   if HAVE_LD_VERSION_SCRIPT
> libgcrypt_version_script_cmd = 
> -Wl,--version-script=$(srcdir)/libgcrypt.vers
>   else
> libgcrypt_version_script_cmd = 
>   endif
>   [...]
>   libgcrypt_la_LDFLAGS = $(no_undefined) $(export_symbols) \
>   $(libgcrypt_version_script_cmd) -version-info \
>   @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@
> 
> $(no_undefined) $(export_symbols) are only used for W32 and not defined
> if we have version script support.

Why is -no-undefined not used unconditionally?  For C-only code, this
shouldn't be a problem (and if it is, we'd like to hear about it).

Cheers,
Ralf

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

Re: Blackfin and version scripts

[Ralf Wildenhues]

* Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST:
> On Wed, 23 Jun 2010 07:29, r...@stanford.edu said:
> 
> > I can take a pass at starting.  All that I need for my packages is to
> > support the basic version syntax:
> >
> >  {
> >   global:
> > ;
> 
> That would be sufficient for me too as long as a  with only
> global symbols is supported as well.
> 
> Having a second file with a simple list of symbols instead of a version
> script parser is another option.  Actually this is required because to
> support W32 we need a .def file
> 
>   EXPORTS
>   gcry_check_version  @1
>   gcry_control  @2
> 
> which allows to assign id numbers to symbols.  In theory we could add
> this via comment lines to a versions script but that would make a parser
> even more complicated.  In some projects I create the .def file from a
> .def.in file to handle differences between W32 and W32CE.  In any case
> the .def file is easy to parse and could be used as input to
> --export-symbols.

OK, so the problem space as I see it:

- complex GNU/Solaris ld version scripts, but most users need only a
  fairly simple part of that,
- w32 .def files,
- symbols lists or regexes as used by libtool,
- the wild card specification to use: ld uses globbing,
  -export-symbols-regex uses ERE.
- mangling relevant also for C: prepending underscore or not, appending
  calling convention suffixes @... on w32,
- mangling for non-C languages: C++, Java,
- libtool should be able to add or remove a few symbols to the list,
- for w32, we may need to tag DATA exports,

"Parsing" is hard in the shell.  It's probably easiest to define a
libtool-specific language ("file format") that is easily amenable to sed
or old awk, from which we can generate a ld version script, a def file,
or a list of mangled symbols.  That language could still allow the user
to specify arbitrarily complex version script constructions, as long as
they are given in a way our parser can easily ignore.  That's the hard
part.

A complicating factor in the current libtool handling for exports is
line length limitations: we might need to cope with partial links or
reloadable objects, or, preferably, employ one of the workarounds like
response files or linker scripts.  This part in ltmain I know how to
deal with, so if you need help there speak up.

Cheers,
Ralf

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

Re: Empty allow_undefined_flag in libtool.m4 seems to cause undefined symbol errors on Linux

[Ralf Wildenhues]

Hello Ben,

any chance you could get your mailer to word-wrap at 72 chars?  Thanks.

* Ben Roberts wrote on Sat, Jul 03, 2010 at 01:55:51AM CEST:
> I've been trying to adapt a set of libraries and programs to use
> autoconf, automake and libtool instead of being manually configured.
> One of the features of this particular package is that there are some
> symbols that should be satisfied at run time, rather than at
> compile-and-link time.

Is this a feature for this package's shared libraries only, or also for
programs?

> Now, when I try to build on a Linux box with GNU ld 2.17.50.0.6-9.el5,
> I get errors about undefined symbols.

Please show an example link command line that fails, including output.

> That version of the linker can be persuaded to ignore undefined
> symbols using the "--unresolved-symbols=ignore-all" flag.
> 
> When I consulted libtool.m4, I found that there's a variable in there
> that is supposed to contain that flag, or its equivalent on different
> systems: namely, allow_undefined_flag (with a suffix for the compiler
> in certain instances).
> 
> The problem: in libtool.m4, allow_undefined_flag is left as an empty
> string on Linux systems.

Yes, well, GNU/Linux systems allow undefined symbols by default in
shared libraries.

> Is modifying, and perhaps preparing a patch for, libtool.m4 the best
> approach? An alternative is, no doubt, to write some kind of
> Linux-specific workaround in my configure.ac, but as far as I know
> libtool aims to spare me that kind of thing...

Well, a patch is acceptable for behavior we can generalize.  In order to
find that out, we should have a testsuite addition that tries out the
feature that you would like to see work (showing a small example is
fine, we can easily rework that into a testsuite addition).  Then we can
judge it better, and see whether this is good to have generally.
Otherwise, let's then see what you can do instead.

Hope that helps.

Cheers,
Ralf

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

Re: CentOS 4 Build Erro

[Ralf Wildenhues]

Hello Damian,

thanks for the report.

* Damian Hess wrote on Fri, Jul 02, 2010 at 04:09:16PM CEST:
> I'm trying to install libtool-2.2.8 on a CentOS 4.7 box for another
> piece of software that requires libtool, however when I run make I get
> the following error:
> 
> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 -no-undefined 
> -version-info 9:2:2 -dlpreopen libltdl/dlopen.la   -o libltdl/libltdl.la 
> -rpath /usr/local/lib libltdl/loaders/libltdl_libltdl_la-preopen.lo 
> libltdl/libltdl_libltdl_la-lt__alloc.lo 
> libltdl/libltdl_libltdl_la-lt_dlloader.lo 
> libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo 
> libltdl/libltdl_libltdl_la-slist.lo libltdl/lt__strl.lo -ldl 
> libtool: link: rm -f libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS 
> libltdl/.libs/libltdl.nmT
> libtool: link: (cd libltdl/.libs && gcc -g -O2 -c -fno-builtin  -fPIC -DPIC 
> "libltdlS.c")
> libltdlS.c:26: error: `lt_ptr' undeclared here (not in a function)
> libltdlS.c:26: error: initializer element is not constant
> libltdlS.c:26: error: (near initialization for 
> `lt_libltdl_LTX_preloaded_symbols[1].address')
> libltdlS.c:26: error: syntax error before numeric constant
[...]
> make[2]: *** [libltdl/libltdl.la] Error 1

Weird.  I remember this sort of error, but waay before 2.2.8, more like
1.5.x something.  Can you run the above --mode=link command manually
with RM='echo ' set in the environment beforehand, then post
libltdl/.libs/libltdlS.c?

The file is generated from the libtool script.  I think something like
this (GNU sed-specific) edit
  sed -i~ 's/\/void */g' libtool

should probably work around the bug, unless I'm gravely mistaken.

> I'm sure there is another component that I am missing (wrong version
> of gcc or something else) but I can't find a list of requirements to
> build libtool.  Any help or direction would be appreciated.

You need a C compiler that is supported; many are, and most all releases
of GCC should be.  And the usual unix shell tools.  Any other
requirements for building from a release tarball are usually bugs.

Hope that helps.

Cheers,
Ralf

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

[sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR

[Ralf Wildenhues]

Update of sr #107416 (project libtool):

Severity:  3 - Normal => 4 - Important  

___

Follow-up Comment #1:

Yes it is a real problem and it is a Libtool bug.

If you already have a testcase handy, please post it (to the libtool-patches
list), preferably as patch against tests/destdir.at.  Thanks.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


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

Re: Issues w/ "relink" and cross-compilation

[Ralf Wildenhues]

Hello Philip,

thanks for the reports.

* Philip Prindeville wrote on Sun, Jul 11, 2010 at 02:38:28AM CEST:
> The problem is that a lot of projects that we use in turn use
> libtool (and not always terribly up-to-date versions of it),

this is something I'm afraid you need to take up with the projects.

> and
> what seems to happen is that the relink stage uses -L/usr/lib by
> default, even when cross-compiling.

This is a bug in libtool.  I could argue about calling it a limitation,
but that doesn't really matter.

> There's probably a really simple trick to getting this not to happen,
> but it's not obvious to me.  Also, it would be nice if libtool figured
> out the need to do this on its own (i.e. figure out that it's
> cross-compiling and that -Lxxx for any host libraries shouldn't be
> included).
> 
> Can someone walk me through the workaround?

I'm not sure there is a general workaround.  For some setups it helps to
(temporarily) remove the .la files of the libraries relinked against.

I don't really have the time to look into this right now (and I expect
it to be at least a little bigger project), but here's what you (and
others) can do to help: post small reproducible examples, ideally as
portable as possible, and ideally as XFAILing testsuite additions
against tests/destdir.at so that it is clear what it is that is to be
fixed.

If you are not at ease with Autotest, a small shell script that creates
the necessary files and invokes libtool in the way that exposes the
bug(s) is fine, too.  It's just that IIRC, there were a lot more than
just one detail to get right here, some quite debatable because they
don't apply in all situations, and I think we should start by collecting
setups that we think ought to work.

One complication when writing tests for this is that tests shouldn't
mess with system directories like /usr/lib or /usr/local/lib but OTOH
libtool treats directories listed in sys_lib_search_path_spec and
sys_lib_dlsearch_path_spec special.  It might be necessary to use a
munged libtool script (similar to tests/install.at and others) that
adds entries to these below the build tree so we can play with them.
(Of course the test then needs to ensure that the link editor and/or
runtime linker really searches these directories.)

These comments of course all hold for the --sysroot stuff as well, which
is in a similar category of issues.

Please note that nontrivial additions need copyright assignment (ping me
and I'll send you the form off-list).

If somebody has done the work of searching for proposed patches for
these issues (IIRC there are a couple floating around at least in some
distros) then posting links would be a good thing.

Thanks,
Ralf

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

Re: [PATCH] updating homepage with current version and other minor fixes

[Ralf Wildenhues]

Hi Carlo,

* Carlo Marcelo Arenas Belon wrote on Mon, Jul 12, 2010 at 01:27:00AM CEST:
> The following patch updates the main libtool page to reflect the new version
> released and correct some minor typo and link.

installed.  Thank you!

Cheers,
Ralf

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

Re: libtool documentation missing Index.html

[Ralf Wildenhues]

Hello Carlo,

* Carlo Marcelo Arenas Belon wrote on Mon, Jul 12, 2010 at 12:37:15AM CEST:
> As can be seen by clicking on the HTML or HTML compressed (gzip tar) links
> in : 
> 
>   http://www.gnu.org/software/libtool/manual/
> 
> funny enough is not a bug on gendocs.sh or the documentation itself as I
> hadn't been able to reproduce it but probably just that the process was
> executed on a case sensitive filesystem (maybe a MAC) and therefore blowed
> away the documentation index (index.html) with the concept index (Index.html)

Thanks for the report and analysis, that seems about right I guess.
I replaced the files now with regenerated ones.

> the following patch should prevent that to happen but just rebuilding the
> documentation in a linux box would fix this for 2.2.10 without requiring
> any patching.

Hmm, I'm wondering whether it might not be nicer to eventually start
splitting up the Index into a couple of typed indices, as is done in
autoconf.html.

Cheers,
Ralf

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

Re: libtool documentation missing Index.html

[Ralf Wildenhues]

* Carlo Marcelo Arenas Belon wrote on Mon, Jul 12, 2010 at 07:34:55AM CEST:
> On Mon, Jul 12, 2010 at 07:13:03AM +0200, Ralf Wildenhues wrote:
> > * Carlo Marcelo Arenas Belon wrote on Mon, Jul 12, 2010 at 12:37:15AM CEST:
> > > As can be seen by clicking on the HTML or HTML compressed (gzip tar) links
> > > in : 
> > > 
> > >   http://www.gnu.org/software/libtool/manual/
> > > 
> > > funny enough is not a bug on gendocs.sh or the documentation itself as I
> > > hadn't been able to reproduce it but probably just that the process was
> > > executed on a case sensitive filesystem (maybe a MAC) and therefore blowed
> > > away the documentation index (index.html) with the concept index 
> > > (Index.html)
> > 
> > Thanks for the report and analysis, that seems about right I guess.
> > I replaced the files now with regenerated ones.
> 
> the file libtool.html_node.tar.gz which is linked for download as explained
> above also needs to be updated with the new version that has both "index"
> files.

Updated as well now, thanks.

> also, just curious, but noticed that the CVS tree wasn't updated before
> (except for some individual files) when 2.2.10 was released and therefore
> was obviously not reflecting what was visible in the site (since it had
> both files) so I wasn't sure if maybe there might be other issue where
> the website tree has been accidentally clovered :
> 
>   http://web.cvs.savannah.gnu.org/viewvc/libtool/manual/?root=libtool

That's because a lot of the files were actually identical between 2.2.8
and 2.2.10.  They were released in quick succession.

Cheers,
Ralf

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

Re: z/OS

[Ralf Wildenhues]

Hi Alon,

* Alon Bar-Lev wrote on Wed, Jul 14, 2010 at 04:48:22PM CEST:
> Does anyone has experience with libtool at z/OS open edition?
> It builds static libraries, but it does not know how to build shared objects.

AFAICS Libtool does not support z/OS yet, which means only static
libraries can be expected to work.

Porting Libtool to a new system is fairly straightforward if all the
documentation is available.  Are you willing to help with this?
If yes, I can start writing a number of questions for it.  You could
send pointers.  Generally, the right thing to do is grab git Libtool,
start reading the PORTING file, follow pointers there, and search for
PORTME in *.m4 files.  When you have something that works, start running
the test suites to find out that you're not quite done yet.  ;-)
Post whatever you can find out, including (very important!) test suite
output.

We may need copyright papers for nontrivial patches (so please don't
post them if you're not willing to go there; in that case it is easier
if you provide pointers and test suggested patches from us).

Hope that helps.

Cheers,
Ralf

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

Re: z/OS

[Ralf Wildenhues]

Hi Howard,

* Howard Chu wrote on Thu, Jul 15, 2010 at 06:51:30AM CEST:
> 
> The z/OS linker has two operating modes, old style and XPLINK. I
> seem to recall that you can only create DLLs using XPLINK. This has
> some complications because XPLINK throws all object files into a
> single namespace; if you have two object files with the same
> filename foo.o they will clash and either the link will fail or only
> one of them will be inserted into the result.

This should be fairly easy to work around: libtool already has machinery
in place to rename objects sub1/foo.o sub2/foo.o that are to be added to
the same static library; we could enable that machinery for shared
objects on systems that need it.

Cheers,
Ralf

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

darwin access

[Ralf Wildenhues]

Hello,

my access to a darwin system has gone; is there anybody with a darwin
system willing to give me ssh access to a system to use for autotools
portability testing?  Please answer off-list, Reply-To: set.

Thanks,
Ralf

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

Re: Linking problem building iconv on Solaris x86

[Ralf Wildenhues]

* Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:07:28PM CEST:
> http://trac.sagemath.org/sage_trac/attachment/ticket/9718/iconv-1.13.1.p2.log

Does it work if you run this command manually, i.e., the failing link
but without -no-undefined?

/bin/bash ../libtool --mode=link gcc  -m64 -fvisibility=hidden -o libiconv.la 
-rpath /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info 7:0:5 
iconv.lo localcharset.lo relocatable.lo

Cheers,
Ralf

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

Re: Linking problem building iconv on Solaris x86

[Ralf Wildenhues]

Hello David,

* Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:48:25PM CEST:
> On 08/10/10 09:28 PM, Ralf Wildenhues wrote:
> >/bin/bash ../libtool --mode=link gcc  -m64 -fvisibility=hidden -o 
> >libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib 
> >-version-info 7:0:5 iconv.lo localcharset.lo relocatable.lo
> 
> No, it does not.
> 
> (sage subshell) fulvia:lib drkirkby$ /bin/bash ../libtool
> --mode=link gcc  -m64 -fvisibility=hidden -o libiconv.la -rpath
> /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info
> 7:0:5 iconv.lo localcharset.lo relocatable.lo
> libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libiconv.so.2
> -o .libs/libiconv.so.2.5.0  .libs/iconv.o .libs/localcharset.o
> .libs/relocatable.o   -lc  -m64

Hrmpf.  On Solaris, we add '${wl}-z ${wl}text' to archive_cmds and
archive_expsyms_cmds unconditionally, as opposed to only with
-no-undefined.  I wonder why that is the case.

But of course I also wonder why the problem happens at all.  iconv.o is
built with PIC, so that would indicate a bug in GCC, or possibly the
assembler or linker.  Which GCC version is this, and how was it
configured?  Any chance you can create a small reproducible example to
send to the GCC bugzilla?

> I've often had these "relocations remain against allocatable but
> non-writable sections" messages on Solaris. They seem to fox a lot of
> people when you Google for them.

Sorry for them, but I don't think Google is accepting bug reports for
Libtool nor GCC.  I don't recall a prior report for gcc on Solaris on
the Libtool lists (unlike for a C++ compiler on Solaris).

Cheers,
Ralf

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

Re: Linking problem building iconv on Solaris x86

[Ralf Wildenhues]

* Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 11:33:36PM CEST:
> On 08/10/10 10:10 PM, Ralf Wildenhues wrote:
> >* Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:48:25PM CEST:
> >>(sage subshell) fulvia:lib drkirkby$ /bin/bash ../libtool
> >>--mode=link gcc  -m64 -fvisibility=hidden -o libiconv.la -rpath
> >>/home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info
> >>7:0:5 iconv.lo localcharset.lo relocatable.lo
> >>libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libiconv.so.2
> >>-o .libs/libiconv.so.2.5.0  .libs/iconv.o .libs/localcharset.o
> >>.libs/relocatable.o   -lc  -m64
> >
> >Hrmpf.  On Solaris, we add '${wl}-z ${wl}text' to archive_cmds and
> >archive_expsyms_cmds unconditionally, as opposed to only with
> >-no-undefined.  I wonder why that is the case.
> 
> If you don't know, I'm sure I don't.

Can you try removing that from the archive_cmds and archive_expsyms_cmds
variable settings in the first 150 lines of the generated libtool script
and seeing if the link then works?  You might still have to also remove
-no-undefined from the link command line again.  Thanks.

If that works, then at least you have a workaround.

And, do you have a link to a tarball that shows this issue?
A login might help, thanks, but it might take a while to look at it.

> It's not so obvious where the bug here is, which is perhaps why
> people don't really know where to report it to.

Good point.

Thanks,
Ralf

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

Re: Linking problem building iconv on Solaris x86

[Ralf Wildenhues]

* Dr. David Kirkby wrote on Wed, Aug 11, 2010 at 11:30:25AM CEST:
> On 08/11/10 05:33 AM, Ralf Wildenhues wrote:
> >Can you try removing that from the archive_cmds and archive_expsyms_cmds
> >variable settings in the first 150 lines of the generated libtool script
> >and seeing if the link then works?  You might still have to also remove
> >-no-undefined from the link command line again.  Thanks.
> 
> There's no such things in the first 150 lines, but if you are happy
> with the first 320 lines, then yes. I set:
> 
> archive_cmds=""
> archive_expsym_cmds=""

Ah, no, I didn't mean to empty those variables completely, just remove
the '\${wl}-z \${wl}text' thingies from the variable setting; keep the
rest, please.

> >If that works, then at least you have a workaround.
> 
> It's not so easy as that, as I don't know how to modify the
> makefile/configure script so that it installs all the files needed
> in the right places. This does a lot more than build a few libraries
> that I can copy to a lib directory.

Don't worry.  If we find a way to manually fix things, then there is
most always a way to fixup things more or less automatically.  I just
first need confirmation that the above really is an exposer for the
issue and not a distraction; given that information, I can help you
with a patch against libtool.m4, or against configure scripts.

> The other problem is that to make some progress on Sage, I really
> need a package that is not going to be very difficult for someone to
> install. Getting people to test on Solaris is hard enough - without
> the hassles of them doing this manually

Sure.

Cheers,
Ralf

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

Re: Building modules on AIX

[Ralf Wildenhues]

Hi Daniel,

* Daniel Sands wrote on Fri, Aug 20, 2010 at 07:16:04PM CEST:
> I'm using 2.2.10.
> 
> Didn't Libtool once have the behavior on AIX that if -module was
> specified, it wouldn't wrap the .so in a .a archive?

I'm on the run right now, so can't really confirm that this wasn't ever
the case (will try to do later), but ...

> I'm having trouble
> building and installing Apache because it is wrapping its mod_'s.
> Is there a configuration flag to change this?

... using LDFLAGS=-Wl,-brtl at configure and link time should achieve
this in any case.

Hope that helps, and please report back if it doesn't!

Thanks,
Ralf

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

Re: Building modules on AIX

[Ralf Wildenhues]

Hello Daniel,

please don't top-post, thank you!

* Daniel Sands wrote on Fri, Aug 20, 2010 at 08:11:01PM CEST:
> Yeah I'm just trying to avoid the RTL because it sometimes gums up the
> works.  APR started with -brtl and it caused a bunch of headaches trying
> to make that work--it built both the .so's and the static libraries, and
> APR-UTIL linked to the static libraries instead of the .so's.  Maybe
> the .la generated by the .a version took priority on the install.

Can you try
  ./configure --disable-static LDFLAGS=-Wl,-brtl

?  I can otherwise look into this, but it'll be a few days.

> I'm ultimately trying to build Subversion, but I'm caught in Dependency
> Hell.

I'm sorry.  Aren't there pre-built binary packages for APR available?

Cheers,
Ralf

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

Re: linux to windows cross compile af a dll

[Ralf Wildenhues]

Hello,

* Eric Blake wrote on Tue, Aug 24, 2010 at 06:47:51PM CEST:
> On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote:
> >*** Since this library must not contain undefined symbols,
> >*** because either the platform does not support them or
> >*** it was explicitly requested with -no-undefined,
> >*** libtool will only create a static version of it.
> >
> >It seems to be related to
> >http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html
> >
> >Is the hack that is mentioned necessary or is there another solution?

Which ./libtool --version is your package using?  With 2.2.10,
no hacks should be necessary.

If 2.2.10 is still not working right, please post the output of
the failing 'libtool --mode=link' command, with --debug added as
first argument after libtool.  Thank you.

Replies can drop the automake list from Cc:.

Cheers,
Ralf

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

Re: Link Time Optimization

[Ralf Wildenhues]

Hello David,

* David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST:
> I've been searching mailing list for supporting -flto in libtool, and seen 
> several (commited?) patches.

not yet committed, unfortunately; I had hoped for feedback from a person
knowledgeable with WinCE, but that didn't happen.  Oh well.

Since my Great Plan for automated testing is read to be deployed this
weekend, I think I'll have another go at testing the proposed patches;
they change commands on a lot of different systems, and I want to make
sure they work before committing under the 72hour rule as Gary suggested
before.

So, unless problems show up, they should hopefully appear in 2.2.12,
due fairly soon.

> The problem is that I've tried git version of libtool (trunk) and still it is 
> not supported since any program will compile with -flto (for example, 
> mysql-5.1.50).

Thanks for mentioning that, I will test the patches on this package
then.

Cheers,
Ralf

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

Re: Link Time Optimization

[Ralf Wildenhues]

Hello Vincent,

* Vincent Torri wrote on Tue, Aug 24, 2010 at 07:09:18PM CEST:
> On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
> 
> >* David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST:
> >>I've been searching mailing list for supporting -flto in libtool, and seen
> >>several (commited?) patches.
> >
> >not yet committed, unfortunately; I had hoped for feedback from a person
> >knowledgeable with WinCE, but that didn't happen.  Oh well.
> 
> sorry, i didn't follow the thread.

That's unfortunate, because it cost us a couple of months now.  :-/
I Cc:ed you on the thread, was that wrong?  How can we reach you?

> What is the problem with WinCE ?

See here:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9990
http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769

To repeat the question: can I assume that the preprocessor symbol
_WIN32_WCE is defined for wince code, and usually not defined for
non-wince code?

Thanks,
Ralf

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

Re: Link Time Optimization

[Ralf Wildenhues]

Vincent, what about the other question I asked:

* Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST:
> >I Cc:ed you on the thread, was that wrong?  How can we reach you?

Please answer this.  Without somebody to ask about WinCE we *can* *not*
support it.

> >http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9990
> >http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769
> >
> >To repeat the question: can I assume that the preprocessor symbol
> >_WIN32_WCE is defined for wince code, and usually not defined for
> >non-wince code?
> 
> Yes. _WIN32_WCE is defined only on Windows CE platform.

Thanks!
Ralf

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

Re: Link Time Optimization

[Ralf Wildenhues]

* Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST:
> On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
> >* Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST:
> >>>I Cc:ed you on the thread, was that wrong?  How can we reach you?
> >
> >Please answer this.  Without somebody to ask about WinCE we *can* *not*
> >support it.
> 
> sorry, i don't really understand (my english is so ugly...). What do
> oyu want, exactly ? a mail ?

English:

In order to be able to support Libtool on WinCE, we need somebody to be
able to test it regularly, for example before releases; also, we need to
be able to ask questions about it now and then.  Are you able to do this
for us?  I can try to ask questions in French, but it's not practical to
wait months for answers.  Thank you.

French:

Pour être en mesure de soutenir Libtool sur WinCE, nous avons besoin de
quelqu'un pour être de pouvoir le tester régulièrement, par exemple,
avant de presse; aussi, nous devons être en mesure de poser des
questions à ce sujet ici et là. Êtes-vous capable de le faire pour nous?
Je peux essayer de poser des questions en français, mais ce n'est pas
pratique pour attendre des mois pour obtenir des réponses. Merci.
(Cela a été traduit translate.google.com)

Cheers,
Ralf

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

Re: Link Time Optimization

[Ralf Wildenhues]

* David wrote on Wed, Aug 25, 2010 at 04:31:08AM CEST:
> Instead of relying in only one person and possibly waiting for his response, 
> how about to start supporting it in all other arches and disabling it on 
> untested arches like WinCE?

That's not the point.  The question was for some reorganization needed
prior to the actual LTO-enabling patches.  I did not see a way to do the
reorganization sanely without it affecting WinCE.  Many changes in
Libtool don't just affect one system.

Details can all be found in the threads I've quoted.

Cheers,
Ralf

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

Re: problem with mingw-w64 and libraries like libole32.a

[Ralf Wildenhues]

* Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST:
> I checked out libtool git 2 days ago and try to compile a library
> that uses libole32 or libws2_32 with mingw-w64 (cross compilation on
> linux). I get the usual message:
> 
> *** Warning: linker path does not have real file for library -lole32.
> etc...
> 
> No problem with mingw. A guy from mingw-w64 told me that it worked
> before. Could this be a regression ?

Please rerun the 'libtool --mode=link' command with --debug added as
first argument after libtool, and post both the complete command as well
as all output.  Thanks.

Cheers,
Ralf

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

Re: Linking problem building iconv on Solaris x86

[Ralf Wildenhues]

For others looking at the same issue:

We hashed this issue out off-list, using
  configure CC='gcc -m64'

works, just
  configure CFLAGS=-m64

fails.

Cheers,
Ralf

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

Re: GNU Libtool 2.2.8 released (stable)

[Ralf Wildenhues]

Hello Adam,

* Adam Mercer wrote on Tue, Aug 31, 2010 at 08:44:59PM CEST:
> On Fri, Jun 4, 2010 at 15:44, Gary V. Vaughan  wrote:
> >  - Initial support for the Cuda Compiler Driver on GNU/Linux.
> 
> Is there any documentation for this anywhere, I can't find anything in
> the online manual nor info document and a quick Google search only
> leads me to the release notes for 2.2.8?

Well, the support is basically

and comes from this discussion:


Other patches posted for improved Cuda support in autotools had to be
ignored so far because submitters were not able or willing to assign
copyrights.

What are you missing, what is not working?

Cheers,
Ralf

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

Re: libtool and Cuda

[Ralf Wildenhues]

Hi Adam,

* Adam Mercer wrote on Wed, Sep 01, 2010 at 08:28:43PM CEST:
> I was just wondering what is available as about 18 months ago we added
> some Cuda code to one of our projects and have found that the build
> isn't working with more recent versions of Cuda. We have rules such as
> the following to build .c files from the .cu that are then compiled:
> 
> SUFFIXES = .cu .c
> .cu.c:
>   @nvcc -cuda --host-compilation=c $(INCLUDES) $(CPPFLAGS) --output-file 
> $@ $<
> 
> it seems that in newer cuda versions the --host-compilation option has
> been dropped so we need to approach this differently.

Do you know how?  (Because that knowledge will be needed when
implementing this.)

> As the
> libtool-2.2.8 ChangeLog mentioned initial support for Cuda I was
> interested in how to use this, i.e. if we specify the Cuda source file
> in the list of SOURCES will libtool call nvcc appropriately?

No, that would require Cuda .cu file support in Automake; sorry.

I'd love to have this, and there has been a patch for this, too
(and I think it was reasonably good), but again, the copyright
question could not be cleared up so we have to ignore the patch.

If you are willing to code up a patch for this, and to assign
copyright to the FSF, then be my guest.

Cheers,
Ralf

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

Re: libtool and Cuda

[Ralf Wildenhues]

[ adding automake-patches, replies can drop libtool@ ]

* Adam Mercer wrote on Wed, Sep 01, 2010 at 09:03:53PM CEST:
> On Wed, Sep 1, 2010 at 13:44, Ralf Wildenhues wrote:

[ automake support for cuda ]

> > I'd love to have this, and there has been a patch for this, too
> > (and I think it was reasonably good), but again, the copyright
> > question could not be cleared up so we have to ignore the patch.
> >
> > If you are willing to code up a patch for this, and to assign
> > copyright to the FSF, then be my guest.
> 
> I'll take a look but can't promise anything. I have no objection with
> assigning copyright to the FSF as this will make things much easier in
> the future.
> 
> Where would be an appropriate place to start in looking at adding this 
> support?

Check out the Automake git tree, find the patch in the git log that
added UPC support.  Or the discussion on the automake-patches list.
It's probably almost as simple as s/UPC/CUDA/ s/upc/cuda/  plus
adjusting some blurbs and the actual compile rule, once you know how it
should look like.

Cheers,
Ralf

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

Re: Anything remaining to hold up the August release I promised?

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:00:20PM CEST:
> Unless there are any unmerged patches or unresolved issues to bring to
> my attention, I'll make a new libtool release from the HEAD of master
> branch this coming weekend (September 5th).

I haven't pushed the new small LTO patch series yet.  The 72 hours are
over.  Anybody want to review (or reject) it before I push?

I still see about a dozen bugs in the testing that I have done, but
probably only have time for whatever I can manage to fix tonight.
http://autobuild.josefsson.org/libtool/

Cheers,
Ralf

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

Re: Anything remaining to hold up the August release I promised?

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:39:18PM CEST:
> I don't have time either until Sunday at the earliest.

I don't either.  So please let's move this a week or two off.
Peter and Charles have several remaining patches too.
All bored devs can look at autobuild logs and fix regressions
in the meantime.

> If you want to
> wait for a review, I can push back the release until next weekend if we
> agree to freeze master except for LTO and any bug-fixes we find time for
> between now and then.

Well, Peter *did* announce his patches earlier, and it would be really
good to have that queue flushed, as well as the couple of remaining ones
from Charles.

Cheers,
Ralf

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

Re: Anything remaining to hold up the August release I promised?

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Thu, Sep 02, 2010 at 08:45:02PM CEST:
> On Wed, 1 Sep 2010, Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:00:20PM CEST:
> >>Unless there are any unmerged patches or unresolved issues to bring to
> >>my attention, I'll make a new libtool release from the HEAD of master
> >>branch this coming weekend (September 5th).
> >
> >I haven't pushed the new small LTO patch series yet.  The 72 hours are
> >over.  Anybody want to review (or reject) it before I push?
> 
> While I doubt that I am qualified to review the patch, I am
> definitely interested in seeing autotools fully support LTO.

Can you try out the patch series, ideally on something other than
GNU/Linux?  If it helps you, I can push the branch I have it on.

Thanks,
Ralf

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

Re: Anything remaining to hold up the August release I promised?

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Thu, Sep 02, 2010 at 08:59:25PM CEST:
> On Thu, 2 Sep 2010, Ralf Wildenhues wrote:
> >
> >Can you try out the patch series, ideally on something other than
> >GNU/Linux?  If it helps you, I can push the branch I have it on.
> 
> First I would need to build a GCC which properly supports LTO.

;-)

> Pushing the branch to head would certainly make it easier to test.

I've pushed the 'lto' branch to savannah now, after merging current
master into it.  (I had one more trivial testsuite patch in my master
that I'm pushing to savannah now too.)

Thanks,
Ralf

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

Re: Installing libtool 1.5 and 2.2.6a on Linux at the same time

[Ralf Wildenhues]

Hello Yersinia,

* yersinia wrote on Mon, Sep 06, 2010 at 06:00:40PM CEST:
> A question probably  banal so i apologize in advance but i have not
> found any clue.

It's not a trivial question at all.

> I'm trying to install on Linux(RHEL5) at the same time, as you can do
> with automake and autoconf, libtool 2.2.6a with libtool 1.1.5 on FHS
> directories (with --prefix /usr) . But it is not enough use the -
> program-suffix=-2.2.6 to  configure: libltdbl for example could
> overwrite the library of the e other version. What should I supposed
> to do?

Unfortunately, it does not really work to install different Libtool
versions below the same prefix without further ugliness.  We usually
suggest having separate --prefix values, and installing all of Autoconf,
Automake, and Libtool under each of those prefixes.

You can also use a separate prefix for each of them, but then you might
have to fiddle with adding include directory paths to aclocal such as
with the dirlist feature (info Automake "Macro Search Path").

Another good recommendation is to just not use Libtool 1.5.x or earlier
any more.  There really isn't any good reason for sticking to those
versions except packages that haven't updated yet and need some
adjustment.  For them, if updating is nontrivial please feel free to
post here asking for advice.  We would like those packages to update.

Hope that helps.

Cheers,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST:
> I'm planning to make the belated 2.4 release in about 24 hours.

Great!

> If there is any reason you'd like me to hold off for a bit longer,
> please speak up now!

I don't know of any confirmed regression that we have analyzed and a
patch for.  IOW, anything else can be addressed after the release.

Please send a message to the list though right when you require no more
changes to the tree though; there still the odd testsuite issue or two
in new tests, and while with git, it is not a problem if we push
something while you create the release (in that case you can still merge
origin/master afterwards, instead of rebase origin/master), it would be
nicer to not have this.

Thanks,
Ralf

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

Re: module libposix

[Ralf Wildenhues]

Hi Bruce,

* Bruce Korb wrote on Sun, Sep 19, 2010 at 12:00:37AM CEST:
> I seem to be missing something and can't quite figure it out.
> 
> I get these messages during autoreconf:
> 
> >>build_libposix> autoreconf
> >configure.ac:29: required file `build-aux/ltmain.sh' not found

Use -i to have things installed; or run libtoolize beforehand.

> >libposix/Makefile.am: object `pt_chown.$(OBJEXT)' \
> > created both with libtool and without
> >autoreconf: automake failed with exit status: 1
> 
> My configure.ac looks like this:

> The piece of the Makefile.am that is causing trouble is:
> 
> > ## begin gnulib module pt_chown
> >
> > # TODO: Add rules for installing as setuid root (chown root, chmod 
> > a=rx,u+s).
> > # The next line can be removed once we assume automake >= 1.11.
> > pkglibexecdir = $(libexecdir)/@PACKAGE@
> > pkglibexec_PROGRAMS = pt_chown
> > pt_chown_LDADD = libposix.la
> >
> > EXTRA_DIST += pt_chown.c pty-private.h
> >
> > EXTRA_libposix_la_SOURCES += pt_chown.c

The program pt_chown wants to have pt_chown.$(OBJEXT) compiled without
libtool, and libposix_la wants pt_chown.lo compiled with libtool, and
the latter will also create pt_chown.$(OBJEXT).

You can work around this by letting automake rename one of the two,
which it will do in the presence of, e.g., per-target flags:
  pt_chown_CFLAGS = $(AM_CFLAGS)

See info Automake "Libtool Issues" for more information on both issues.

Cheers,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

> * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST:
> > I'm planning to make the belated 2.4 release in about 24 hours.

> > If there is any reason you'd like me to hold off for a bit longer,
> > please speak up now!

Rainer just confirmed a regression in this thread:

(his latest message hasn't shown up in the archives yet).

I would like to look into it, and try to come up with a fix before the
release.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST:
> Unfortunately, my MinGW testing is not so successful.  The testing
> still quits part-way through with some sort of make-related issue
> (as reported in detail previously).

I don't have that previous report on my radar.  Can you point us to it,
please?

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 08:45:08PM CEST:
> On Sun, 19 Sep 2010, Ralf Wildenhues wrote:
> >* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST:
> >>Unfortunately, my MinGW testing is not so successful.  The testing
> >>still quits part-way through with some sort of make-related issue
> >>(as reported in detail previously).
> >
> >I don't have that previous report on my radar.  Can you point us to it,
> >please?
> 
> This is the situation where the tests quit mid-way like this:
> 
> PASS: tests/depdemo-shared-unst.test
> make[4]: *** No rule to make target `.log', needed by `test-suite.log'.  Stop.
> make[4]: Leaving directory `/home/bfriesen/mingw/libtool-head'
> make[3]: *** [check-TESTS] Error 2
> make[3]: Leaving directory `/home/bfriesen/mingw/libtool-head'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/home/bfriesen/mingw/libtool-head'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/home/bfriesen/mingw/libtool-head'
> make: *** [check] Error 2
> 
> I am not finding this posted to a libtool list so it was probabably
> in off-list discussion among libtool core developers.
> 
> The above is produced today after re-installing MinGW/GCC using the
> latest TDM GCC installer (with GCC 4.5.1).  It is similar to what I
> observed before.  The test suite used to work so I assume that the
> issue is due to some change in the past few months, such as in
> Automake.

Yeah, this is a GNU make 3.80 bug exposed by Automake 1.11, fixed by
Automake 1.11.1, and re-exposed in git Automake (I am working on a fix
that tries to avoid this and another bug about long $(TESTS) on MinGW).

We /could/ work around it in Libtool by making sure the last entry in
$(TESTS) is non-optional.  OTOH, since the release will be done with
Automake 1.11.1, I don't see why we would need to do that.

Thanks for the feedback,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 09:27:08PM CEST:
> On Sun, 19 Sep 2010, Ralf Wildenhues wrote:
> >>The above is produced today after re-installing MinGW/GCC using the
> >>latest TDM GCC installer (with GCC 4.5.1).  It is similar to what I
> >>observed before.  The test suite used to work so I assume that the
> >>issue is due to some change in the past few months, such as in
> >>Automake.
> >
> >Yeah, this is a GNU make 3.80 bug exposed by Automake 1.11, fixed by
> >Automake 1.11.1, and re-exposed in git Automake (I am working on a fix
> >that tries to avoid this and another bug about long $(TESTS) on MinGW).
> 
> The 'make' used is GNU make 3.79.1.

Yeah, that has the same bug.

> There is a 'mingw32-make' which
> is GNU make 3.82, but does not seem to work under MSYS.

That one's not for you, normally.  IIUC it's for the development of, not
with, MSYS.

> I tried building my own GNU make 3.82 under MinGW and the result
> behaves the same as 'mingw32-make'.

When you build stuff yourself, it matters where you install it.  Some
directories are treated specially by the MSYS runtime.  Please see the
MinGW wiki for details.

Anyway, I still don't see why we should care, as long as the Libtool
release is done with Automake 1.11.1 (which our configure.ac ensures).

Cheers,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST:
> On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote:
> > Rainer just confirmed a regression in this thread:
> > <http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html>
> > (his latest message hasn't shown up in the archives yet).
> 
> Okay, nice catch.
> 
> > I would like to look into it, and try to come up with a fix before the
> > release.
> 
> Sure.  Please ping me when you're ready, since I sometimes lag by a
> week or more on mailing list posts depending on other demands on my
> time.

Can I ask for 24 hour delay?  I won't be able to finish this tonight.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Mon, Sep 20, 2010 at 06:35:21PM CEST:
> On 09/18/2010 10:03 PM, Gary V. Vaughan wrote:
> >I'm planning to make the belated 2.4 release in about 24 hours.
> >
> >If there is any reason you'd like me to hold off for a bit longer,
> >please speak up now!
> 
> Can we ship libltdl/m4/autobuild.m4 as a static copy of a decently
> recent autobuild.m4, rather than requiring autobuild to be
> pre-installed where aclocal can find autobuild.m4?  After all, this
> is how coreutils, m4, and the soon-to-be-released autoconf 2.68 do
> things.
> http://git.sv.gnu.org/cgit/autoconf.git/commit/?id=842807af6
> 
> And in doing so, it may ease Chuck's burden in porting libtool 2.4
> to cygwin:
> http://cygwin.com/ml/cygwin-apps/2010-09/msg00121.html

OK with me if it helps that.

Be sure to *not* list autobuild.m4 anywhere else, e.g., in Makefile.am.
It is picked up automatically.  You can make the AB_INIT call in
configure.ac unconditional, but then again, no loss in leaving it as it
is.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Sep 20, 2010 at 01:39:38AM CEST:
> On 9/19/2010 12:57 PM, Charles Wilson wrote:
> > On 9/19/2010 11:45 AM, Bob Friesenhahn wrote:
> >> Unfortunately, my MinGW testing is not so successful.  The testing still
> >> quits part-way through with some sort of make-related issue (as reported
> >> in detail previously).
> > 
> > Odd.  My last test on MinGW was very successful. This was version 1.3266
> > (ef56e98f3 IIRC).  I'll give it another go @ f0584085.
> 
> MinGW/MSYS:
> old -- All 122 tests passed (2 tests were not run)
> new -- 108 tests behaved as expected.  12 tests were skipped.

I'd really appreciate if you guys could send build logs to the autobuild
server as I've been doing lately, much more than just posting
non-verbose results on the list here.

You don't need to have autobuild installed.  When Eric installs
autobuild.m4 you don't need to do anything else.

Here's what I use, more or less, to create the logs:

  ( ../libtool/configure [OPTIONS] \
&& make \
&& make -k check
cat test-suite.log tests/testsuite.log
if tail tests/testsuite.log | grep '^| ' >/dev/null; then :; else
  sed 's/^/| /' config.log
fi
  ) > logfile

  $sanitize logfile
  mail libtool_autobuild.josefsson.org < logfile

with the underscore replaced by @.  For now, OPTIONS includes
autobuild_mode=bla if there is anything special about the build.

Cheers,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Mon, Sep 20, 2010 at 07:53:15PM CEST:
> On Mon, 20 Sep 2010, Ralf Wildenhues wrote:
> >
> >I'd really appreciate if you guys could send build logs to the autobuild
> >server as I've been doing lately, much more than just posting
> >non-verbose results on the list here.
> >
> >You don't need to have autobuild installed.  When Eric installs
> >autobuild.m4 you don't need to do anything else.
> 
> No autobuild.m4 here.  Only heard mention of it in the past couple
> of days.  I don't know what it is.

And when that patch is in, you *don't* need to know.  Just wait for the
commit, git fetch && git rebase, profit.

> > $sanitize logfile
> > mail libtool_autobuild.josefsson.org < logfile
> 
> Most systems I test on have no email access.  Certainly I would not
> trust a Windows PC dedicated to testing with the ability to send
> email.

So?  Send it from any other system.  Certainly you will have some way to
transfer data from or to that PC.

> Shouldn't there be a username component to that email address?

Well, in the part of my email that you clipped, I explained the mangling
that I used.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Mon, Sep 20, 2010 at 02:17:34AM CEST:
> On Sep 20, 2010, at 3:18 AM, Ralf Wildenhues  wrote:
> > * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST:
> >> On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote:
> >>> <http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html>

> >>> I would like to look into it, and try to come up with a fix before the
> >>> release.
> >> 
> >> Sure.  Please ping me when you're ready, since I sometimes lag by a
> >> week or more on mailing list posts depending on other demands on my
> >> time.

I'm ready, in the sense that I think
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5886/focus=7559>
fixes this issue, passes tests for me, needs feedback and approval,
and that otherwise, the only pending regression is:
<http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10713/focus=10740>

Cheers,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 03:21:55AM CEST:
> On 22 Sep 2010, at 05:02, Charles Wilson wrote:
> > Peter Rosin wrote:
> >> Just a friendly ping, but only just now I pushed a change to the
> >> 'compile' script in automake and would like the new version in
> >> the release if it's not too much to ask for.  Thanks!
> > 
> > Errr...is that kosher?  I thought libtool was only supposed to ship the
> > scripts provided by released versions of automake, not git head
> > copies...

No.  See Makefile.maint, where the 'fetch' target explicitly fetches the
git master copies of some scripts, including 'compile'.  As long as you
run fetch after bootstrap, there is no need for you to do anything else
at all.

You should not need to use git Automake for this, and please don't,
because it currently carries a small regression over 1.11.1.  I'll
fix it ASAP, but just haven't had the time for it yet.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Charles Wilson wrote on Wed, Sep 22, 2010 at 12:10:39AM CEST:
> On 9/20/2010 1:41 PM, Ralf Wildenhues wrote:
> > I'd really appreciate if you guys could send build logs to the autobuild
> > server...
> > Here's what I use, more or less, to create the logs:

> See, that's what was missing.  You had asked about a month ago for me to
> save all the logs from my various tests...but I had no idea what to DO
> with them.  Anyway, those are all a month out of date, so I'll test the
> 2.4 release on those platforms and submit new reports.

Even sending out of date logs is worthwhile.

> We should probably create some sort of reporting script (post 2.4, of
> course) and mention it (and its usage) in HACKING.  Perhaps also in the
> message you get at the end of the new testsuite when there are failing
> tests.

Yes.  All on the TODO list for after this release.

Thanks,
Ralf

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

Re: 2.4 Release in 24hrs

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:42:53AM CEST:
> 
> On 22 Sep 2010, at 11:29, Ralf Wildenhues wrote:
> > You should not need to use git Automake for this, and please don't,
> > because it currently carries a small regression over 1.11.1.
> 
> Ah, okay.  If it was taken care of by fetch already, then there was
> no need for Peter to ping me :)

I made Peter do it, in case you already started in the HACKING list,
as the update to 'compile' might not have otherwise shown up as git
changes in Libtool at all.

Sorry for the resulting confusion, all mine.

> Thanks for the heads up before releasing with 1.11a though.

Cheers,
Ralf

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

autobuild results (was: 2.4 Release in 24hrs)

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Thu, Sep 23, 2010 at 08:54:43AM CEST:
> Den 2010-09-20 19:41 skrev Ralf Wildenhues:
> > I'd really appreciate if you guys could send build logs to the autobuild
> > server as I've been doing lately, much more than just posting
> > non-verbose results on the list here.
[...]
> > Here's what I use, more or less, to create the logs:

> >   mail libtool_autobuild.josefsson.org < logfile
> > 
> > with the underscore replaced by @.  For now, OPTIONS includes
> > autobuild_mode=bla if there is anything special about the build.
> 
> If I do post there, will a human (you?) or a robot process the mail?

A robot will periodically (once an hour?) process mails, deleting
anything not carrying the autobuild signature, and creating the
overview web page that links to all logs from the rest.  Details at
<http://autobuild.josefsson.org/README.html>.

I'm mostly interested in collecting a large number of samples in order
to be able to pinpoint regressions more easily at a later stage.  For
this reason, and because Simon garbage-collects logs older than 24 days,
I'm probably going to start mirroring all posted logs to my hard drive
eventually.  Hopefully this can be improved somehow at a later stage,
when the service has moved to savannah.

> Is the Subject: important?

No.

> I have plans to soon mail output from the v2.4 tag with OPTIONS as
> below on MSYS:
*snip*

That looks all fine to me.  Thanks!

Cheers,
Ralf

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

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

Hello t7,

* t66...@gmail.com wrote on Thu, Sep 23, 2010 at 03:01:31AM CEST:
> I don't know if my problem suites this description.

No, it doesn't.

> Currently installed libtool on this system is,
> ltmain.sh (GNU libtool) 2.2.6b
> 
> I recently tested the LTO feature of GCC (targeting windows) and I
> found it was unable to link due to the presence of duplicating lines
> of *crt* without compiling with -flto there were not such issues.
> 
> It seems that libtool is emitting dllcrt2, crtbegin, crtend all over
> again after the first crtend. In the following line.
> g++ lib64/dllcrt2.o lib64/crtbegin.o ...
> _alot_of_other_link_arguments_ ... lib64/crtend.o lib64/dllcrt2.o
> lib64/crtbegin.o lib64/crtend.o
> These last three duplicating .o arguments are causing errors.
> lib64/dllcrt2.o:crtdll.c:(.text+0x50): multiple definition of `_CRT_INIT'
> lib64/dllcrt2.o:crtdll.c:(.text+0x50): first defined here
> Is this a know issue?

You may have found a bug, or not, I cannot tell from the sparse
description you've given.  Please write to the bug-libtool at gnu.org
mailing list (no subscription required) with full details about which
GCC and Libtool versions you are using, after updating Libtool to 2.4 if
you are trying to use LTO with it, write how you configured the software
that fails to link, and please post the complete 'libtool --mode=link'
command that fails, including all of its output.

Then we will see further.  On the odd chance of turning up a new GCC
bug, we'll report back to the GCC bugzilla then.  But until then there
is no need to cross-post this to the GCC development mailing list.

Thank you.

Cheers,
Ralf

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

Re: Multi lib 32 bits support

[Ralf Wildenhues]

Hello t7,

please consider using the bug-libtool list for bug reports and a real
name for posting, that is considered friendly.  Thanks.

* t66...@gmail.com wrote on Thu, Sep 23, 2010 at 11:11:34AM CEST:
> The new released libtool 2.4 fixed my compilation problem while
> linking a dll with code compiled with -flto.

Ah ok.  Good.

> Now I have new problem with 32-bit.
> 
> I think libtool 2.4 breaks multi-lib 32-bit.
> For 64-bit it was ok.
> Also I didn't notice this error while using older libtool came with the o/s.
> ltmain.sh (GNU libtool) 2.2.6b
> 
> At link time it used gcc to link a *.c object file but failed to
> pick the right path to the correct library.
> 
> It picked up lib/gcc/x86_64-w64-mingw32/4.5.2/libstdc++.a
> instead of picking up lib/gcc/x86_64-w64-mingw32/4.5.2/32/libstdc++.a

Please post the output of './libtool --tag=CXX --config'.  Thanks.

Cheers,
Ralf

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

Re: autobuild results

[Ralf Wildenhues]

Good morning Peter,

* Peter Rosin wrote on Thu, Sep 23, 2010 at 10:40:48PM CEST:
> Den 2010-09-23 20:05 skrev Ralf Wildenhues:
> >> I have plans to soon mail output from the v2.4 tag with OPTIONS as
> >> below on MSYS:
> > *snip*
> > 
> > That looks all fine to me.  Thanks!

> Ok, done, and they appeared just fine on the site too. Since you said
> you were going to collect them, would you want a bcc for future dumps?

As long as I know there are logs to collect, that's not necessary.

Thanks,
Ralf

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

Re: bogus warning 'seems to be moved'

[Ralf Wildenhues]

Hello Marco,

thanks for the bug report.

* Marco Atzeri wrote on Wed, Sep 22, 2010 at 10:49:56AM CEST:
> is this bogus warning avoidable in the next release ?
>  
> libtool: link: warning: 
> `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be 
> moved
> libtool: link: warning: 
> `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved
> ...
>  
> as the files are
>  
> /usr/lib/libfontconfig.la
> /usr/lib/libexpat.la
> ..
> 
> the *.la files did not moved at all
>  
> $ libtool --version
> libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a
> 
> on cygwin-1.7.x

I agree that it is likely that the warning is bogus in your specific
case.  All other messages in this thread so far have been about slightly
different cases; ignore them.

To be sure however, please send the full 'libtool --mode=link' command
that caused the above warnings, plus all of its output.  I'll put fixing
this on my TODO list then.

Thanks,
Ralf

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

Re: GNU Libtool 2.4 released [stable]

[Ralf Wildenhues]

Hello Alon,

* Alon Bar-Lev wrote on Sat, Sep 25, 2010 at 10:53:36AM CEST:
> > - Sysroot support. This allows you to build cross-compiled packages
> > with the same prefix that will be used on the destination machine,
> > and still find dependent libraries under the compiler's "sysroot".
> > Without sysroot support, paths internal to the build system may leak
> > into the product of the build.
> >
> > Sysroot support is disabled unless the --with-sysroot configure
> > option is passed to configure, because .la files generated with
> > sysroot support will not be usable in general with older Libtools.
> 
> This is great news!
> Can you please explain how this feature works?

Really good question.  We didn't manage to update the documentation in
time.  :-(

You pass '--with-sysroot $sysroot' to configure.  This should enable the
machinery.

> I see '=' is added to the prefix of .la files.
> This suggests *ALL* packages compiled into sysroot must be migrated to
> libtool 2.4.

Well, not necessarily.  'libtool --mode=finish' has new functionality to
remove the '=' prefixes from libraries passed to it explicitly.  Of
course, at that point, the .la files are not suitable for use in the
sysroot any more, just on the final system.

> Also, why not take the value of the sysroot from the DESTDIR automake 
> variable?

Because we know DESTDIR far too late, only at 'make install' time and
not yet at the time we link against dependent libraries (that may
already be installed below the sysroot).

Hope that helps.  And yes, we really should fix the documentation for
2.4.2.

Cheers,
Ralf

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

Libtool 2.4 and APR (was: GNU Libtool 2.4 released [stable], yet might not be an immediate) drop in replacement for version 2.2.10

[Ralf Wildenhues]

Hello Kyle,

please don't top-post, thanks.

* Kyle Sallee wrote on Sat, Sep 25, 2010 at 03:52:28PM CEST:
> Also I noticed that httpd version 2.2.16
> failed compilation with libtool version 2.4 installed
> Compile log looks like:
> 
> found apr source: srclib/apr
> found apr-util source: srclib/apr-util
> rebuilding srclib/apr/configure
> buildconf: checking installation...
> buildconf: python version 2.6.6 (ok)
> buildconf: autoconf version 2.68 (ok)
> buildconf: libtool version 2.4 (ok)
> Copying libtool helper files ...
> /libtool.m4 not found
> ./buildconf failed for apr
> 
> Merely re-installing libtool version 2.2.10
> enabled compilation of httpd.

Thanks for the report.  This is not enough information for me to
analyze the issue, however.

> This problem was repeatable on both IA32 i686 linux + glibc
> and x86_64 linux + glibc.
> That is why I am providing only the limited information above,
> because someone who is eager and able to debug this
> should be able to easily replicate the error.

I am sorry, but I *really* don't have the time to go find the
installation and building instructions of all kinds of third-party
packages using Libtool (not even important ones such as APR) each
time someone posts a vague bug report.  Just finding out what you did
would probably cost me an hour or so, multiply that by the several such
requests each week.

If you want help, then you need to provide us with simple instructions
on how to build the software and reproduce the issue you are seeing.
That's the difference between me going to ignore the bug report right
away, or maybe trying to look into it.

Thanks,
Ralf

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

Re: Inherited linker flags

[Ralf Wildenhues]

Hello Sam,

* Sam Varshavchik wrote on Sun, Sep 26, 2010 at 05:57:43AM CEST:
> By doing some experimenting, I found that that everything appears to
> work nicely, if I put "-Wl,--undefined=Y" into liby.la's
> inherited_linker_flags setting. This apparently carries no impact
> when "sharedly" linking against liby.la. And when statically linking
> liby.la the undefined symbol forces the inclusion of Y's module into
> P, and resolving the weak reference from libx.
> 
> I could, of course, do the same thing by explicitly specifying the
> extra linker flag in Makefile.am in P's LDFLAGS. Having this flag in
> a .la file has the nice effect of libtool automatically handling
> this. It goes without saying that the whole thing works only on
> platforms where gcc and binutils have weak references.

There is currently no way to get arbitrary flags into the
inherited_linker_flags variable, except patching the file afterwards.

Please note that the flags are carried over to any library linking
(directly or indirectly) against liby.la, which may or may not be what
you intended.

Please also note that this may make the .la file linker-dependent (in
case your users use more than linker on their system, with different
--undefined API).  For the specific example, the risk seems fairly low,
however.  The clean way would be to add to P's LDFLAGS.

Cheers,
Ralf

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

Re: Inherited linker flags

[Ralf Wildenhues]

Sorry for the off-list post, but Sam's MTA doesn't like the one from my
provider's:

| Hi. This is the qmail-send program at mail.gmx.net.
| I'm afraid I wasn't able to deliver your message to the following addresses.
| This is a permanent error; I've given up. Sorry it didn't work out.
| 
| :
| 
Connected_to_216.254.115.190_but_sender_was_rejected./Remote_host_said:_517_HELO_mail.gmx.net_does_not_match_:::213.165.64.22/

If it can't be fixed, please set your mailer to set Mail-Followup-To: to
the list address only, thanks.

Cheers,
Ralf

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

Re: GNU Libtool 2.4 released [stable]

[Ralf Wildenhues]

Hello Alon,

* Alon Bar-Lev wrote on Mon, Sep 27, 2010 at 03:41:36PM CEST:
> On Sun, Sep 26, 2010 at 7:17 AM, Ralf Wildenhues wrote:
> >> Also, why not take the value of the sysroot from the DESTDIR automake 
> >> variable?
> >
> > Because we know DESTDIR far too late, only at 'make install' time and
> > not yet at the time we link against dependent libraries (that may
> > already be installed below the sysroot).
> 
> But you do relink the libraries when 'make install' is executed.

Yes, that requirement has not gone away.

> So why not relink it with proper sysroot?

I'm not sure I understand the question.  Care to post a small example
that shows what you mean, that goes wrong, and what you would have
expected instead?

Thanks,
Ralf

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

Re: bindir.at takes forever.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Tue, Sep 28, 2010 at 02:28:48PM CEST:
> I have been looking at the loops in tests/bindir.at and I see
> this:

bindir.at has several problems.  First, the first
AT_SETUP/.../AT_CLEANUP is completely redundant, it can just be removed.

Then, the actual tests are broken, in that they fail on AIX, and they
don't test quite the right thing practically everywhere, but in
different variations, i.e., they are sometimes too strict and sometimes
too lax.  I didn't get a half-patch finished and tested before 2.4,
and haven't gone back to it since.  I'm not actually sure whether my
changes are too lax.

>   for bindir in \
>   $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
[...]
>   $curdir/bin \
>   /tmp/foo/bar ;
>   do
> 
>  ...
> 
>   done
> 
> Is it really necessary to check *all* components with the trailing slash?
> And do we really need to test so many levels?

I would think not.  The overhead comes from the double loop with lots
of iterations (like stresstest).  Let's cut down the list to something
manageable, just be sure the cases documented in the test comments are
still executed.

For reference, I've copied the unfinished patches below.  Feel free to
try them out/fixup the second one; it still needs testing on AIX, too.

I just realize there is an 'exit 77' in an unneeded subshell and another
one outside of AT_CHECK which needs fixing, too.

Thanks,
Ralf

tests: remove unneeded 'bindir compile check' test.

* tests/bindir.at (bindir compile check): Remove.

diff --git a/tests/bindir.at b/tests/bindir.at
index 40e67cc..ebe1baa 100644
--- a/tests/bindir.at
+++ b/tests/bindir.at
@@ -1,6 +1,6 @@
 # bindir.at -  Test the -bindir option
 #
-#   Copyright (C) 2009 Free Software Foundation, Inc.
+#   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
 #   Written by Dave Korn, 2009
 #
 #   This file is part of GNU Libtool.
@@ -58,25 +58,8 @@
 # statement in libtool.m4sh around where the 'tdlname' variable is set.
 
 
-# Verify compiling works, and skip remaining tests if not.
-#
-
-AT_SETUP([bindir compile check])
-
-AT_DATA([simple.c] ,[[
-int main() { return 0;}
-]])
-
-$CC $CPPFLAGS $CFLAGS -o simple simple.c || noskip=false
-rm -f simple
-
-AT_CHECK([$noskip || (exit 77)])
-
-AT_CLEANUP
-
-
-# Now run the tests themselves.  First a simple test that we can
-# build and run an executable with a couple of tiny libraries.
+# First a simple test that we can build and run an executable with a couple of
+# tiny libraries.
 
 AT_SETUP([bindir basic lib test])
 



Fix bindir check logic, and relax non-bindir case for AIX.

* tests/bindir.at (bindir install tests): Rewrite checks for
place of the installed shared library in two separate tests,
depending on whether -bindir is supposed to have an effect or
not.  In the positive case, make the test stricter so that we
reject libraries in $libdir.  In the negative case, do not
require a major version number in the $libdir file name, for
AIX without runtimelinking.

diff --git a/tests/bindir.at b/tests/bindir.at
index ebe1baa..5e4c534 100644
--- a/tests/bindir.at
+++ b/tests/bindir.at
@@ -138,14 +138,14 @@ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o 
main$EXEEXT $CPPFLAGS $CFLAGS $LD
 # here, that will be covered by the later tests; we've rpath'd things
 # so that they can all be run in situ.
 
-LT_AT_NOINST_EXEC_CHECK([$LIBTOOL], [], [0], [ignore], [ignore], 
[--mode=execute ./main$EXEEXT])
+LT_AT_NOINST_EXEC_CHECK([./main])
 
 # Ensure libraries can be found on PATH, if we are on one
 # of the affected platforms, before testing the shared version.
 
 func_save_and_prepend_path $curdir/$objdir
 $bindirneeded && {
-  LT_AT_NOINST_EXEC_CHECK([$LIBTOOL], [], [0], [ignore], [ignore], 
[--mode=execute $objdir/main$EXEEXT])
+  LT_AT_NOINST_EXEC_CHECK([$objdir/main])
 }
 
 #  In fact, prepending the PATH as above is superfluous on the windows
@@ -275,7 +275,11 @@ do
   # 'libfoo-0.dll', or 'libfoo.so.0'.  We'll simplify this check by taking 
advantage
   # of the fact that if it's a DLL, it has to go in bindir, so we'll not check 
for
   # both forms in libdir.
-  AT_CHECK([$bindirneeded && { test -f $libdir/../bin/???foo-0.dll || ls 
$libdir/../bin/*foo*0* 2>/dev/null ; } || ls $libdir/*foo*0* 2>/dev/null], [], 
[ignore], [ignore])
+  if $bindirneeded; then
+AT_CHECK([test -f $libdir/../bin/???foo-0.dll || ls 
$libdir/../bin/*foo*0*], [], [ignore], [ignore])
+  else
+AT_CHECK([ls $libdir/*foo*], [], [ignore], [ignore])
+  fi
 
   # And that it can be executed.
   extrapath=
@@ -343,7 +347,11 @@ do
 AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
$curdir/sbin/main$EXEEXT], [], [ignore], [ignore])
 
 # Ensure it went to bindir rather than default dir this time.
-AT_CHECK([$bindirneeded && { test -f $bindir/???foo-0.dll || ls 
$bindir/*foo*0* 2>/dev/null ; } || ls $libdir/*foo*0* 2>/dev/null], [], 
[ignore], [ignore])
+if $bindirnee

Re: libtool 2.2.10: What is the correct library naming convention

[Ralf Wildenhues]

Hello Joost,

* Joost Kraaijeveld wrote on Wed, Sep 29, 2010 at 10:46:09PM CEST:
> I have asked this question before, but I got no answer. If I asked it
> the wrong or impolite way: sorry and please forgive me.

No, it's simply that we don't have the manpower to address all bug
reports in a timely manner, or even all bug reports at all; sorry.

> For instance, when ld is called with the argument `-lxxx' it will
> attempt to find, in the first directory of its search path, 
> 
>   libxxx.dll.a
> xxx.dll.a
> libxxx.a
> xxx.lib
> cygxxx.dll (*)
> libxxx.dll
> xxx.dll
> 
> But it appears that libtool insists that is *must* be called libxxx.dll
> or otherwise the library is not found. Which is rather annoying because
> several other packages do not use the lib prefix.

Right.  libtool should be detecting those without a prefix, and probably
also those with a different one.  One place in the current code that is
wrong is this in ltmain:

  for searchdir in $searchdirs; do
for search_ext in .la $std_shrext .so .a; do
  # Search the libtool library
  lib="$searchdir/lib${name}${search_ext}"

Just removing .so on systems where it's irrelevant (or = $std_shrext)
should help efficiency (as this is a fairly tight inner loop).  We'd
need to look up whether there are systems accepting .so but have
something different set in $shrext_cmds.

But of course more importantly, other names should be detected as well.


I think one possible approach would be to allow here more general
libname_formats (set in libtool.m4) that for w32 could list the above
possibilities (taking into account std_shrext of course).  This could
help a couple of other systems as well (yes, darwin, I'm looking at
you).

A good way to test this would be to create installed libraries with each
of the above naming convention (on suitable systems only, of course),
then remove .la files and the like, and link against them as you would.

Any takers?

Thanks,
Ralf

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

Re: libtool and LTO

[Ralf Wildenhues]

Hello Andi, Bob,

* Bob Friesenhahn wrote on Tue, Oct 05, 2010 at 12:30:51AM CEST:
> On Mon, 4 Oct 2010, Andi Kleen wrote:
> 
> >I discovered that libtool breaks gcc LTO (link time optimization)
> >
> >Is there a solution or a workaround known?
> >
> >I'm using libtool 2.2.6b
> 
> Maybe you should use libtool 2.4?

Yep, 2.4 should work with GCC LTO in every way *except* when partial
linking is involved in the process.  The latter should generally only
happen when command line length limits are exceeded.  We didn't try to
work around the 'ld -r' case because IIUC gold was going to be enhanced
to also support this OOTB (right?).

Getting Libtool 2.4 into GCC before 4.6 is on my list, by the way.

> [...] if you are using Automake I
> have heard that there are some fixes in development Automake which
> are needed/useful for -flto.

I'm not aware of fixes needed in Automake.  Care to point them out?

Thanks,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

Hello Ethan,

* Ethan Mallove wrote on Fri, Oct 08, 2010 at 02:42:53PM CEST:
> I'm trying to create a library which has no shared library
> dependencies using the Intel compilers, but it appears Libtool might
> be automatically adding in some -lfoo flags that are forcing the
> issue.  How can I tell Libtool to not add the -lfoo flags?

Which libraries are added?  Which of those would you like to avoid?
Please show a 'libtool --mode=link' command line and its output.

libtool normally adds all direct and indirect library dependencies
(the latter only when link_all_deplibs is true, which it currently is
everywhere except in the Debian-modified libtool), as well as compiler
support libraries.  The indirect deplibs is an obvious issue for at
least distributors, the rest is usually the right thing to do.

Cheers,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

* Ethan Mallove wrote on Fri, Oct 08, 2010 at 07:26:45PM CEST:
> On Fri, Oct/08/2010 07:14:18PM, Ralf Wildenhues wrote:
> > * Ethan Mallove wrote on Fri, Oct 08, 2010 at 02:42:53PM CEST:
> > > I'm trying to create a library which has no shared library
> > > dependencies using the Intel compilers, but it appears Libtool might
> > > be automatically adding in some -lfoo flags that are forcing the
> > > issue.  How can I tell Libtool to not add the -lfoo flags?
> > 
> > Which libraries are added?  
> 
> libimf and friends.
> >
> > Which of those would you like to avoid?
> 
> If possible, all of the Intel runtime libraries (e.g., libimf,
> libsvml, libintlc).

> > libtool normally adds all direct and indirect library dependencies
> > (the latter only when link_all_deplibs is true, which it currently is
> > everywhere except in the Debian-modified libtool), as well as compiler
> > support libraries.  The indirect deplibs is an obvious issue for at
> > least distributors, the rest is usually the right thing to do.
> > 
> 
> So if I set "link_all_deplibs" to "false", will that turn off the
> "-limf -lsvml ..." we're seeing in the link line?

Nope.

Does running the link command with --tag=CC "fix" that, i.e., avoid the
libraries for you?

Maybe we should just make postdeps et al overridable with a cache
variable.

Thanks,
Ralf

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

Re: somewhat misleading -no-undefined documentation

[Ralf Wildenhues]

[ adding libtool-patches ]

Hi Matěj,

* Matěj Týč wrote on Sun, Oct 03, 2010 at 12:12:00AM CEST:
> I have thought so far that if you want to make a DLL, you can't get
> involved with any other library, because libtool needs -no-undefined
> flag in order to make DLLs and you are supposed to use it only if the
> library is self-contained.
> I was quite surprised when I have cheated libtool, supplied the
> -no-undefined parameter and it worked although I thought that it
> shouldn't and after some investigation, I have stumbled across an old
> mailing list thread, where another person had the same issue:
> http://lists.gnu.org/archive/html/libtool/2006-03/msg00012.html
> Having looked at the documentation thoroughly, I had to admit that the
> documentation is correct, but if you try to read through it quickly, it
> is likely that you leave with the impression expressed in the beginning
> of this e-mail.
> Therefore I suggest that you stress this in the documentation, feel free
> to use this patch (there is also a patch if you look at the old
> message).

Thanks for the report and patch.

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1517,7 +1517,8 @@ of library paths.  Useful if the program is only
> used in the build tree,
>  e.g., for testing or generating other files.
>  
>  @item -no-undefined
> -Declare that @var{output-file} does not depend on any other libraries.
> +Declare that @var{output-file} does not depend on any other libraries
> +in the sense that after linking it will not have any unresolved
> symbols.
>  Some platforms cannot create shared libraries that depend on other
>  libraries (@pxref{Inter-library dependencies}).

This isn't quite right yet, because it may be misinterpreted in a way
that symbols may not even be resolved to dependent libraries.  I don't
think we support such systems any more, if there still are any more of
them out there.

> @@ -3263,7 +3264,8 @@ library systems and simple dynamic library
> systems.
>  
>  Some platforms, such as AIX, do not even allow you this
>  flexibility.  In order to build a shared library, it must be entirely
> -self-contained (that is, have references only to symbols that are found
> +self-contained or it must have dependencies known at the link time
> +(that is, have references only to symbols that are found
>  in the @file{.lo} files or the specified @samp{-l} libraries), and you
>  need to specify the @option{-no-undefined} flag.  By default, libtool
>  builds only static libraries on these kinds of platforms.

Good point.

I kinda like Simon's patch you referenced (wow, that's old!), so how
about this patch which takes from both your suggestions?
(I'm attributing this to Simon because he got it started, for lack of a
better way to specify multiple authors in a git commit.)

Thanks,
Ralf

2010-10-09  Simon Josefsson  
Matěj Týč 
Ralf Wildenhues  

docs: improve description of -no-undefined.
* doc/libtool.texi (Link mode): Fix -no-undefined description.
(Inter-library dependencies): Use Windows not AIX as example
system.  Clarify need for symbol resolution at library creation
time.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..076b67b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1517,9 +1517,12 @@ of library paths.  Useful if the program is only used in 
the build tree,
 e.g., for testing or generating other files.
 
 @item -no-undefined
-Declare that @var{output-file} does not depend on any other libraries.
-Some platforms cannot create shared libraries that depend on other
-libraries (@pxref{Inter-library dependencies}).
+Declare that @var{output-file} does not depend on any libraries other
+than the ones listed on the command line, i.e., after linking, it will
+not have unresolved symbols.  Some platforms require all symbols in
+shared libraries to be resolved at library creation (@pxref{Inter-library
+dependencies}), and using this parameter allows @command{libtool} to
+assume that this will not happen.
 
 @item -o @var{output-file}
 Create @var{output-file} from the specified objects and libraries.
@@ -3261,12 +3264,13 @@ in order to guarantee that all the required libraries 
are found.  This
 restriction is only necessary to preserve compatibility with static
 library systems and simple dynamic library systems.
 
-Some platforms, such as AIX, do not even allow you this
+Some platforms, such as Windows, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
-self-contained (that is, have references only to symbols that are found
-in the @file{.lo} files or the specified @samp{-l} libraries), and you
-need to specify the @option{-no-undefined} flag.  By default, libtool
-builds only static libraries on these kinds of platforms.
+self-co

Re: LT_INIT pic-only not setting --with-pic

[Ralf Wildenhues]

Hi Luke,

* Luke Mewburn wrote on Mon, Oct 11, 2010 at 05:52:16AM CEST:
> I'm using libtool (and the other autotools) to build an installed
> static library (which I don't want it as a shared library),
> which I link into various other applications.
> 
> I sometimes need to link this static library into a dynamic
> object, such as a python module, and so we need the static
> library compiled as PIC.

You could make it a convenience archive, and install it with a manually
written install rule (both the libconv.la and libconv.a).

> Recently, I started getting libtool failures trying to build
> the shared python module, complaining about the missing PIC
> support.  I had made a few changes to our build infrastructure,
> including:
>  - upgrade from libtool 2.2.10 to libtool 2.4
>  - explicit use of LT_INIT in configure.ac
>  - conversion from use of foo_LDADD = -static in Makefile.am
>to LT_INIT([disable-shared])
> and one of these stopped the PIC compilation of the objects.
> I speculate it was the use of disable-shared versus the previous
> behaviour where I was getting implicit PIC support in the normal
> build.
> 
> As a solution, I tried LT_INIT([disable-shared pic-only]),
> but that did not seem to set --with-pic as I expected.
> 
> My current workaround is to explicitly invoke configure --with-pic
> in the package build framework.
> 
> Is LT_INIT([disable-shared pic-only]) not setting --with-pic
> a bug in libtool, or my misunderstanding of its purpose?

I think that's a semantic difference in the LT_INIT interface vs. the
previous one.  Can you show your old code, or a reduced version of it?

Thanks,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

Hello Ethan,

* Ethan Mallove wrote on Mon, Oct 11, 2010 at 01:59:20PM CEST:
> On Fri, Oct/08/2010 02:24:26PM, Robert Boehne wrote:
> >I think the mode=compile line doesn't tell us much about what happens 
> > when
> >mode=link - post what you get on the "libtool --mode=link" command.
> 
> $ /bin/sh ../../../libtool  --tag=CXX   --mode=link icpc  -O3 -DNDEBUG -Wall 
> -static-intel -m32 -finline-functions -fexceptions -pthread -version-info 
> 0:0:0 -export-dynamic  -fexceptions  -o libmpi_cxx.la -rpath /o
> pt/SUNWhpc/HPC9.0/intel/instrument/lib mpicxx.lo intercepts.lo comm.lo 
> datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl  -lutil
> libtool: link: icpc -shared  .libs/mpicxx.o .libs/intercepts.o .libs/comm.o 
> .libs/datatype.o .libs/win.o .libs/file.o   -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath 
> -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib -Wl,-rpath -W
> l,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib 
> ../../../ompi/.libs/libmpi.so -lnsl -lutil 
> -L/ws/ompi-tools/intel/Compiler/11.0/084/lib/ia32 
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -L/usr/li
> b/gcc/x86_64-redhat-linux/4.1.2/ 
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../ -L/lib/ -L/usr/lib -limf 
> -lsvml -lm -lipgo -ldecimal -lstdc++ -lpthread -lirc -lgcc_s -lirc_s -ldl -lc 
>  -m32 -pthread   -pthread
>  -Wl,-soname -Wl,libmpi_cxx.so.0 -o .libs/libmpi_cxx.so.0.0.0

Thanks.  Now, please rerun that command manually, but with --tag=CXX
replaced by --tag=CC.  Post command plus output.

Thanks,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

* Ethan Mallove wrote on Mon, Oct 11, 2010 at 08:11:19PM CEST:
> On Mon, Oct/11/2010 07:51:20PM, Ralf Wildenhues wrote:
> > * Ethan Mallove wrote on Mon, Oct 11, 2010 at 01:59:20PM CEST:
> > > $ /bin/sh ../../../libtool  --tag=CXX   --mode=link icpc  -O3 -DNDEBUG 
> > > -Wall -static-intel -m32 -finline-functions -fexceptions -pthread 
> > > -version-info 0:0:0 -export-dynamic  -fexceptions  -o libmpi_cxx.la 
> > > -rpath /o
> > > pt/SUNWhpc/HPC9.0/intel/instrument/lib mpicxx.lo intercepts.lo comm.lo 
> > > datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl  -lutil
> > > libtool: link: icpc -shared  .libs/mpicxx.o .libs/intercepts.o 
> > > .libs/comm.o .libs/datatype.o .libs/win.o .libs/file.o   -Wl,-rpath 
> > > -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib 
> > > -Wl,-rpath -W
> > > l,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib 
> > > ../../../ompi/.libs/libmpi.so -lnsl -lutil 
> > > -L/ws/ompi-tools/intel/Compiler/11.0/084/lib/ia32 
> > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -L/usr/li
> > > b/gcc/x86_64-redhat-linux/4.1.2/ 
> > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../ -L/lib/ -L/usr/lib 
> > > -limf -lsvml -lm -lipgo -ldecimal -lstdc++ -lpthread -lirc -lgcc_s 
> > > -lirc_s -ldl -lc  -m32 -pthread   -pthread
> > >  -Wl,-soname -Wl,libmpi_cxx.so.0 -o .libs/libmpi_cxx.so.0.0.0
> > 
> > Thanks.  Now, please rerun that command manually, but with --tag=CXX
> > replaced by --tag=CC.  Post command plus output.
> 
> $ /bin/sh ../../../libtool --tag=CC --mode=link icpc -O3 -DNDEBUG -Wall 
> -static-intel -m64 -finline-functions -fexceptions -pthread -version-info 
> 0:0:0 -export-dynamic -fexceptions -o libmpi_cxx.la -rpath 
> /opt/SUNWhpc/HPC9.0/intel/instrument/lib/lib64 mpicxx.lo intercepts.lo 
> comm.lo datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl -lutil
> libtool: link: rm -fr  .libs/libmpi_cxx.la .libs/libmpi_cxx.lai 
> .libs/libmpi_cxx.so .libs/libmpi_cxx.so.0 .libs/libmpi_cxx.so.0.0.0
> libtool: link: icc -shared  .libs/mpicxx.o .libs/intercepts.o .libs/comm.o 
> .libs/datatype.o .libs/win.o .libs/file.o   -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath 
> -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64 -Wl,-rpath -Wl,$ORIGIN 
> -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64 
> ../../../ompi/.libs/libmpi.so -ldl -lnsl -lutil  -m64 -pthread   -pthread 
> -Wl,-soname -Wl,libmpi_cxx.so.0 -o .libs/libmpi_cxx.so.0.0.0

This doesn't have the libraries you don't want, AFAICS.  So a workaround
(using internal details, but fairly safe) would be to use
  libmpi_cxx_la_LIBTOOLFLAGS = --tag=CC

Note however that you get to keep the pieces when this breaks.

Cheers,
Ralf

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

Re: [RFC] w32 and Libtool.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
> Can you spot any errors?

See below.  I've only checked for things obvious to me; I hope somebody
else verifies the w32 semantics and details.  ;-)

Thanks for writing this!

> (I have not actually tested the code samples. Yet)

Thanks in advance!  :-)

> Windows DLLs.
> -
> 
> This topic describes a couple of ways to portably create Windows Dynamic
> Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools

Two spaces after period.

> and using Microsoft tools.
> 
> A typical library has a "hidden" implementation with an interface
> described in a header file. On just about every system, the interface
> could be something like this:
> 
> Example foo.h:
> 
> #ifndef FOO_H
> #define FOO_H
> 
> int one (void);
> int two (void);
> extern int three;
> 
> #endif /* FOO_H */
> 
> And the implementation could be something like this:
> 
> Example foo.c:
> 
> #include "foo.h"
> 
> int one (void)
> {
>   return 1;
> }
> 
> int two (void)
> {
>   return 2;
> }
> 
> int three = 3;

Isn't this less-than fully general, in the sense that having in addition
references to one and three from within two would possibly be more
complex to handle?

> When using contemporary GNU tools to create the Windows DLL, the above
> code will work there too, thanks to its auto-import/auto-export
> features. But that is not the case when using older GNU tools or perhaps
> more interesting when using proprietary tools. In those cases the code
> will need additional decorations on the interface symbols with
> __declspec(dllimport) and __declspec(dllexport) depending on if the
> library is built or if it's consumed and how it's built and consumed.
> 
> Concentrating on how Libtool is using Microsoft tools, Libtool will dig

How about simplifying this to
 With Microsoft tools, Libtool will dig ...

> through the object files making up the library looking for non-static

that make up the

> symbols to automatically export. I.e., Libtool with Microsoft tools is
> trying to mimic the auto-export feature of the contemporary GNU tools.
> It should be noted that the GNU auto-export feature in turned off when

s/ in / is /

> an explicit __declspec(dllexport) is seen. The GNU tools is doing this

s/is doing/do/  or  s/is/are/

> to not make more symbols visible for projects that have already taken
> the trouble to decorate all symbols. There is no similar way to limit

s/all// ?  (because how can you know that it did do so for all symbols,
when parts of the project may come from third parties?)

> which symbols are visible in the code when Libtool is using Microsoft
> tools. In order to limit symbol visibility in that case you need to use
> one of the -export-symbols or -export-symbols-regex options.
> 
> No matching help with auto-import is provided by Libtool for neither
> proprietary tools nor older GNU tools, so symbols *must* be decorated in
> order to import them from a DLL for everything but contemporary GNU
> tools on Windows.

But can we not assume that older GNU tools are irrelevant?  What would
keep people from updating them?

> When the objects that form the library are built, there are generally
> two copies built for each object. One copy is used when linking the DLL
> and one copy is used for the static library. On Windows systems, the
> copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.

> It is common practice to also add a flag that is only present when the
> library is built, but that will not be present when it is consumed, such
> as -DBUILDING_LIBFOO. These defines are then used to discriminate how
> the interface symbols should be decorated.

This seems to be a bit reversed.  From a narrative standpoint, the
"common practice" only appears out of necessity, and the necessity has
not been explained yet.  Right?

> However, the matching double compile is not performed when consuming
> libraries. It is therefore not possible to reliably distinguish if the
> consumer is importing from a DLL or if it is going to use a static
> library. With contemporary GNU tools, auto-import saves the day.

because auto-import does what exactly?
(pointer to auto-import documentation from binutils?)

> With
> Microsoft tools you typically get away with always compiling the code as
> if it is going to be linked with a DLL. There are cases when this does
> not work, such as when only variables and no functions are imported from
> the library. There is also a price connected to this liberal use of
> imports in that an extra indirection is introduced when you are
> consuming the static version of the library. That extra indirection is
> always present when the DLL is consumed, but it is not needed when
> consuming the static library.

This paragraph is fairly vague.  I understand if you don't want to tell
all the gory details about this, but in that case maybe a pointer to
more detailed documentation would be good here.

> For older GN