Re: libtool mingw cross compile problems

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Wed, May 18, 2011 at 09:13:32PM CEST:
> * Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST:
> > The problem is the generation of a test program in a sub-directory.
> > The test program that should be generated is:
> > 
> > G72x/g72x_test.$(EXEEXT)
> > 
> > which executes a a wrapper script in G72x/.libs/ . Unfortunately
> > for Linux -> windows cross compiles, the G72x/g72x_test.$(EXEEXT)
> > executable isn't being generated. There is however a bash script
> > G72x/.libs/g72x_test_ltshwrapper.
> 
> Please provide more details.  For example a small Makefile.am snippet
> that reproduces the problem for you.

Aw darn, now that I sent this mail I see you already sent this to the
automake list.  Please don't send to two lists without at least hinting
that you've already sent things elsewhere, or better a URL or Xpost with
Followup.

In this case I would like to see the output of
  make clean && make; make g72x_test

Thanks,
Ralf

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

Re: libtool mingw cross compile problems

[Ralf Wildenhues]

Hello Erik,

* Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST:
> I have a project that uses autoconf/automake/libitool etc. The
> build system worked as recently as a month ago for both native
> compiles on linux and cross compiles from linux to windows.
> Unfortnately, linux to wndows cross compiles suddenly stopped
> working with libtool 2.4 from Debian testing.
> 
> The problem is the generation of a test program in a sub-directory.
> The test program that should be generated is:
> 
> G72x/g72x_test.$(EXEEXT)
> 
> which executes a a wrapper script in G72x/.libs/ . Unfortunately
> for Linux -> windows cross compiles, the G72x/g72x_test.$(EXEEXT)
> executable isn't being generated. There is however a bash script
> G72x/.libs/g72x_test_ltshwrapper.

Please provide more details.  For example a small Makefile.am snippet
that reproduces the problem for you.

> Software versions:
> 
> autoconf (GNU Autoconf) 2.68
> automake (GNU automake) 1.11.1
> libtool (GNU libtool) 2.4
> 
> All from Debian Testing.
> 
> I've tried downgrading libtool to 2.2.6b, but that resulted in a
> huge spew of errors from autoconf.

Please provide more details, such as a cut and paste of the actual
errors (or a part), as well as the commands you used that got you there.

> Is this a known problem?

No idea.

Thanks,
Ralf

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

Re: Why --nostdlib is used for building shared library?

[Ralf Wildenhues]

Hello Mu Qiao,

* Mu Qiao wrote on Sun, May 15, 2011 at 06:33:56AM CEST:
> I use libtool to manage the build of my C++ shared library. But I find
> it passes --nostdlib to g++. It works fine in most cases but is not
> working well with gcov.

Does it work when you pass CXXFLAGS=--coverage already at configure
time?

Thanks,
Ralf

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

Re: QNX6 patch

[Ralf Wildenhues]

Hello Sean,

* Sean Boudreau wrote on Mon, Apr 11, 2011 at 05:32:25PM CEST:
> Here's a patch for qnx that I've been using for a while.
> I'd like to try to get it integrated.

Thank you for the patch.  Unfortunately, we cannot take it as it is,
because there are several bits of information missing, and some things
look problematic.

First off, the patch needs a GNU-style ChangeLog entry (see the
ChangeLog file for existing entries).  We can write it if you have
problems with it, but you should at least try.  Did you write the
patch?  Were others also involved?

Then, we'd like to see how both the old and the new Libtool testsuites
fare with this patch on QNX6 (and maybe older releases if relevant?),
and whether the patch fixes any test failures that were present
previously (and it would be good to see verbose test logs for those as
well).

More comments inline.

> --- libtool-2.4~/libltdl/m4/libtool.m42010-09-22 04:41:19.0 
> -0400
> +++ libtool-2.4/libltdl/m4/libtool.m4 2011-04-11 11:13:24.0 -0400
> @@ -2651,9 +2651,10 @@
>;;
>  
>  *nto* | *qnx*)
> -  version_type=qnx
> +  version_type=linux

Whoa, this is a very heavy change.  This has the chance to break
virtually all existing QNX setups, turn installed libraries that have
been built without this change incompatible to libraries that use the
change.

Such a change needs a very good rationale, usually including a pointer
to system documentation for why the old version semantics are not
adequate (any more?), for why maybe a newer system release changed
semantics, or some other reason.  If we do this change for a new system
version, that can be acceptable, but then older versions should not be
affected.

That said, I have no idea how large the user base for Libtool and
Libtool-using packages on QNX is.  You might be the only person building
packages there, I cannot tell.  Please share such information, as much
as you have it.

Jasons remark about this being different from the QNX style makes me
doubt the validity of this change even more.  libtool should be
emulating the native shared library semantics as much as possible in
order to "fit in".

>need_lib_prefix=no
>need_version=no
> +  sys_lib_search_path_spec="/lib /usr/lib"

This looks benign.

>library_names_spec='${libname}${release}${shared_ext}$versuffix 
> ${libname}${release}${shared_ext}$major $libname${shared_ext}'
>soname_spec='${libname}${release}${shared_ext}$major'
>shlibpath_var=LD_LIBRARY_PATH
> @@ -3245,7 +3246,7 @@
>;;
>  
>  *nto* | *qnx*)
> -  lt_cv_deplibs_check_method=pass_all
> +  'match_pattern /lib[[^/]]+(\.so|S\.a)$'

This looks like a typo.  The resulting shell code is erroneous
(tries to execute a program named "match_pattern /...".
You meant to assign the contents of the added line to the variable
named in the removed line.

>;;
>  
>  openbsd*)
> @@ -5289,6 +5290,8 @@
>;;
>  
>  *nto* | *qnx*)
> +  _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'

Please check whether adding $pic_flag to both added commands lets them
still work.

>;;
>  
>  openbsd*)
> @@ -6495,7 +6498,12 @@
>   ;;
>  
>*nto* | *qnx*)
> -_LT_TAGVAR(ld_shlibs, $1)=yes
> +_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'

Likewise.

> +_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
> +_LT_TAGVAR(hardcode_direct, $1)=yes
> +_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> +output_verbose_link_cmd='echo'

These additions look OK to me.

>   ;;
>  
>openbsd2*)

Thanks again,
Ralf

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

Re: debbugs, and a FAQ, for Autotools

[Ralf Wildenhues]

* Glenn Morris wrote on Tue, Apr 05, 2011 at 11:46:21PM CEST:
> Ralf Wildenhues wrote (on Tue, 5 Apr 2011 at 23:30 +0200):
> 
> > Thank you!  Could you also list libtool on <http://debbugs.gnu.org/>?
> 
> Umm, I did. Maybe you have a stale cache?

I guess.  It works now.

Thank you Glenn for taking care of this!
Ralf

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

Re: debbugs, and a FAQ, for Autotools

[Ralf Wildenhues]

Hi Glenn,

* Glenn Morris wrote on Tue, Apr 05, 2011 at 07:05:16PM CEST:
> This is done, the mail routing change should take effect in an hour or so.

Thank you!  Could you also list libtool on ?

> BTW I noticed that in the online libtool manual:
> 
> http://www.gnu.org/software/libtool/manual/html_node/Reporting-bugs.html
> 
> the link in
> 
>   "you should read the Emacs guide to reporting bugs (see Reporting Bugs)"
> 
> is broken.

I updated the .symlinks file, should be fixed now.

Thanks,
Ralf

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

Re: Example in libtool manual gives wrong dependencies w/ automake.

[Ralf Wildenhues]

Hello Nick,

* Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST:
> I'm working on a project which uses libltdl to load modules, and I've
> set it up in a manner pretty similar to what's described in the libtool
> manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5).
> In that section, the manual recommends to use a weak library interface.
> 
> However, the example given in the manual does not work because
> the generated makefile lacks dependencies from libloader.la to
> libinterface.la's objects.

Indeed.  The reference to the internal *_OBJECTS variable is surprising.
It would be cleaner to have a libfoo_conv.la convenience
(noinst_LTLIBRARIES) archive that had the same sources as libfoo.la and
add that to libbar_la_LIBADD.

A patch to fix libtool.texi to this end would be appreciated.

>  Here's a simplified and complete
> version of the example in the libtool manual:
> 
>   % cat >Makefile.am <<'EOF'
>   lib_LTLIBRARIES = libbar.la libfoo.la
> 
>   libfoo_la_SOURCES = foo.c
> 
>   libbar_la_SOURCES = bar.c
>   libbar_la_LDFLAGS = -weak libfoo.la
>   libbar_la_LIBADD  = $(libfoo_la_OBJECTS)
>   EOF

>   % ./configure -q && make
> CC bar.lo
> CCLD   libbar.la
>   libtool: link: `foo.lo' is not a valid libtool object
>   make: *** [libbar.la] Error 1
> 
> Looking at the generated Makefile.in, we see this is because libbar.la
> doesn't have any dependency on foo.lo.  We can add it to the
> Makefile.am:
> 
>   libbar_la = libbar.la
>   $(libbar_la): $(libfoo_la_OBJECTS)
> 
> and now it will build.  So, should automake support the example in the
> libtool manual, or does the libtool manual need to be fixed?  If the
> latter, is the above workaround a good one?

I see several workarounds.  The one I described above is clean.
Another would be to compute libbar_la_DEPENDENCIES manually, e.g.:
  libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

In a real-life situation, there are other dependencies, so you'd prefer
to use
  EXTRA_libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

so automake will still compute libbar_la_DEPENDENCIES
(available only in git Automake, will be in 1.12; sorry).

One thing that I wonder about is why you actually need the foo code to
be both in libfoo and libbar.  If possible, then code should only ever
exist in one shared library.  (I may be missing details from the
dlpreopen machinery here now, it's been a while ... feedback as to what
worked for you appreciated.)


As to whether automake should be able to look through $(*_OBJECTS)
references in _LIBADD and add them to _DEPENDENCIES: yes that too
seems like a viable idea.  'info Automake "Program and Library
Variables"' is currently vague about this case (but it can be, since
_OBJECTS are supposed to be internal details).

So there really are two issues here, one in libtool.texi and one in
Automake.  Thanks for reporting them.

Cheers,
Ralf

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

Re: debbugs, and a FAQ, for Autotools

[Ralf Wildenhues]

Let's pick this up again, but for Libtool only for now.

[ http://lists.gnu.org/archive/html/automake/2011-02/msg00025.html ]

* Ralf Wildenhues wrote on Sun, Feb 13, 2011 at 07:12:02PM CET:
> [ Cross post; Reply-To and Mail-Followup-To set.  Please followup to
>   the automake list only, to avoid excessive spammage.  Thank you.  ]

> I've been advertising debbugs before, I think we should be a good
> example.  So, two proposals:
> 
> 1) Autoconf and Libtool should also use debbugs.
> 
> bug-automake has switched a few months ago, and I find it helpful to
> avoid losing reports.  Given that we never have enough time on our
> hands, it becomes more important to not lose track.

Do any Libtool developers or regulars have any issue with this?
We do keep forgetting about bug reports, and we do have contributors
that only work every once in a while, and for both it would seem to
be useful to have a list of open issues.

Eric had concerns that it would be difficult to tell which package a bug
was against.  The Sender: header shows this, however, so I don't see it
as a big problem (unless your MUA cannot be configured to show this
particular header).  Or we could modify debbugs to provide some more
hints.

If there is no disagreement by, let's say Monday, Glenn could you then
set up debbugs for the bug-libtool list?

Thanks,
Ralf

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

Re: libtool relinks all shared libraries when "make install" is performed

[Ralf Wildenhues]

Hello Markus,

* Markus Franke wrote on Wed, Mar 23, 2011 at 05:18:53PM CET:
> we have a large C++ project containing of several modules which each get 
> compiled into seperate shared libraries. Our directory structure looks 
> somehow as follows:
[...]

> When performing the "make install" step all the libraries and binaries get 
> installed to our prefix directory "/opt/kmt". This currently takes very 
> long (~20 minutes) as libtool relinks all libraries.
[...]

Wow.  That's terrible.

> How can I avoid this additional relinking step during "make install"?

Generally, --enable-fast-install should be the switch to avoid it.
However, it is not possible to do on every system, and not fully
optimized on all systems where it could be made to work.  Unfortunately,
GNU/Linux is one of the latter ones where Libtool still needs a bit of
work.

Thanks for the bug report,
Ralf

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

Re: About libtool supporting parallel "make install"

[Ralf Wildenhues]

Pacho,

hope you're reading the list.  Mail from me to you bounces because some
MTA near your end is over-eagerly using SPF to reject legitimate mail.

Rakf

* Ralf Wildenhues wrote on Fri, Mar 18, 2011 at 08:43:21PM CET:
> Hello Pacho,
> 
> * Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET:
> > We have some downstream opened bugs with similar cases, would you mind
> > asking for help with them here in the future once their respective
> > upstream refuse to fix the issues?
> 
> Feel free to come to this mailing list for help about Libtool issues.
> 
> Cheers,
> Ralf

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

Re: About libtool supporting parallel "make install"

[Ralf Wildenhues]

Hello Pacho,

* Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET:
> We have some downstream opened bugs with similar cases, would you mind
> asking for help with them here in the future once their respective
> upstream refuse to fix the issues?

Feel free to come to this mailing list for help about Libtool issues.

Cheers,
Ralf

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

Re: About libtool supporting parallel "make install"

[Ralf Wildenhues]

* Dan Nicholson wrote on Thu, Mar 17, 2011 at 11:47:38PM CET:
> On Thu, Mar 17, 2011 at 3:08 AM, Pacho Ramos  wrote:
> 
> > https://bugzilla.gnome.org/show_bug.cgi?id=644896#c2
> 
> This seems more legitimate. I looked at the Makefile.am's and they
> look reasonable to me. You have two libraries, one is in
> lib_LTLIBRARIES and the other is in pkglib_LTLIBRARIES. The pkglib one
> depends on the lib one.
> 
> It seems that make is running install-libLTLIBRARIES and
> install-pkglibLTLIBRARIES in parallel. Each one of these these rules
> installs the libraries serially in a loop. However, if libtool is
> relinking the libraries, it really needs to wait until the
> prerequisite libraries from _other_ rules are installed. I'd bet if
> you do this:
> 
> echo "install-pkglibLTLIBRARIES: install-libLTLIBRARIES" >>
> src/backend/xml/Makefile
> 
> it will work again. This seems like a bug in automake's libtool
> support to me, but I don't know how to fix it.

Yes, it's a bug in Automake/Libtool, but the workaround isn't quite
correct: you'd need something like

install-pkglibLTLIBRARIES = install-pkglibLTLIBRARIES
$(install-pkglibLTLIBRARIES): install-libLTLIBRARIES

because your proposed workaround will cause automake to not emit its
install-pkglibLTLIBRARIES rule at all.  Yes, depending on automake not
seeing through variables when determining target names is ugly, I know.
(It's also so widespread by now that we can't easily change that issue.)

I've posted some ideas to fix the original bug before, on an automake or
libtool list; but nothing finished.  :-/

Cheers,
Ralf

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

Re: Consider adding -I $macrodir

[Ralf Wildenhues]

Hi Jan,

* Jan Engelhardt wrote on Sun, Mar 13, 2011 at 03:31:40PM CET:
> I have seen one project where Makefile.am used
> 
>   ACLOCAL_AMFLAGS = -Im4
> 
> and libtool 2.2.6b still threw the warning
> 
>   Consider adding -I m4 to Makefile.am
> 
> which is because libtool does not seem to handle bundled arguments.

Thanks.  I'm pushing the patch below and adding you to THANKS.

Cheers,
Ralf

libtoolize: detect -I (without space) in ACLOCAL_AMFLAGS.

* libtoolize.m4sh (func_scan_files): Also accept -I
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
 # Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
 
 my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
-   s,^[^=]*=[   ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+   s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
   am_macrodir="$arg"
   break
 else
-  if test "X$arg" = "X-I"; then
-my_macrodir_is_next=:
-  else
-my_macrodir_is_next=false
-  fi
+ case $arg in
+   -I) my_macrodir_is_next=: ;;
+   -I*)
+ am_macrodir=`$ECHO "$arg" | sed 's,^-I,,'`
+ break
+ ;;
+   *) my_macrodir_is_next=false ;;
+ esac
 fi
   done
 fi

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

Re: -soname passed directly to the compiler

[Ralf Wildenhues]

* tom fogal wrote on Tue, Feb 15, 2011 at 06:34:44PM CET:
> Hi, sorry for the slow response.

No worries.

> Ralf Wildenhues writes:
> > Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but
> > apparently it isn't.  You could look in config.log to find out why.
> > I'd really really suggest using a newer Libtool though [. . .]
> 
> Just wanted to follow up for the archives.  I upgraded libtool but hit
> lots of strange issues.  Ended up upgrading both autoconf and automake
> too, which of course were also a few years old.
> 
> I was still hitting issues, now with libtool trying to execute "X--gcc"
> or something like that; it seemed to be a common problem, from google
> searches, yet nobody had a concrete answer.  I'm afraid I don't either:
> my solution was to stash my current changes and `git clean -df'.  I
> don't version control configure, aclocal.m4, config.* etc., and so this
> got me a virgin tree.
> 
> At that point 'libtoolize --copy --force && autoreconf -vi' got me a
> working build system.  There must have been some sort of state which
> was not getting overwritten from the above w/o cleaning out the whole
> tree, but I do not know what it was, exactly.

I want to add this to the to-be-written FAQ.  I have half an idea of
where that bug comes from but would like to make sure.  Please specify
exactly which Autoconf, Automake, and Libtool versions you used before
upgrading, and then, in which order you upgraded which tool to what
newer version.

Thanks,
Ralf

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

Re: -soname passed directly to the compiler

[Ralf Wildenhues]

Hello Tom,

* tom fogal wrote on Sun, Feb 13, 2011 at 10:23:30PM CET:
> A package we're converting to the autotools is having an issue building
> a library; it seems to think gcc supports a -soname option.
> 
>   /bin/sh ../libtool --tag=CC   --mode=link mpicc  -I/home/tfogal/sw/include
>   -L/home/tfogal/sw/lib -o libH5Part.la -rpath
>   /home/tfogal/dev/install-h5part/lib H5Part.lo H5PartAttrib.lo H5Block.lo
>   H5BlockReadWrite.lo H5MultiBlock.lo H5MultiBlockReadWrite.lo  -lhdf5
>   mpicc -shared  .libs/H5Part.o .libs/H5PartAttrib.o .libs/H5Block.o
>   .libs/H5BlockReadWrite.o .libs/H5MultiBlock.o .libs/H5MultiBlockReadWrite.o
>   -L/home/tfogal/sw/lib /home/tfogal/shigeru/lib/libhdf5.a -lc  -soname
>   libH5Part.so.0 -o .libs/libH5Part.so.0.0.0
>   gcc: libH5Part.so.0: No such file or directory
>   gcc: unrecognized option '-soname'

> ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02/01
> 16:58:18)

Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but apparently
it isn't.  You could look in config.log to find out why.  I'd really
really suggest using a newer Libtool though, 2.4 is the current version,
and I'm not eager to debug issues in the 1.5 branch (which has been dead
for almost three years now) any more.

Thanks,
Ralf

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

debbugs, and a FAQ, for Autotools

[Ralf Wildenhues]

[ Cross post; Reply-To and Mail-Followup-To set.  Please followup to
  the automake list only, to avoid excessive spammage.  Thank you.  ]

Hello everyone,

I've been advertising debbugs before, I think we should be a good
example.  So, two proposals:

1) Autoconf and Libtool should also use debbugs.

bug-automake has switched a few months ago, and I find it helpful to
avoid losing reports.  Given that we never have enough time on our
hands, it becomes more important to not lose track.

See http://debbugs.gnu.org/ and linked pages for details.

2) Autotools should have a FAQ document.  Not of the sort of the FAQ
chapter that answers seven random questions and that has a 1 year+
latency until it is updated, but one that answers both totally-newbie
kinds of questions that get asked over and over again, or cross-tool
bug questions like the infamous libtool echo problem (which was due to
an incompatible m4sugar change).  A document that, ideally, eventually
obsoletes many of the third-party "here's how autotools work, in quick"
kinds of pages.

See e.g., this most recent thread which made the need so clear again:
http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672


For (2) I'd suggest a wiki if we GNU the infrastructure, but something
like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html
would certainly be good.  (And yes, I've been arguing against wikis in
the past.  I was wrong.  Sue me.)


Now, I have very little spare time on my hands.  Any volunteers on
managing such a document?  Any people interested in contributing answers
or even only questions?  I wouldn't mind handing out commit privs to any
of the regulars on these lists.

Thanks for feedback,
Ralf

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

Re: how to debug unexpected dependency

[Ralf Wildenhues]

Hello Mirko,

* Mirko Vukovic wrote on Thu, Jan 27, 2011 at 06:31:04PM CET:
> A build of mpc on 64-bit RHEL5 fails.  I tracked down the cause to an entry
> in libmpc.la file:
> 
> # Libraries that this one depends upon.
> dependency_libs='
> /usr/local/lib/libmpfr.la/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gmp-5.0.1/lib/
> libgmp.la /usr/local/lib/libgmp.la'

> I am looking for ideas on how to debug this condition.

Usually, by looking at the output of the 'libtool --mode=link' command
that produces this library, with --debug added as first argument to
libtool.  In this (usually large!) trace output find out why this path
is searched at all.  That usually points to where the problem comes from.

If you have the trace but cannot decipher it, feel free to post it here,
gzip'ed.

Hope that helps.

Cheers,
Ralf

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

Re: How to create only executable files

[Ralf Wildenhues]

* Sergio Belkin wrote on Mon, Jan 24, 2011 at 11:42:25AM CET:
> Let's say that you have a library libfoo.so and you have on build tree a
> source file fred.c. You've created a test target that creat (with
> -no-install flag)  the  ELF  executable fred (note that has no extension).
> But libtool create also fred.o "an ELF relocatable", is there a way that
> libtool create only the "ELF excutable"? What is the advantage of create an
> "intermediate file"?

Simplicity of (Automake+Libtool) implementation.
Absence of (non-esthetic) downsides for the user.

Cheers,
Ralf

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

Re: How to create only executable files

[Ralf Wildenhues]

Hello Sergio,

* Sergio Belkin wrote on Sun, Jan 23, 2011 at 11:13:16PM CET:
> I've found great the option "-no-install". But I wonder if is there a
> way to build directly the executables files, I mean that don't create
> object file "something.o" and only do something.o

You mean creating an executable directly from source file(s)?
No, Automake doesn't really support that.  You can try to write
a rule that passes foo.c to 'libtool --mode=link', but since we
don't test that I'm guessing that it won't work reliably.

What's the point of this anyway?  AFAIK the only thing you save
by omitting the object file is one fork&exec of the compiler driver,
which is often negligible compared with the actual work the compiler
and linker do.  You can 'make mostlyclean' to remove object files
you don't need again afterwards.

Cheers,
Ralf

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

Re: pic-only option not working as expected

[Ralf Wildenhues]

* John Calcote wrote on Sat, Jan 22, 2011 at 08:42:33PM CET:
> LT_INIT([disable-shared static pic-only])
> ...
> 
> While playing with these options, I noticed that the 'disable-shared'
> and 'static' options seem to have the desired effect, but the 'pic-only'
> option does not. Whether I use 'pic-only' or not, I get the following
> output from 'configure --help':

I was just going to get to this patch tomorrow.  I haven't retested it
and am on a run now.  Can you try it?  Jose reported this to me
off-list.

Thanks,
Ralf

Fix LT_INIT([pic-only]) semantics.

* libltdl/m4/ltoptions.m4 (_LT_WITH_PIC): Use the macro argument
for setting the default for pic_mode.
* tests/pic.at: New file, new test.
* Makefile.am (TESTSUITE_AT): Update.
Reports by Jose Marchesi, Luke Mewburn, and John Calcote.

diff --git a/Makefile.am b/Makefile.am
index 15d9404..3c8f213 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -510,6 +510,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/stresstest.at \
  tests/cmdline_wrap.at \
  tests/pic_flag.at \
+ tests/pic.at \
  tests/old-autotools.at \
  tests/darwin.at \
  tests/dumpbin-symbols.at \
diff --git a/libltdl/m4/ltoptions.m4 b/libltdl/m4/ltoptions.m4
index 5d9acd8..91876f0 100644
--- a/libltdl/m4/ltoptions.m4
+++ b/libltdl/m4/ltoptions.m4
@@ -344,7 +344,7 @@ m4_define([_LT_WITH_PIC],
   IFS="$lt_save_ifs"
   ;;
 esac],
-[pic_mode=default])
+[pic_mode=m4_default([$1], [default])])
 
 test -z "$pic_mode" && pic_mode=m4_default([$1], [default])
 
diff --git a/tests/pic.at b/tests/pic.at
new file mode 100644
index 000..545d9cc
--- /dev/null
+++ b/tests/pic.at
@@ -0,0 +1,38 @@
+# pic.at -- LT_INIT(pic)   -*- Autotest -*-
+
+#   Copyright (C) 2010 Free Software Foundation, Inc.
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([pic-only])
+
+AT_DATA([configure.ac],
+[[AC_INIT
+AC_CONFIG_MACRO_DIR([m4])
+LT_INIT([pic-only])
+AC_OUTPUT
+]])
+
+mkdir m4
+LT_AT_BOOTSTRAP([--install], [], [ignore], [ignore], [], [], [ignore])
+AT_CHECK([./libtool --config | grep pic_mode], [], [pic_mode=yes
+])
+
+AT_CLEANUP

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

Re: Libtool sysroot RPATH problems

[Ralf Wildenhues]

Hello Richard,

* Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
> Firstly, for the first time ever for us, it appears libtool is no longer
> relinking our libraries at install time.

That's weird, I don't think the sysroot feature should've caused this
change.  Not quite sure though.

> This is welcome as we're cross
> compiling to a sysroot and we'd never want to actually run them in situ
> so this could probably save us some build time. It does however mean we
> never go for a relink step so we're hitting codepaths and issues that
> I've never seen. For reference, we always used to set installed="no" in
> our "staged" libraries prior to sysroot support since this let us hack
> around the lack of sysroot support easier.
> 
> Anyhow, the problem I'm seeing is that the final library has an RPATH
> including the sysroot prefix when make is calling libtool with
> -rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
> starting at line 7240 (see the end of the email for a quotation) and
> firstly, I don't understand why the func_replace_sysroot call is inside
> the $hardcode_libdir_separator test? Surely it should be outside it and
> happen whenever $hardcode_libdir_flag_spec is set?

Please show the --mode={link,install} commands plus all of their output,
also './libtool --config'.  Please also show how exactly you invoke
configure.  Thanks.

> Changing that helps a bit and I end up with an RPATH of "=/usr/lib" so
> the sysroot prefix is gone but the "=" is there. I suspect that isn't
> valid so I added the following code after the func_replace_sysroot call
> 
> func_stripname '=' '' "$libdir"
> libdir=$func_stripname_result
> 
> and then I get an RPATH of "/usr/lib" which is ok to a point.

The replacing of '=' can be achieved by running 'libtool --mode=finish
LIB' later, although I see we don't document this everywhere yet.

> Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
> getting added at all. Its coming to this function via $compile_rpath
> which is being set around line 5939 which in turn is coming from absdir.
> absdir is being compared against $sys_lib_dlsearch_path_spec but without
> adding/removing any sysroot prefixes.

Hmm, that sounds like a bug indeed.

> I'd really therefore like to ask what behaviour to be expecting from
> libtool before I try and write patches to fix any of this. To summarise
> some of my questions:

I can answer them only with more information, sorry.

Thanks,
Ralf

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

Re: Libtool library used but `LIBTOOL' is undefined??

[Ralf Wildenhues]

Hello,

* kknd1233 wrote on Wed, Jan 05, 2011 at 12:14:20AM CET:
> And then when I run the command 'autoreconf --install', it said an error
> message like
> "
> lib/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
> lib/Makefile.am:1:   The usual way to define `LIBTOOL' is to add
> `AC_PROG_LIBTOOL'
> lib/Makefile.am:1:   to `configure.ac' and run `aclocal' and `autoconf'
> again.
> lib/Makefile.am:1:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
> lib/Makefile.am:1:   its definition is in aclocal's search path.
> "

(LT_INIT is a synonym of AC_PROG_LIBTOOL.)

I presume your Automake and your Libtool are not installed below the
same prefix, thus aclocal doesn't find the Libtool macros to install.
One solution is to install both below the same prefix; or write a
dirlist file in $automake_prefix/share/aclocal with a line containing
$libtool_prefix/share/aclocal.

Or the error has a different reason, in which case please post output of
  autoreconf --verbose --install

Hope that helps.

Cheers,
Ralf

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

Re: func_convert_file_cygwin_to_w32 woes

[Ralf Wildenhues]

Hi Dan,

* Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
> I am trying to build a program under cygwin but using the mingw tool
> chain in a fake cross build way.  In my configure environment, I have:
> 
>  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
> 
> as suggested by the libtool manual.  I'm using libtool 2.4.
> 
> Everything goes smoothly until install time when libtool calls ranlib
> (the mingw one) on an absolute path and of course the cygwin absolute
> path doesn't make sense to the mingw ranlib.  I thought that's what the
> func_convert... bit was for.

Please copy and paste 'libtool --mode={link,relink,install}' commands
for the libraries and programs involved.  We may provide better help
then.

Cheers,
Ralf

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

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Bruce Korb wrote on Mon, Dec 20, 2010 at 09:37:58PM CET:
> On 12/20/10 11:20, Ralf Wildenhues wrote:
> > One crucial part is that libtool gets confused whenever it has
> > directories with the wrong ABI in the search path (unlike ld or ld.so,
> > both are in some cases smart enough to skip wrong ABI), which means that
> > either no instance of the build system machineries may introduce such
> > paths, or libtool needs to get smarter to ignore wrong ABI dirs.
> >
> > The other crucial part is that libtool doesn't get the
> > sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
> > right on several distros, introducing such wrong directories itself (not
> > to speak of cross setups).  There have been several proposed patches to
> > address this, e.g.
> > http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
> > http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
> > but I have yet to see one that solves it.
> > 
> > At least with current Libtool you can override wrong settings with the
> > lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
> > cache variables.

> Addressing things in reverse order:
> 
> 1. "lt_cv_sys_lib..." It is true that authors of packages need to be
>more knowledgeable than the "hapless builder", still they should
>not have to fiddle with undocumented internals; and cached variable
>values seem like grody internals to me.

I fully agree that such knowledge /should/ not be required.  It's a bug
that libtool doesn't get the right setting by default.

> 2. Way back at the beginning, with a default installation of
>RHEL for amd-64/x86-64, these commands fail:
> 
>$ cd $guile_build_dir
>$ $guile_src/configure && make && sudo make install
>$ cd $autogen_build_dir
>$ $autogen_src/configure && make && sudo make install
> 
>and it fails because `guile-config link` produces output
>that libtool interprets and then passes, as a full path name,
>a library listed as ``-lXXX'' in the guile-config
>output.  The full path, of course, is to a 32 bit shared obj
>in  a 64 bit link command.  Oops.
> 
>So this means that if "ld" could have identified a 32 bit shared obj
>and gone on to look in another directory, all would have been well.
>Instead, "ld" saw a full path and tried to do what it was told,
>but said, "no, I won't do that".
> 
> 3. CF:
> > One crucial part is that libtool gets confused whenever it has
> > directories with the wrong ABI in the search path (unlike ld or ld.so,
> > both are in some cases smart enough to skip wrong ABI),
>   So DO NOT REPLACE ``-lgmp'' with ``/usr/local/lib/libgmp.so''!!!
>   libtool did this and triggered the whole thread.

Again: the replacement of -lgmp with /usr/local/lib/libgmp.so might be
the thing that makes the failure visible, but it is not the underlying
cause, and trying to avoid the replacement is like trying to make
someone go away by closing your eyes.  The error happened earlier: at
the time /usr/local/lib was introduced into the libtool search path.

The replacement of -lfoo with /abs/path/to/libfoo.so on some systems,
notably GNU/Linux, is very helpful in being able to reliably link
against uninstalled libraries even in the presence of -L/some/inst/path
early on the link command line.  Crying against this will not fix the
issue (as there are other places where libtool will get things wrong for
you even if you inhibit this, once it looks in the wrong directories).

>   See: http://lists.gnu.org/archive/html/libtool/2010-12/msg00041.html
> 
> Just a note: if a distro puts 64 bit SOs in /usr/lib64, then it is
> reasonable to put add-on 64 bit SOs into /usr/local/lib64.  In fact,
> I would consider it peculiar to put 'em into /usr/local/lib.

Sure, that's what you would expect.  What can libtool expect though?
I don't think /usr/local can be treated as necessarily having the same
policy as /usr has, one coming from the distro and the other containing
all kinds of non-adapted (even non-GNU standards using) junk.

> The difference should just be $prefix (i.e. "/usr" vs. "/usr/local").
> If my sloppiness regarding distinguishing /usr/lib from /usr/local/lib
> caused any confusion, my apologies.  The final lib directory name
> should be consistent.

I fail to see how it would be possible to ingrain this rule into all of
our users, overnight.

Cheers,
Ralf

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

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:20:25PM CET:
> The other crucial part is that libtool doesn't get the
> sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
> right on several distros, introducing such wrong directories itself (not
> to speak of cross setups).  There have been several proposed patches to
> address this, e.g.
> http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
> http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
> but I have yet to see one that solves it.

ESENDTOOSOON, sorry.

At least with current Libtool you can override wrong settings with the
lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
cache variables.

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

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
>   How much understanding of the machinery should be expected
>   of the hapless project builder?

I've skimmed most of the conversation in this thread now.

The crucial part, I think, is *not* the --libdir setting.  Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.

One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.

The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups).  There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.

Thanks,
Ralf

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

Re: Enhanced OS/2 port

[Ralf Wildenhues]

[ adding libtool-patches@; followups can remove libtool@ ]

* KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET:
> I've enhanced and fixed libtool 2.4 for OS/2.

Thanks again for working on this.

Generally, we prefer one patch per logical change, and GNU-style
ChangeLog entries.  Also, we should strive to expose bugs in the
testsuite, so that we don't regress.

I understand that just producing a patch at all can be hard work,
so we can help with things (just that takes time ...)
One thing is quite helpful though, and that's how well our testsuite
fares on your system (both without and with the patch).

Also, for nontrivial changes, the FSF needs copyright papers
(more on this off-list).

That said, let's try to get the easier things out of the way:

> --- Makefile.am.org   2010-09-21 16:07:22.0 +0900
> +++ Makefile.am   2010-11-27 00:19:56.0 +0900
> @@ -324,7 +324,7 @@
>  dist_man1_MANS   = $(srcdir)/doc/libtool.1 
> $(srcdir)/doc/libtoolize.1
>  MAINTAINERCLEANFILES += $(dist_man1_MANS)
>  update_mans = \
> -  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
> +  PATH=".$(PATH_SEPARATOR)$$PATH"; export PATH; \

Good change.

>$(HELP2MAN) --output=$@
>  $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
>   $(update_mans) --help-option=--help-all libtool

> --- libltdl/config/general.m4sh.org   2010-09-01 15:02:44.0 +0900
> +++ libltdl/config/general.m4sh   2010-11-27 12:15:52.0 +0900
> @@ -296,10 +296,13 @@
>   ;;
>*)
>   save_IFS="$IFS"
> - IFS=:
> - for progdir in $PATH; do
> -   IFS="$save_IFS"
> -   test -x "$progdir/$progname" && break
> + for pathsep in : ";"; do
> +   IFS="$pathsep"
> +   for progdir in $PATH$pathsep; do
> +  IFS="$save_IFS"
> +  test -x "$progdir/$progname" && break
> +   done
> +   test -n "$progdir" && break
>   done
>   IFS="$save_IFS"
>   test -n "$progdir" || progdir=`pwd`

I don't particularly like guessing here.  Rather, let's store the
configure-computed PATH_SEPARATOR in the generated libtool script
(libtoolize already sets it anyway) and use that.

I'm applying the following patch in your name, and adding you to THANKS:


2010-12-15  KO Myung-Hun   (tiny change)
Ralf Wildenhues  

Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.

diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
 dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
 MAINTAINERCLEANFILES   += $(dist_man1_MANS)
 update_mans = \
-  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+  PATH=".$(PATH_SEPARATOR)$$PATH"; export PATH; \
   $(HELP2MAN) --output=$@
 $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
  ;;
   *)
  save_IFS="$IFS"
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
  for progdir in $PATH; do
IFS="$save_IFS"
test -x "$progdir/$progname" && break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
 AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
 AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
 
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build 
system])dnl
+dnl
 _LT_DECL([], [host_alias], [0], [The host system])dnl
 _LT_DECL([], [host], [0])dnl
 _LT_DECL([], [host_os], [0])dnl




> @@ -564,6 +567,10 @@

(in func_show_eval)

>  my_cmd="$1"
>  my_fail_exp="${2-:}"
> 
> +# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
> +# when a line length is 1022. Maybe 1022 is a magic number ?
> +my_cmd=`$ECHO "$my_cmd" | $SED s/\r$//`

Ouch.  Where did you hit this?  Can't you fix pdksh instead?
This change unconditionally costs two forks and one exec on almost every
command that libtool issues.  Also, \r is not a portable sed regex.

Does something like this work instead?

   # pdksh 5.2.14-bin-2 for OS/2 does not r

Re: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

* Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET:
> Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues:
> > Alternatively, the untested patch below should help as well.  Can you
> > try it out?
> 
> Unfortunately the patch didn't work. configure does not execute the new
> case branch although the innermost condition matches.

Hmm.  Is $GCC = yes for this compiler?  That would be surprising.
Why else would the new branch not be matched?

> BTW, the same problem occurs for mpif77 and mpif90 using the PGI
> compilers. Called with -V they produce:
> 
> pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64
> Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
> Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved.

I suppose that could be fixed with the diff below on top
(pending the fix for the issue above).

Thanks,
Ralf

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index e735c75..7323986 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
  ;;
+   *Portland\ Group*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
esac
;;
   esac

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

* Ethan Mallove wrote on Fri, Dec 10, 2010 at 07:41:20PM CET:
> On Thu, Oct/21/2010 06:13:03AM, Ralf Wildenhues wrote:
> > Pass -Wc,-static-intel instead.
> 
> This works like a charm for shared libraries, but for standalone
> executables I get an error like this:
> 
>   ...
>   icc: command line warning #10156: ignoring option '-W'; no argument required
>   /bin/sh ../../../libtool  --tag=CC   --mode=link icc  -Wc,-static-intel -g 
> -finline-functions -fno-strict-aliasing -restrict -pthread 
> -fvisibility=hidden  -export-dynamic   -o orte-iof orte-iof.o 
> ../../../orte/libopen-rte.la -lnsl  -lutil
>   libtool: link: icc -Wl,-static-intel -g -finline-functions 
> -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -o .libs/orte-iof 
> orte-iof.o -Wl,--export-dynamic  ../../../orte/.libs/libopen-rte.so -ldl 
> -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. 
> -Wl,-rpath -Wl,$ORIGIN/../lib
>   ipo: warning #11015: Warning unknown option -static-intel
>   ld: unrecognized -a option `tic-intel'
> 
> Do you know of a way to get this working in both cases: shared libs
> and standalone executable?

Yes.  Use Libtool 2.2.8 or newer.  Quoting from the NEWS file:

  - Fix ancient bug where "-Wc," was turned into "$wl" (typically "-Wl,")
when using the compiler driver to link programs. Now "-Wc," is stripped
just as it is when linking libraries through the compiler driver.

Cheers,
Ralf

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

Re: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

Hello Christian,

* Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET:
> ./configure --enable-shared F77=mpif77 ...
> 
> where mpif77 translates to
> 
> ifort -I/opt/parastation/mpi2-intel/include
> -L/opt/parastation/mpi2-intel/lib -Wl,-rpath
> -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread
> -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64
> -Wl,--enable-new-dtags -lpscom -lrt
> 
> configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC
> flags are discovered though):
> 
> configure:17627: checking for mpif77 option to produce PIC
> configure:17899: result:
> 
> There is no more output concerning the PIC flags in config.log.
> With F77=ifort everything works as expected:
> 
> configure:16805: checking for ifort option to produce PIC
> configure:17077: result: -fPIC

Yeah, that's because libtool.m4 macros partly match by name, unless the
compiler claims to be GCC.  A bit dumb, sure, but it's not easy to avoid
because portable testing of these flags is not trivial.  We might have
to think about a more general way to extract the compiler name from an
MPI driver (-show and -showme come to mind).

For the moment you should be able to work around it using
  configure lt_cv_prog_compiler_pic_F77=-fPIC \
lt_cv_prog_compiler_pic_FC=-fPIC \

but I'm not sure if you also need fixes for missing -static and -Wl,
flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...).
This requires Libtool >= 2.4.

Alternatively, the untested patch below should help as well.  Can you
try it out?

Thanks for the report,
Ralf

Fix PIC flags with mpif77 using ifort on GNU/Linux.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]:
Match Intel compiler also using $CC -V output, to avoid false
negatives with compiler drivers like mpif77.
Report by Christian Rössel.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..e735c75 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
  _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
+*Intel*\ [CF]*Compiler*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ ;;
esac
;;
   esac

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

Re: Libtool and CUDA

[Ralf Wildenhues]

* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 10:56:13PM CET:
> On 12/06/2010 03:25 PM, Ralf Wildenhues wrote:
> >
> >Where do you see that?  As far as I understand, Paweł hasn't actually
> >tried configuring Libtool with something like
> 
> Yeah, I failed to read your entire email this morning, definitely didn't
> have enough coffee. It makes sense now :)
> 
> We have some compilers with whitespace in lt_prog_compiler_pic, I assume
> nvcc doesn't run on those platforms?

So far I know only of GNU/Linux, Windows, and OS X as supported
platforms.  I would be mildly surprised if Nvidia were interested
in porting their code to any other platforms.

Thanks for the feedback, I've pushed the patch now.

Cheers,
Ralf

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

Re: Libtool and CUDA

[Ralf Wildenhues]

* Paweł Daniluk wrote on Mon, Dec 06, 2010 at 11:52:00AM CET:
> Thanks for your prompt reply. Unfortunately the patch doesn't seem
> to change anything. Perhaps I'm doing something completely wrong. I
> expect that libtool after invoking in compile mode with nvcc instead
> of gcc should add -Xcompiler where needed, but I get:

> I have always treated libtool as a black box which just works, and
> know very little about its internals. Nevertheless libtool doesn't
> seem to depend on any external files, and contains no "nvcc" string.
> Maybe I miss something during the compilation phase.

Right.  You need to configure Libtool with CC=nvcc for it to work right
for nvcc.

One alternative is to integrate Libtool in your own (autoconf-using)
package; see 'info libtool "Integrating libtool"' for more information.

Cheers,
Ralf

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

Re: Libtool and CUDA

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 02:49:23PM CET:
> On 12/06/2010 01:07 AM, Ralf Wildenhues wrote:
> >>>OK to apply?
> >>
> >>Unless Pawel reports that it works for him, no. This doesn't make
> >>sense to me.

> >Why?
> 
> Well, perhaps I haven't been drinking enough coffee, but...

Hehe.

> >>>_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
> 
> This assignment didn't work, or was overwritten later.

Where do you see that?  As far as I understand, Paweł hasn't actually
tried configuring Libtool with something like
  ./configure CC=nvcc

because then the assignment will work.

> >>>-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
> 
> So, why will this make any difference?

See above.

> >>>+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
> >>>+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
> >>>$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
> >>>+  fi

Of course the whole support currently won't work if you need to have
both compilers CC=gcc and, say, NVCC=nvcc or so; to workaround you
currently need a subpackage with a sub configure script where you
override CC=$NVCC.

We could fix that in the same way as the proposed Go patch: by
explicitly introducing a new language called Cuda or so.  I'm not
disinclined, but since there exists no free version of this compiler
this might politically be a bit "interesting", to say the least.

I was wrong a bit in my last message though: the manual for version 2.0
does document --shared and -shared, and mentions that other flags
necessary for shared libraries need to be passed through with
-Xcompiler.  Which matches my proposed patch.

Cheers,
Ralf

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

Re: Libtools for Win7-64

[Ralf Wildenhues]

* Arbol One wrote on Mon, Dec 06, 2010 at 02:57:16PM CET:
> Having stated the above and on another front, I would like to know if you
> can direct me to a place where I can download libtools-64bit.

Well, you can just download Libtool 2.4 from
, extract and build it on your systems.
Whichever systems that are.  If you hit one that we don't support (yet),
come back and complain.  We will then work with you to add support for
that system as well.

"We support everything!"  ;-)

Cheers,
Ralf

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

Re: Libtool and CUDA

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 05:23:12AM CET:
> On 12/05/2010 09:34 PM, Ralf Wildenhues wrote:
> 
> >Does this patch fix things for you?  As far as I see, you should be
> >getting -fPIC passed instead of -fno-common, so it's not completely
> >clear that this is right, or what other changes MacPorts has done to
> >their glibtool code over upstream Libtool.  Please also send 'glibtool
> >--config' output.
> >
> >OK to apply?
> 
> Unless Pawel reports that it works for him, no. This doesn't make
> sense to me.

Why?

> MacPorts doesn't appear to have patched their libtool at all:
> http://trac.macports.org/browser/trunk/dports/devel/libtool/Portfile

OK.  The installed glibtool is quite certainly configured to use gcc not
nvcc.  If you configure libtool to use nvcc though, the current code
would get '-Xcompiler -fPIC' on darwin.  I only have nvcc.pdf from an
older version that didn't provide documentation for MacOS installation,
but it didn't mention PIC code at all, which is not too surprising given
that the Cuda-specific parts don't care all that much about what happens
on the CPU.  So IMVHO it would make sense to just pass through the PIC
flag to the underlying gcc compiler driver, whatever the flag is.
What am I missing?

Thanks,
Ralf

> >_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
> >-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
> >+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
> >+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
> >$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
> >+  fi

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

Re: Libtool and CUDA

[Ralf Wildenhues]

Hello Paweł,

* Paweł Daniluk wrote on Sun, Dec 05, 2010 at 11:16:37PM CET:
> I am trying to run nvcc compiler driver through libtool, and I keep
> getting errors about compiler flags which are not supported by nvcc:
> 
> pa...@solea:~/sandbox/libdesc/libdesc/trunk$ /opt/local/bin/glibtool
> --mode=compile --tag=CC nvcc -c -m64 -arch=sm_11 -g  -DTIMER
> -Xcompiler -fno-common -I/usr/local/cuda/include/  -o
> cliques_cuda_int.lo cliques_cuda_int.cu
> glibtool: compile:  nvcc -c -m64 -arch=sm_11 -g -fno-common -DTIMER
> -I/usr/local/cuda/include/ cliques_cuda_int.cu  -fno-common -DPIC -o
> .libs/cliques_cuda_int.o
> nvcc fatal   : Unknown option 'fno-common'
> 
> This is understandable because -fno-common should be prepended with
> -Xcompiler in nvcc call. One would expect that libtool should do it
> automagically, since it has some kind of CUDA support built in.
> 
> What am I doing wrong? Is there any method to override regular
> libtool behavior to put -Xcompiler before flags it adds?
> 
> I'm using libtool 2.4 from MacPorts on Mac OS 10.6.5.

Does this patch fix things for you?  As far as I see, you should be
getting -fPIC passed instead of -fno-common, so it's not completely
clear that this is right, or what other changes MacPorts has done to
their glibtool code over upstream Libtool.  Please also send 'glibtool
--config' output.

OK to apply?  OK to add you to THANKS, Paweł?

Thanks,
Ralf

Fix nvcc PIC setting on darwin.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
: Prepend -Xcompiler to nonempty variable
setting rather than hard-coding -Xcompiler -fPIC, for darwin.
* NEWS, THANKS: Update.
Report by Paweł Daniluk.

diff --git a/NEWS b/NEWS
index 1679c58..d8fc3ea 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 not available) works again.  Regression introduced in v2.2.6-39-g9c3d4d8.
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
+  - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
 
 * Important incompatible changes:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 99d66bb..5f18dcb 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4240,7 +4240,9 @@ m4_if([$1], [CXX], [
 case $cc_basename in
 nvcc*) # Cuda Compiler Driver 2.2
   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
+  fi
   ;;
 esac
   else

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

Re: Libtools for Win7-64

[Ralf Wildenhues]

Hello Arbol,

* Arbol One wrote on Sun, Dec 05, 2010 at 11:47:51PM CET:
> 
> Does anyone know if there is a libtool's port to Win7-64.

First off, welcome to this list.  Please do not top-post nor full-quote
here, also please do not reply to existing threads with new topics;
rather, start a new thread for a new topic, and keep on a thread for an
existing one.  Thank you.

Libtool has been ported to work on MinGW-w64, if that's what you mean.
As far as I know, MinGW-w64 works on Win7.  So yes, Libtool should work
on Win7-64 already.  But maybe you mean to run it in Cygwin; that also
should work on 64bit Windows.

Cheers,
Ralf

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

Re: ld: fatal: file .libs/libglib-2.0.exp: unknown file type

[Ralf Wildenhues]

* Laviticus Stone wrote on Thu, Dec 02, 2010 at 08:53:40AM CET:
> On 12/ 2/10 02:37 AM, Ralf Wildenhues wrote:
> >* Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET:
> >>Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc.
> >>Libtool creates the following command and results:

> >>ld: fatal: file .libs/libglib-2.0.exp: unknown file type
> >>ld: fatal: file processing errors. No output written to
> >>.libs/libglib-2.0.so.0.2600.1
> >>collect2: ld returned 1 exit status
> >
> >Somehow libtool seems to think you're using GNU ld but apparently you're
> >not.  Please send output of
> >   ./libtool --version
> >   ./libtool --config

> Ah yes, netbsd's pkgsrc is configured for
> LD="ld"
> 
> I imagine it was finding gnu lsd, which was in the search path, and
> assumign gnu ld, yet the gcc command it was issuing was using the
> solaris ld in /usr/ccs/bin.
> 
> 
> ps up to date pkgsrc is ltmain.sh (GNU libtool) 2.2.6b

So I gather you can fix/work around your issues by installing a local
Libtool, rebuilding the pkgsrc one with an absolute LD=/path/to/ld as
configure argument, or by adjusting your PATH to find the ld that was
found at the time the pkgsrc Libtool was built.  Right?

Thanks,
Ralf

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

Re: Version mismatch error

[Ralf Wildenhues]

Hello Dan,

* Dan Nicholson wrote on Fri, Dec 03, 2010 at 02:43:04PM CET:
> On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote:
> > Depending on your package setup, that means either passing --install to
> > libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or
> > running aclocal with flags set so that it finds the right Libtool macros
> > (either by some -I include-path, or setting the path in the dirlist file
> > of the aclocal installation), or possibly hand-copying macro files or
> > file contents to your aclocal.m4 file.  Details are documented in the
> > manual.

> It would nice if libtoolize when run without --install (e.g. when run
> by autoreconf without --install) would detect that ltmain.sh and
> libtool.m4 are out of sync and error. One of the most common autotools
> errors I see is that people run bare autoreconf and things break
> strangely (to them) some time later. What do you think?

If we can do a warning or error reliably, then I'm all for it.
I don't think it can be done in libtoolize though, because aclocal may
be called afterwards and fix things up.  autoreconf might call
libtoolize with some special --check argument or so, to tell it that
aclocal --install won't be called afterwards.  Putting the warning into
automake seems possible but an ugly hack.  We could put a check into
autoreconf, but then non-autoreconf users wouldn't get the extra safety.

It's not easy.  :-/

Cheers,
Ralf

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

Re: ld: fatal: file .libs/libglib-2.0.exp: unknown file type

[Ralf Wildenhues]

Hello Laviticus,

* Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET:
> Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc.
> Libtool creates the following command and results:
> 
> gcc -shared  .libs/garray.o .libs/gasyncqueue.o .libs/gatomic.o
[...]
> .libs/giounix.o .libs/gspawn.o  -Wl,--whole-archive
> libcharset/.libs/libcharset.a -Wl,--no-whole-archive  -Wl,-rpath
> -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib -Wl,-rpath
> -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib
> -L/usr/pkgsrc/devel/glib2/work/.buildlink/lib
> /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libpcre.so
> /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libintl.so
> /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libiconv.so -lc -lnsl
> -lsocket -lc  -Wl,-R/usr/pkg/lib   -Wl,-soname -Wl,libglib-2.0.so.0
> -Wl,-retain-symbols-file -Wl,.libs/libglib-2.0.exp -o
> .libs/libglib-2.0.so.0.2600.1
> ld: fatal: file .libs/libglib-2.0.exp: unknown file type
> ld: fatal: file processing errors. No output written to
> .libs/libglib-2.0.so.0.2600.1
> collect2: ld returned 1 exit status

Somehow libtool seems to think you're using GNU ld but apparently you're
not.  Please send output of
  ./libtool --version
  ./libtool --config

Thanks,
Ralf

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

Re: Enhanced OS/2 port

[Ralf Wildenhues]

Hello,

* KO Myung-Hun wrote on Wed, Dec 01, 2010 at 09:24:56AM CET:
> > I've enhanced and fixed libtool 2.4 for OS/2.
> > 
> > Review, please.

> Ping ?

Thanks for your patch, and sorry for the delay.  I'm very busy ATM but I
will try to review it by next week.  It needs some more work.  Also,
patches should generally be sent to the libtool-patches list.

Thanks,
Ralf

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

Re: Problem with libtool adding -pthread

[Ralf Wildenhues]

Hello John,

* John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET:
> I am tring to link with libtool using the compiler
> wrappers on a Cray and with pgi.
> 
> At final link, libtool inserts the flag, -pthread, which
> causes the compiler to fail.  This is shown below.

Uh, that's probably because one of the installed libtool libraries you
link against was compiled with GCC and with -pthread, so it has that
flag in its inherited_linker_flags.  Easiest workaround would be to
remove that from the *.la file.

And yes, this is a libtool bug.  It should translate -pthread to the
spelling that your compiler uses for enabling threads.

Thanks for the report,
Ralf

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

Re: adding conditionally a c++ file implies static linking with g++

[Ralf Wildenhues]

[ let's drop the automake list ]

* Vincent Torri wrote on Sat, Nov 20, 2010 at 12:55:27AM CET:
> 
> Now, i've remarked a side effect. What I'm building is a shared lib
> that is only opened by dlopen. So I pass --tag=disable-static to
> pdf_la_LIBTOOLFLAGS. When using foo_LINK, the static lib is build,
> hence installed. Is there a way to forbid the build of the static
> lib.
> 
> Of course, I can always delete it during install with the
> install-data-hook rule, but i would like to not build it.

Please show a small full example, that way it is easier to see what code
exactly you have, and what is happening.

If you need a small example setup to start with:

cat >configure.ac <<\EOF
AC_INIT([a], [1])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_CXX
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

cat >Makefile.am <<\EOF
lib_LTLIBRARIES =
EOF

autoreconf -vi

Cheers,
Ralf

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

Re: Libtool can't find libgcc_s

[Ralf Wildenhues]

* Ethan Mallove wrote on Wed, Nov 10, 2010 at 09:02:18PM CET:
> On Wed, Nov/10/2010 07:59:38PM, Ralf Wildenhues wrote:
> > * ethan.mall...@oracle.com wrote on Wed, Nov 10, 2010 at 07:48:14PM CET:
> > > Libtool seems to get confused about where libgcc_s is, e.g.,
> > >   
> > >   $ /bin/sh ../../../libtool --tag=CXX --mode=link icpc -lgcc_s foo.c -o 
> > > a.out
> > >   libtool: link: icpc foo.c -o a.out  -lgcc_s
> > >   ld: skipping incompatible 
> > > /usr/lib/gcc/x86_64-redhat-linux/3.4.6//libgcc_s.so when searching for 
> > > -lgcc_s
> > >   ld: cannot find -lgcc_s
> > > 
> > > If I help it out with my own -L, it works:
> > > 
> > >   $ /bin/sh ../../../libtool --tag=CXX --mode=link icpc 
> > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -lgcc_s foo.c -o a.out
> > >   libtool: link: icpc foo.c -o a.out  
> > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -lgcc_s
> > > 
> > >   $ ../../../libtool --version
> > >   ltmain.sh (GNU libtool) 2.2.6b
> > 
> > I think the first question to ask is why are you passing -lgcc_s in the
> > first place?
> 
> I don't know.  Does libtoolize add -lgcc_s to postdeps?  The above is
> a stripped down link line that happens when I build the Open MPI trunk
> using Intel 11.0 compilers.

postdeps are only expanded by 'libtool', but you posted a libtool
command line that already included -lgcc_s, IOW, that particular
argument was not added by libtool but in the Makefile already.
You need to find out which Makefile macro set this, and since
presumably the macro was @substituted@ by some configure script,
find the configure code that set it.  Otherwise I cannot say more.

Cheers,
Ralf


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

Re: Libtool can't find libgcc_s

[Ralf Wildenhues]

Hello Ethan,

* ethan.mall...@oracle.com wrote on Wed, Nov 10, 2010 at 07:48:14PM CET:
> Libtool seems to get confused about where libgcc_s is, e.g.,
>   
>   $ /bin/sh ../../../libtool --tag=CXX --mode=link icpc -lgcc_s foo.c -o a.out
>   libtool: link: icpc foo.c -o a.out  -lgcc_s
>   ld: skipping incompatible 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6//libgcc_s.so when searching for -lgcc_s
>   ld: cannot find -lgcc_s
> 
> If I help it out with my own -L, it works:
> 
>   $ /bin/sh ../../../libtool --tag=CXX --mode=link icpc 
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -lgcc_s foo.c -o a.out
>   libtool: link: icpc foo.c -o a.out  
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 -lgcc_s
> 
>   $ ../../../libtool --version
>   ltmain.sh (GNU libtool) 2.2.6b

I think the first question to ask is why are you passing -lgcc_s in the
first place?  The instance that decided that that would be necessary
should also decide which libgcc_s to use, and whether to prepend
suitable -L flags.

Aside, please pass -l flags after the objects that need the libraries,
that is guaranteed to work portably, i.e., also for static linking.

Cheers,
Ralf

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

Re: Problem with deplibs

[Ralf Wildenhues]

Hello Bruno,

* Bruno Barberi Gnecco wrote on Tue, Nov 09, 2010 at 08:47:08PM CET:
>   I'm facing a problem compiling a library with libtool (via
> automake/autoconf). It depends on OpenCV, and deplibs links against
> all indirect libraries as well (that is, it adds the libs such as
> "/usr/lib64/libhighgui.so /usr/lib64/libgthread-2.0.so
> /usr/lib64/libgtk-x11-2.0.so /usr/lib64/libgdk-x11-2.0.so").
> 
>   For some reason this breaks the application (don't ask me why, the
> cameras just stop working). All I need is to link only against the
> libraries I specify. I though "link_all_deplibs=no" in configure.in
> would achieve this, but it has no effect at all.

You need to provide more information for us to be able to help.

If I were you, I'd start trying to find out why additional DT_NEEDED
entries would break an application.  That usually only happens because
incompatible library versions, or even multiple versions of a library,
are linked in.  Looking at make output, esp. the libtool --mode=link
commands and all output they generate, can help here.

In order to judge whether link_all_deplibs=no works or not, we'd need to
see, in addition to said build output, probably also the contents of the
created .la file, plus that of the .la files that belong to libraries
that are linked in.  This data is usually contained in the output of the
--mode=link command with --debug added as first libtool argument (gzip
large outputs).

Also, './libtool --config' output is usually helpful.

Hope that helps.

Cheers,
Ralf

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

Re: How to create only target shared library at place not ending in rpath?

[Ralf Wildenhues]

Hello Vitaly,

please don't top-post, thank you.

* Vitaly V. Ch wrote on Tue, Nov 02, 2010 at 09:52:41AM CET:
> On Mon, Nov 1, 2010 at 6:30 PM, Ralf Wildenhues wrote:
> > Would you like to avoid building both static and shared libraries?
> > Use --disable-static or --disable-shared at configure time.
> >
> > Would you like to speed up 'make install'?  Use the newest Automake
> > version, in case you're using a version older than 1.11 now.
> >
> > Would you like to not install some of the shared libraries you build,
> > but still create them as shared rather than convenience archives?
> > Use noinst_LTLIBRARIES but also pass '-rpath /nowhere' or so in
> > libfoo_la_LDFLAGS.

> I have few tens of projects which I need install into few tens of
> sysroots. Currently it's to slow in following cases:
> 
> 1) libtool --mode=link  create shared objects which I newer use.

Why are they then created even?  Can you disable their creation by some
--disable-* configure option or similar?  If not, can you modify your
project to add such options?

> 2) each libtool --mode=install create same shared objects binaries for
> each sysroot.

Is this very slow?  In absolute time, or compared to the rest of your
project overhead, and is the latter very low?

Cheers,
Ralf

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

Re: DLL creation and static libs

[Ralf Wildenhues]

Hello Matěj,

* Matěj Týč wrote on Wed, Oct 27, 2010 at 10:44:25PM CEST:
> I have came across a libtool issue that complicates my life quite much.
> The essence of the problem is that libtool refuses to make a DLL if it
> is supposed to link a static library into the DLL. I have learned that
> this is a good assumption since the majority static libs don't contain
> PIC code, which would not work at all in the library.
[...]
> The trouble is that in this very case, it is OK to link with libuuid.a,
> because it contains data only. However libtool doesn't want to link with
> it no matter what.

Also, w32 COFF essentially doesn't produce different code for shared
libraries.

> The situation is described in more detail in the link below by people
> who understand the stuff more:
> http://mingw-users.1079350.n2.nabble.com/undefined-ref-of-win32-function-with-mingw32msvc-td1089772.html
> So now the question is: What to do now? Maybe the mingw project is
> wrong?

No, I don't think so.

> Or maybe it can be checked somehow whether a static library
> contains data only so it can be linked without problems? 

Maybe that.

Since libuuid seems to be fairly special, I don't have any problem with
special-casing it (as we already do for -lc -lm and maybe a couple of
other libraries).

OTOH, if the w32 maintainers agree, then we can also give in and allow
linking against static libraries plainly.  I tried the trivial patch
(set deplibs_check_method to pass_all) a while ago but that caused a
number of test failures, so somebody would at least have to look into
this issue.

Thanks for the report,
Ralf

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

Re: How to create only target shared library at place not ending in rpath?

[Ralf Wildenhues]

Hello Vitaly,

* Vitaly V. Ch wrote on Mon, Nov 01, 2010 at 02:01:44PM CET:
> I'm try to speed up compilation of my project by removing overhead
> stages. Especially time of installation.

Please also try to speed up communication for us by slowing down
communication on your end of the mail writing: Please state your problem
more clearly, so we don't have to ask what you meant.  Thank you.

Would you like to avoid building both static and shared libraries?
Use --disable-static or --disable-shared at configure time.

Would you like to speed up 'make install'?  Use the newest Automake
version, in case you're using a version older than 1.11 now.

Would you like to not install some of the shared libraries you build,
but still create them as shared rather than convenience archives?
Use noinst_LTLIBRARIES but also pass '-rpath /nowhere' or so in
libfoo_la_LDFLAGS.

Hope that helps.

Cheers,
Ralf

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

Re: How does libtool decide which so to link against?

[Ralf Wildenhues]

Hello Giles,

please don't top-post, thank you.

* Giles Anderson wrote on Tue, Oct 26, 2010 at 12:00:55AM CEST:
> Thanks Mike, Daniel and please excuse my ignorance in questioning libtool.

Oh, no need for that.  We're all ignorant one way or another.  ;-)

> Do you know of a definitive guide & explanation of the correct way to
> define/use SONAMEs etc?

There is not always one correct way.  However, there is one way that the
Libtool manual recommends, and following it has turned out useful for
both developers and users of a library.  The Libtool approach is to not
change the name part of the SONAME (on most systems, anyway), but only
to modify the version part, with a custom, per-system mapping from
abstract interface numbers to SONAME version.  The API is described in
info Libtool Versioning.

Hope that helps.

Cheers,
Ralf

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

Re: libtool-2.2.10: print vs. printf

[Ralf Wildenhues]

Hi Markus.

* Markus Duft wrote on Wed, Oct 27, 2010 at 09:13:17AM CEST:
> On 10/23/2010 09:16 AM, Ralf Wildenhues wrote:
> > * Markus Duft wrote on Fri, Oct 22, 2010 at 09:59:27AM CEST:
> >> or am i wrong, and it is specified, that the shells that configure and
> >> make use have to be the same?
> > 
> > Exactly.  The bug is that the shell used during configure, and the shell
> > invoking libtool, are not the same.  This bug can be caused by different
> > things, either you setting SHELL in Makefile.in, or SHELL or
> > CONFIG_SHELL in configure.ac, or something similar.  We cannot tell
> > without more details.
> 
> oh, well - good to know that ;) is there some documentation i can refer to
> wrt to this requirement? it seems we need to adapt some things, as this was
> not the case with previous versions - and i need to argue the need to do the
> work ;)

Good point actually.  We don't currently have such documentation.  The
Autoconf manual has some bits on $CONFIG_SHELL, but nothing about the
libtool script of course.

OK to fix that with the patch below, and add Markus to THANKS?

Thanks,
Ralf

docs: mention shell requirement for libtool script.

* doc/libtool.texi (Invoking libtool): Document that the shell
used to invoke libtool needs to be the same used to configure
it.
* THANKS: Update.
Report by Markus Duft.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 076b67b..c84b92a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1326,6 +1326,12 @@ can be achieved using either option @option{-v} or option
 Print libtool version information and exit.
 @end table
 
+The current @command{libtool} implementation is done with a shell script
+that needs to be invoked by the shell which @command{configure} chose for
+configuring @command{libtool} (@pxref{config.status Invocation, , The
+Autoconf Manual, autoconf, The Autoconf Manual}).  This shell is set in
+the she-bang (@samp{#!}) line of the @command{libtool} script.
+
 The @var{mode-args} are a variable number of arguments, depending on the
 selected operation mode.  In general, each @var{mode-arg} is interpreted
 by programs libtool invokes, rather than libtool itself.

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

Re: --with-sysroot conflicts in binutils and gcc

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 10:27:19AM CEST:
> On 10/23/2010 10:01 AM, Ralf Wildenhues wrote:
> >* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 09:38:43AM CEST:
> >>Also, libtool should probably ignore --with-sysroot if build==host;
> >>native compilers are never build with a sysroot in practice.
> >
> >OK, so this would mean there is no way --with-sysroot could be (ab)used
> >to fix the DESTDIR (re)link failures that libtool users experience
> >today.  Desired side-effect?
> 
> No, do you have a pointer?

It would be the next more complex step from tests/destdir.at:
package A provides libA, installed below $(DESTDIR)$(libdir),
package B provides libB depends on libA, installed below same,
package C provides Prog depends on libB.  Depending on how you
pass flags, the installed libB.la either contains the path to
libA including the $(DESTDIR) prefix (which would be right when
C is built before the destdir is moved to the final location,
or afterwards (but then building C before moving will not work).

Anyway you do it, one of the situations will at least look in
the wrong directories (either /usr/lib with missing destdir
prefix, or $(DESTDIR)$(libdir) on the target system).

I haven't tried whether --with-sysroot helps to work around that,
but I kind of figured it would.

> I don't understand what failure is there
> that cannot be fixed by --enable-fast-install (so that relink
> doesn't happen at install time), no?

Relink may just expose the issue to be a hard failure, but the
wrong-directory search will be there no matter what, I think.

That said, --enable-fast-install still has issues on GNU/Linux, too.

> >The rest of your proposed patch could also be wrapped in
> >gcc/configure.ac, I'm not sure whether it belongs there rather than in
> >Libtool?
> 
> I don't recall if binutils needs to know about a sysroot.

It probably does.  At least there are switches for --with-sysroot in ld,
gold, and gdb.

> Another solution is to do the following renaming in GCC
> 
> --with-sysroot -> --enable-sysroot
> --with-build-sysroot -> --with-target-sysroot
> (not existing) -> --with-host-sysroot
> 
> The task of mapping from old to new arguments is given to the
> toplevel configure script; subdirectories _never_ see a
> $with_sysroot with a meaning other than the one Libtool uses.  To do
> this, the toplevel configure simply has to mangle the
> {host,build,target}_configure_args to include the correct args:
> 
> --without-sysroot for build_configure_args
> 
> --with-sysroot=${with_host_sysroot:-no}
> --enable-sysroot=${with_sysroot:-${enable_sysroot:-no}}
> for host_configure_args
> 
> --with-sysroot=${with_target_sysroot:-${with_build_sysroot:-no}}
> for target_configure_args.
> 
> The patch should be relatively small, so OE can backport it to 4.5
> if they wish.  Adjusting the docs and selling the idea on gcc@ is
> probably harder than writing it.

Oh yes.  I'm honestly unsure however which would be the best solution
/in principle/, even apart from the practical selling point and GCC
compatibility issues.  You have more experience with GCC.  While I don't
mind changing new Libtool API here if that helps, I do think we should
pursue a solution that is the most logical in the long term.

Thanks for looking into this,
Ralf

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

Re: undefined reference error

[Ralf Wildenhues]

Hello Sergio,

* Sergio Belkin wrote on Wed, Oct 20, 2010 at 05:08:51PM CEST:
> I have a project that is a library that links against libresolv,
> It works fine on recent distros: Ubuntu 10.x  Fedora 13, Mandriva
> 2010.1 but on Centos 5.x I get the following errors
> 
> g++ -DHAVE_CONFIG_H -I.  -I./include -I/usr/include/postgresql  -O3
> -ansi   -Wall -Wno-deprecated  -D_FORTIFY_SOURCE=0 -MT testUpLog.o -MD
> -MP -MF .deps/testUpLog.Tpo -c -o testUpLog.o testUpLog.cc
> mv -f .deps/testUpLog.Tpo .deps/testUpLog.Po
> /bin/sh ./libtool --tag=CXX   --mode=link g++  -O3 -ansi   -Wall
> -Wno-deprecated  -D_FORTIFY_SOURCE=0  -L/usr/lib64 -L/lib64
> -L/usr/lib64/mysql -o testUpLog testUpLog.o libUpTools.la -lpq
> -lmysqlclient -lssl -lpthread
> libtool: link: g++ -O3 -ansi -Wall -Wno-deprecated -D_FORTIFY_SOURCE=0
> -o .libs/testUpLog testUpLog.o  -L/usr/lib64 -L/lib64
> -L/usr/lib64/mysql ./.libs/libUpTools.so -lpq -lmysqlclient -lssl
> -lpthread
> ./.libs/libUpTools.so: undefined reference to `__ns_name_uncompress'
> ./.libs/libUpTools.so: undefined reference to `__ns_initparse'
> ./.libs/libUpTools.so: undefined reference to `__ns_parserr'
> collect2: ld returned 1 exit status
> make[1]: *** [testUpLog] Error 1

Don't you need to link against libresolv?  Try adding -lresolv to
testUpLog_LDADD.

Cheers,
Ralf

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

Re: --with-sysroot conflicts in binutils and gcc

[Ralf Wildenhues]

Hi Paolo,

* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 09:38:43AM CEST:
> Also, libtool should probably ignore --with-sysroot if build==host;
> native compilers are never build with a sysroot in practice.

OK, so this would mean there is no way --with-sysroot could be (ab)used
to fix the DESTDIR (re)link failures that libtool users experience
today.  Desired side-effect?

The rest of your proposed patch could also be wrapped in
gcc/configure.ac, I'm not sure whether it belongs there rather than in
Libtool?

> This however
> would still conflict with GCC when cross-building a native compiler, or
> for a sysrooted Canadian cross.  The attached patch could be made to work
> in this scenario if you can afford using --without-build-sysroot.
> 
> Another possibility is to have an environment variable which would
> override the command-line options (ick).  Then the GCC toplevel can
> set it as they wish.

Ick.

Thanks,
Ralf

> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -1183,19 +1183,21 @@ AC_DEFUN([_LT_WITH_SYSROOT],
>  AC_ARG_WITH([sysroot],
>  [  --with-sysroot[=DIR] Search for dependent libraries within DIR
>  (or the compiler's sysroot if not specified).],
> -[], [with_sysroot=no])
> +[], [with_sysroot=${with_build_sysroot}])
>  
>  dnl lt_sysroot will always be passed unquoted.  We quote it here
>  dnl in case the user passed a directory name.
>  lt_sysroot=
>  case ${with_sysroot} in #(
>   yes)
> -   if test "$GCC" = yes; then
> +   if test "$GCC" = yes && test "$build" != "$host"; then
>   lt_sysroot=`$CC --print-sysroot 2>/dev/null`
> fi
> ;; #(
>   /*)
> -   lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
> +   if test "$build" != "$host"; then
> + lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
> +   fi
> ;; #(
>   no|'')
> ;; #(

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

Re: --with-sysroot conflicts in binutils and gcc

[Ralf Wildenhues]

Hello Khem,

* Khem Raj wrote on Thu, Oct 21, 2010 at 10:23:51PM CEST:
> When building gcc and binutils in a cross environment there is a
> conflict with respect to --with-sysroot libtool 2.4 expects
> --with-sysroot on configure options to use sysroot which is fine now
> the build time sysroot and run time sysroot for gcc and binutils might
> differ eg. when building binutils build=x86_64-linux
> host=arm-linux-gnueabi target=arm-linux-gnueabi, in this case we are
> building binutils like a target package in terms of cross compiling
> but if we use --with-sysroot without a value then libtool will guess
> it right pointing to build time sysroot but binutils will then use a
> default sysroot which is not pointing to / on the target file system,
> if we set --with-sysroot="/" then binutils will get it right but
> libtool will get it wrong.
> 
> toolchain has two options when it comes to sysroot --with-sysroot and
> --with-build-sysroot I think libtool should also differentiate between
> two and set both to same if not explicitly set during configure time.
> I think libtool means to use build time sysroot and not runtime
> sysroot its just that configure options are colliding

Can we take a step back here.  Did you regenerate the GCC and binutils
source trees with Libtool 2.4?  Upstream hasn't done that move yet,
precisely because the --with-sysroot issues need to be hashed out first.

Or are you trying to build GCC as well as other sources with the same
configure options?

Thanks,
Ralf

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

Re: libtool-2.2.10: print vs. printf

[Ralf Wildenhues]

Hello Markus,

* Markus Duft wrote on Fri, Oct 22, 2010 at 09:59:27AM CEST:
> I have a question: In the new libtool, $ECHO is checked for in
> libtool.me, preferring print over printf over a fallback echo. Now, on
> interix, i have a KSH as /bin/sh which has print builtin, and thus
> configure chooses it. now when building, libtool is called using another
> shell (a bash), and things (of course) go wrong.
> 
> as a workaround now i can use CONFIG_SHELL to set another shell (and
> call configure using that shell explicitly! it does not seem sufficient
> in all cases to set CONFIG_SHELL.), but i feel that it is not so good to
> rely on shell builtins which may not be there when make is called... any
> insights?
> 
> or am i wrong, and it is specified, that the shells that configure and
> make use have to be the same?

Exactly.  The bug is that the shell used during configure, and the shell
invoking libtool, are not the same.  This bug can be caused by different
things, either you setting SHELL in Makefile.in, or SHELL or
CONFIG_SHELL in configure.ac, or something similar.  We cannot tell
without more details.

Cheers,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

Hello Ethan,

* Ethan Mallove wrote on Wed, Oct 20, 2010 at 10:32:11PM CEST:
> > It looks like that gives us the link line we want, yet we still get the
> > libimf.so dependency:
> > 
> > $ /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/lib/lib64 mpicxx.lo intercepts.lo comm.lo 
> > datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl  -lutil 
> > 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
> > $ ldd .libs/libmpi_cxx.so.0.0.0
> > libmpi.so.0 => not found
> > libdl.so.2 => /lib64/libdl.so.2 (0x2b35a9499000)
> > libnsl.so.1 => /lib64/libnsl.so.1 (0x2b35a969e000)
> > libutil.so.1 => /lib64/libutil.so.1 (0x2b35a98b6000)
> > libimf.so => not found
> > libsvml.so => not found
> > libm.so.6 => /lib64/libm.so.6 (0x2b35a9aba000)
> > libintlc.so.5 => not found
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b35a9d3e000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x2b35a9f4c000)
> > libc.so.6 => /lib64/libc.so.6 (0x2b35aa167000)
> > /lib64/ld-linux-x86-64.so.2 (0x003a2000)
> 
> The problem is that Libtool is stripping -static-intel from the link
> line.  How can I prevent this?

Pass -Wc,-static-intel instead.

Cheers,
Ralf

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

Re: Version mismatch error

[Ralf Wildenhues]

Hello Sergio,

* Sergio Belkin wrote on Mon, Oct 18, 2010 at 06:33:17PM CEST:
> I have project with autotools made on Ubuntu, but when I want to
> compile on CentOS it ends with error:
> 
> libtool: Version mismatch error.  This is libtool 2.2.6b
> Debian-2.2.6b-2ubuntu1, but the
> libtool: definition of this LT_INIT comes from libtool 2.2.10.
> libtool: You should recreate aclocal.m4 with macros from libtool
> 2.2.6b Debian-2.2.6b-2ubuntu1
> libtool: and run autoconf again.
> 
> I was using   2.2.10 (compiled) on CentOS. Is there not compatibility
> between 2.2.x releases. Is there not a way to make it works with any
> libtool 2.2.x?

The 2.2.x releases are all compatible in the sense that the command-line
API between them is upward-compatible.  However, the version from which
the libtool.m4 and ltversion.m4 (and a couple more files) macros are
taken, and the file ltmain.sh is from, must be exactly identical.  The
API between ltmain and the macros is mostly an internal detail and not
guaranteed to remain stable between releases.  So if you re-libtoolize,
copying in a new ltmain.sh, you need to also ensure that the new macros
are used.

Depending on your package setup, that means either passing --install to
libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or
running aclocal with flags set so that it finds the right Libtool macros
(either by some -I include-path, or setting the path in the dirlist file
of the aclocal installation), or possibly hand-copying macro files or
file contents to your aclocal.m4 file.  Details are documented in the
manual.

Hope that helps.

Cheers,
Ralf

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

Re: Unwanted shared runtime libraries getting added

[Ralf Wildenhues]

* Ethan Mallove wrote on Fri, Oct 15, 2010 at 08:59:38PM CEST:
> On Mon, Oct/11/2010 09:01:56PM, Ralf Wildenhues wrote:
[...]
> > 
> > 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.
> 
> I end up getting *both* --tag=CXX and ---tag=CC:
> 
> /bin/sh ../../../libtool  --tag=CXX --tag=CC  --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 
> /opt/SUNWhpc/HPC9.0/intel/lib libmpi_cxx_la-mpicxx.lo 
> libmpi_cxx_la-intercepts.lo libmpi_cxx_la-comm.lo libmpi_cxx_la-datatype.lo 
> libmpi_cxx_la-win.lo libmpi_cxx_la-file.lo ../../../ompi/libmpi.la -lnsl  
> -lutil 

OK, sorry, the following should work instead:

libmpi_cxx_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
$(CXXFLAGS) $(libmpi_cxx_la_LDFLAGS) $(LDFLAGS) -o $@

If you don't set libmpi_cxx_la_LDFLAGS yourself, you should replace that
with AM_LDFLAGS in the above string.

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 11:53:55PM CEST:
> Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> > Two spaces after period.
> 
> I consider that part of texification.

Sure.

> >> 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?
> 
> I don't remember ever having problems with that, but I suppose two () could
> be written as { return three - one (); } if that makes you sleep better.

I don't care much, but that's the difference that exposes missing -fPIC
on GNU/Linux (non-x86) systems.  Suppose that bit is irrelevant for
COFF.

> >> an explicit __declspec(dllexport) is seen. The GNU tools is doing this
> >> 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?)
> 
> You have to decorate all symbols you wish to export, because if you miss
> some, auto-export will have been disabled by the symbols that was indeed
> decorated.

Right.  But to me, the sentence can be read to imply that, when the user
has forgotten to decorate some symbols, then GNU tools will somehow
still magically do TRT.

Maybe an example is in order here, to explain why I stumbled over this:
you include third-party code in your project (e.g., helper functions
like those from gnulib), and that code is decorated (unlike gnulib)
but your own code is not.  Boom, that's trouble, but not in the way
you intended.

> I'll still remove "all" though, because you really only need
> to decorate the symbols that you wish to export, and that is typically
> not *all* symbols.

OK.  That also avoids my (arguably weird) misreading.

> >> 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?
> 
> I don't know. I felt that a bit of history wouldn't hurt here. Maybe I'm
> just muddying the waters?

Oh, mentioning older GNU tools seems like a good idea to me; but I also
think that you can regard them as irrelevant for current libtool
operation.

> >> 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.
> 
> I don't know where this is spelled out, and it is intentionally vague as
> I don't know all the answers.

OK.  Maybe somebody else can fill this in, or we leave it like this for
now.

> >> For older GNU tools and other proprietary tools there is no generic way
> >> to make it possible to consume either of the DLL or the static library
> >> without user intervention, the tools needs to be told what is intended.
> >> Or, to be exact, the author are not aware of any generic way. One
> > 
> > s/are/is/  This sounds a bit awkward still.
> 
> Don't know what to do about that.

Well, how about let's remove the sentence starting with "Or"?

> Here's an update:

Looks good to me, given comments above.

Thanks,
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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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: 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: 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: 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

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: 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

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 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]

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]

* 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]

* 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]

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]

* 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]

* 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]

* 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]

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]

> * 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: 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]

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: 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: 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: 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]

* 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]

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: 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