How to create shared library(dll) without lib prefix ?
Let a project use libtool to make libraries. In case of mingw build (cross-compilation) in many cases is good dll to be without lib prefix. In these cases cross-compilation can create dlls with same names as native build and those dlls can be used instead native build. The name of import library can left libNAME.dll.a. When building shared libraries on unix usually Makefile.am contain lib_LTLIBRARIES = libNAME.la and result is libNAME.so... It is similar to case for pcre.la (topic dll names on windows) but with lib-prefix for la-file. How to do this? Notes: - libtool macro AC_LIBTOOL_SYS_DYNAMIC_LINKER don't preserve libname_spec set by CONFIG_SITE so that I cannot use libname_spec=\$name in CONFIG_SITE file; - same for soname_spec; - LDFLAGS -module is only to inform automake that we use nonstandard name, i.e without lib prefix. This is not my case since for other systems lib prefix is fine. Also note that with argument -module file is installed in libdir (!) and without in bindir; - to use def-file with content LIBRARY NAME.dll and to pass to linker by example with -export-symbols. In this case import library libNAME.dll.a is created for NAME.dll but dll-name is libNAME.dll. We can rename dll (to remove lib prefix) and in file libNAME.la to remove lib-prefix in dlname. In this case libtool will install NAME.dll, i.e. without lib prefix, but create in libdir la-file with dlname='../bin/libNAME.dll' so that we should edit again. More info: Command: $i386-mingw32msvc-gcc -shared ... -o .libs/NAME.dll ... -Xlinker --out-implib -Xlinker .libs/libNAME.dll.a create dll without lib prefix and put NAME.dll in import library. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to create shared library(dll) without lib prefix ?
I prepare two possible patches against libtool version 1.5.22. Both
patches change soname_spec if flag to avoid lib-prefix is set.
1.) libtool-1.5.22.ACNOPREFIX.patch
This patch define autoconf macro AC_LIBTOOL_NOSHPREFIX.
In is suitable for project, as example libiconv, where build with
non-gcc win32 compilers produce dlls without lib-prefix. In this case
author{s} can put AC_LIBTOOL_NOSHPREFIX in configure[.in|ac] to ensure
compatible dlls for mingw builds.
2.) libtool-1.5.22.ARGPREFIX.patch
This patch add argument --without-dllprefix to configure, so that
package creator(distributors) can decide how to create dlls.
Please comment,
Roumen
Roumen Petrov wrote:
Let a project use libtool to make libraries.
In case of mingw build (cross-compilation) in many cases is good dll
to be without lib prefix.
In these cases cross-compilation can create dlls with same names as
native build and those dlls can be used instead native build.
The name of import library can left libNAME.dll.a.
When building shared libraries on unix usually Makefile.am contain
lib_LTLIBRARIES = libNAME.la and result is libNAME.so...
It is similar to case for pcre.la (topic dll names on windows) but
with lib-prefix for la-file.
How to do this?
Notes:
- libtool macro AC_LIBTOOL_SYS_DYNAMIC_LINKER don't preserve
libname_spec set by CONFIG_SITE so that I cannot use
libname_spec=\$name in CONFIG_SITE file;
- same for soname_spec;
- LDFLAGS -module is only to inform automake that we use nonstandard
name, i.e without lib prefix.
This is not my case since for other systems lib prefix is fine.
Also note that with argument -module file is installed in libdir (!)
and without in bindir;
- to use def-file with content LIBRARY NAME.dll and to pass to
linker by example with -export-symbols.
In this case import library libNAME.dll.a is created for NAME.dll
but dll-name is libNAME.dll.
We can rename dll (to remove lib prefix) and in file libNAME.la to
remove lib-prefix in dlname.
In this case libtool will install NAME.dll, i.e. without lib prefix,
but create in libdir la-file with dlname='../bin/libNAME.dll' so that
we should edit again.
More info:
Command:
$i386-mingw32msvc-gcc -shared ... -o .libs/NAME.dll ... -Xlinker
--out-implib -Xlinker .libs/libNAME.dll.a
create dll without lib prefix and put NAME.dll in import library.
Roumen
--- libtool.m4.SHPREFIX 2006-01-18 04:42:04.0 +0200
+++ libtool.m4 2007-07-23 00:04:51.0 +0300
@@ -200,6 +200,8 @@
AC_PROVIDE_IFELSE([AC_LIBTOOL_DLOPEN], enable_dlopen=yes, enable_dlopen=no)
AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
enable_win32_dll=yes, enable_win32_dll=no)
+AC_PROVIDE_IFELSE([AC_LIBTOOL_NOSHPREFIX],
+avoid_shprefix=yes, avoid_shprefix=no)
AC_ARG_ENABLE([libtool-lock],
[AC_HELP_STRING([--disable-libtool-lock],
@@ -1328,8 +1330,12 @@
sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
;;
mingw*)
- # MinGW DLLs use traditional 'lib' prefix
+ if test x$avoid_shprefix = xyes; then
+soname_spec='${name}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ else
+# use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ fi
sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: |
$SED -e s/^libraries:// -e s,=/,/,g`
if echo $sys_lib_search_path_spec | [grep ';[c-zC-Z]:/' /dev/null];
then
# It is most probably a Windows format PATH printed by
@@ -1902,6 +1908,14 @@
])# AC_LIBTOOL_WIN32_DLL
+# AC_LIBTOOL_NOSHPREFIX
+#
+# blabla...
+AC_DEFUN([AC_LIBTOOL_NOSHPREFIX],
+[AC_BEFORE([$0], [AC_LIBTOOL_SETUP])
+])# AC_LIBTOOL_NOSHPREFIX
+
+
# AC_ENABLE_SHARED([DEFAULT])
# ---
# implement the --enable-shared flag
--- libtool.m4.ARGPREFIX2006-01-18 04:42:04.0 +0200
+++ libtool.m4 2007-07-24 23:13:04.0 +0300
@@ -1328,8 +1328,17 @@
sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
;;
mingw*)
- # MinGW DLLs use traditional 'lib' prefix
- soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ AC_ARG_WITH([dllprefix],
+[AS_HELP_STRING([--without-dllprefix],
+ [disable traditional 'lib' dll-prefix])],
+[],
+[with_dllprefix=no])
+ if test x$with_dllprefix = xyes; then
+# use traditional 'lib' prefix
+soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ else
+soname_spec='${name}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ fi
sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: |
$SED -e s/^libraries:// -e s,=/,/,g`
if echo $sys_lib_search_path_spec | [grep ';[c-zC-Z]:/' /dev/null];
then
# It is most probably a Windows
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: Roumen Petrov wrote: [SNIP] Well, I think I've figured it out today (albeit I'm testing on a different machine, similar software though) and there are two executables. One in the build directory and one in .libs. e.g. src/ .libs/ libmofo-1.dll test/ libtest.exe -- Doesn't seem to work? No idea what this is... Binary libtest.exe is created from .libs/lt-libtest.c. Please see comments in c-file - binary try to run /bin/sh libtest. On build system this is useless: - binfmt_misc is setup to use wine to run PE executable: Command strace will show whats happen. On my build system its fail since: a) /bin/sh don't exists and b) I will not install born shell(PE executable) only to run the test (see bellow). - on host system : first you should copy whole build three and second /bin/sh should exist as native executable on current drive. I found this executable useless if we do cross-compilation but I could live with this. libtest This is born shell wrapper script for .libs/libtest.exe. If you like to test something (command make check) on build system you should run this script(!) (note without .exe suffix) from Makefile[.in|.am] to do the tests. .libs/ libtest.exe-- Will work when libmofo-1.dll is in the path, e.g. copied to this dir. Yes .libs/libtest.exe is real executable and it is installed by command make install. Can anybody explain what libtool is doing?? It appears to do a lot of nifty stuff, but I don't see any dependencies on libmofo from libtest.exe in either case. I'll attach a minimal example when I'm back at work tomorrow. And the directory it runs from (.libs) indicates it is actually the source lt-libtest.c that relies on a shell, so as soon as I move the executable to a virgin computer without Cygwin, the program libtest.exe won't work. I hope explanation above help. [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
Usually /etc/ld.so.conf contain /usr/local/lib. Dunno why this path is not set on you host. Benoit SIGOURE wrote: Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `-lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable without manually setting LD_LIBRARY_PATH. Shouldn't libtool do something about this? I know that Boost doesn't come with .la files but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't it use -rpath and friends when available/required? What would be the best solution to handle this issue? Write my own check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and check if linking against -lboost_thread* requires a -rpath or not, and if it does, automagically add it to BOOST_THREADS_LDFLAGS? That sounds tedious. And how is it going to work on, say, OSX, where there is no -rpath/-R? Moreover, I don't see how to do such a check while preserving cross-compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? Or maybe analyzing the output of `ldd'? But it surely isn't something standard, for instance on OSX it's `otool -L' and it requires the package odcctools...). Any suggestion would be appreciated. Thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool modules and symbol clashes
Russ Allbery wrote: Simon White [EMAIL PROTECTED] writes: However if one of those modules internally calls a function that is also marked as being exported it does not necessarily call the function in its own library. Depending on order it may call the function that exists in the other library instead. Note that both modules are only manually loaded and neither are loading symbols from each other. It may (or may not) help as a workaround to build your modules with -Wl,-Bsymbolic, which tells the linker to bind all symbols locally within the shared object if possible at link time. This will (hopefully) cause the module to be built without an external reference to that symbol, so then there's nothing to go wrong at runtime. Note that this will change other linker behavior. Read the GNU ld documentation for more details on exactly what the option does. One recent discussion (pros and cons) about -Bsymbolic can be fount at http://rt.openssl.org/Ticket/Display.html?id=1595; . It seems to me that the OpenSSL project stay with -Bsymbolic but Debian create packages without :-/ Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: C++ Plugins and virtual destructors.
Ralf Wildenhues wrote: * Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET: Here's a relevant post from the GCC list; it mentions how to work around some dlopen difficulties (including RTTI, exceptions, custom new/delete). http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html Thanks for this link. FWIW, I could not easily see why RTLD_NOW should be needed. If it is, there's an opportunity to extent libltdl's advise API for this flag. Lest see samples from http://sourceware.org/ml/glibc-bugs/2005-08/msg00074.html If chain2.c dlopen with RTLD_LOCAL only the program crash in dlclose(segmentation fault). So that work around is to use either RTLD_NOW or RTLD_LAZY. [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: relinking makes libtool link to the wrong library
Simon Josefsson wrote:
Hi! We have received a bug report about some parts of recent gnutls
(libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
/usr/lib/ rather than in $prefix, see original report:
http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html
To understand how this works, GnuTLS contains one core library
libgnutls.so (in lib/) and another library libgnutls-extra.so (in
libextra/). The second library links to the former.
libextra/Makefile.am contains:
libgnutls_extra_la_LIBADD += ../lgl/liblgnu.la ../lib/libgnutls.la
The problem is easy to reproduce -- just build gnutls-2.2.0 locally on a
machine that has libgnutls.so.13 in /usr/lib -- but I don't know how to
solve it. I'm posting some details here and hope someone can help me.
Make install in lib/ works fine, the core library is installed properly.
Libtool does not relink the libgnutls.so library.
Make install in libextra/ causes relinking to happen. I think this is
expected, right? The output is:
make[2]: Entering directory `/home/jas/gnutls-2.2.0/libextra'
test -z /home/jas/gnutls-2.2.0/xxx/bin || /bin/mkdir -p
/home/jas/gnutls-2.2.0/xxx/bin
/usr/bin/install -c 'libgnutls-extra-config'
'/home/jas/gnutls-2.2.0/xxx/bin/libgnutls-extra-config'
test -z /home/jas/gnutls-2.2.0/xxx/bin || /bin/mkdir -p
/home/jas/gnutls-2.2.0/xxx/bin
test -z /home/jas/gnutls-2.2.0/xxx/lib || /bin/mkdir -p
/home/jas/gnutls-2.2.0/xxx/lib
/bin/sh ../libtool --mode=install /usr/bin/install -c 'libgnutls-extra.la'
'/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.la'
libtool: install: warning: relinking `libgnutls-extra.la'
(cd /home/jas/gnutls-2.2.0/libextra; /bin/sh ../libtool --tag=CC --mode=relink gcc -std=gnu99 -g -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -lopencdk -version-info 27:1:1 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /home/jas/gnutls-2.2.0/xxx/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la )
gcc -std=gnu99 -shared .libs/gnutls_extra.o .libs/gnutls_openpgp.o .libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a ../lgl/.libs/liblgnu.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/home/jas/gnutls-2.2.0/xxx/lib -L/usr/lib -lopencdk -llzo2 -L/usr/local/lib -lgcrypt -lgpg-error -L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls -Wl,--version-script=./libgnutls-extra.vers -Wl,-soname -Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1
/usr/bin/install -c .libs/libgnutls-extra.so.26.1.1T
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.so.26.1.1
(cd /home/jas/gnutls-2.2.0/xxx/lib { ln -s -f libgnutls-extra.so.26.1.1
libgnutls-extra.so.26 || { rm -f libgnutls-extra.so.26 ln -s
libgnutls-extra.so.26.1.1 libgnutls-extra.so.26; }; })
(cd /home/jas/gnutls-2.2.0/xxx/lib { ln -s -f libgnutls-extra.so.26.1.1
libgnutls-extra.so || { rm -f libgnutls-extra.so ln -s libgnutls-extra.so.26.1.1
libgnutls-extra.so; }; })
/usr/bin/install -c .libs/libgnutls-extra.lai
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.la
/usr/bin/install -c .libs/libgnutls-extra.a
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
chmod 644 /home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
ranlib /home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
PATH=$PATH:/sbin ldconfig -n /home/jas/gnutls-2.2.0/xxx/lib
--
Libraries have been installed in:
/home/jas/gnutls-2.2.0/xxx/lib
...
The libtool command is:
/bin/sh ../libtool --tag=CC --mode=relink gcc -std=gnu99 -g -O2 -D_REENTRANT
-D_THREAD_SAFE -pipe -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE
-Wno-pointer-sign -no-undefined -lopencdk -version-info 27:1:1 -llzo2
-Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath
/home/jas/gnutls-2.2.0/xxx/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo
openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la
That looks correct to me.
The gcc output is:
gcc -std=gnu99 -shared .libs/gnutls_extra.o .libs/gnutls_openpgp.o
.libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a
../lgl/.libs/liblgnu.a -Wl,--no-whole-archive -Wl,--rpath
-Wl,/home/jas/gnutls-2.2.0/xxx/lib -L/usr/lib -lopencdk -llzo2 -L/usr/local/lib
-lgcrypt -lgpg-error -L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls
-Wl,--version-script=./libgnutls-extra.vers -Wl,-soname
-Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1
This looks wrong to me, it contains:
-Wl,--rpath -Wl,/home/jas/gnutls-2.2.0/xxx/lib ... \
-L/usr/lib ... \
-L/usr/local/lib ... \
-L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls
So the final -lgnutls will pick it up from /usr/lib instead. I think
that the -L/usr/lib is bogus, that is the default library path anyway,
so it shouldn't be needed. But I don't think fixing that will take care
of this issue -- the command line also
Re: AIX: More troubles
Roumen Petrov wrote:
Daniel Sands wrote:
I have an executable that dlopens modules, and the modules make use of
symbols provided by the executable. Since AIX does not export symbols
unless either it has to (if needed for direct linkage to a shared
object) or you REALLY want it to (either by -bexpall or by providing
an exports list), these symbols don't resolve. So it either crashes
(if compiled without -brtl) or complains about unresolved references.
Is there a Libtool-standard way to make the executable export all of
its symbols?
The standard is to add libtool flag -export-dynamic to executable
LDFLAGS but may be libtool is not ported to you linker.
For GNU linker:
./libtool --config | grep export_dynamic
export_dynamic_flag_spec=\${wl}--export-dynamic
Roumen
Since Daniel's e-mail address return mails - reason: User unknown
so I quote response.
You're right: On AIX this flag is blank. I'm also scratching my head
because I'm sure I got a successful run without -brtl once the symbols
were exported. But today that is not the case: Both the library and
the executable must be built with -brtl if the library references
symbols within the executable. So those flags should also be added to
the AIX platform. Basically, -bexpall (or do the nm exports trick)
on executables, and -brtl on everything.
I could not help him to resolve issue (I don't have access to AIX, nor
experience ).
Daniel please find attached file bootstrap.sh.gz with sample code and
build based on autotools. The sample is strip down of C++ version.
Please could you adapt to you host environment and post result to list
so that people with experience on AIX to help you.
Also it is wort to try libtool version 1.2.26 where AIX support is
improved or may be to check 2.1b since it will be rool up soon.
Roumen
bootstrap.sh.gz
Description: application/gzip
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool windows dll suffix revision
Alon Bar-Lev wrote: On 3/15/08, Peter Rosin [EMAIL PROTECTED] wrote: With your suggestion of always using age, you would get dll-7.dll and dll-8.dll for your examples, but you would also get dll-7.dll for my example, and then you would have the same file name for two incompatible dlls, which is a lot worse than having the same file name for two compatible dlls. Please explain further, if I have made any false assumptions. Thank you for your response!!! I reread the libtool versioning system, and it looks like I got it wrong. It looks like you already doing what I request, but I did not put the numbers right. current = newest age = current - oldest dll_suffix = current - age = oldest I am truly sorry... I did not understand that I have to calculate the age delta my-self when producing libtool version, and age is not the oldest. Thank you, Alon. I think then version support is useless for mingw builds. Project that use native makefiles don't support version. May be -release is better for you needs. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MinGW linux to win32 cross compiler and the test suite
Erik de Castro Lopo wrote:
Hi all,
I have the beginnings of a solution to this issue.
If I hack the libtool generated wrapper script and replace this:
exec $progdir/$program ${1+$@}
with
WINEDLLPATH=$PATH;$WINEDLLPATH
exec wine $progdir/$program ${1+$@}
My test suite works. Ie, I cross compile from Linux to win32 and
the test suite gets run under wine. Personally, I find this an
huge improvement over developing on windows.
I now have a follow up question. Would it be possible/desirable to
have autoconf/automake/libtool do the following:
1) Detect if cross-compiling from x86 linux to win32.
2) If 1) is true, detect precence of wine.
3) If 2) is true and wine is present, write a wine specific
version of the output wrapper scripts.
Cheers,
Erik
Just setup binfmt-support.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote:
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote:
-rpath is required for proper execution in many environments, the
ability to change the soname is, as far as I can tell, not.
Please present a more convincing argument.
Hello Peter,
I think that infrastructures such as libtool should allow customization
of any attribute that affect the output. Of course there should be defaults
but it should allow overriding to allow customization. This especially true
when the customization is simple to implement and to maintain.
Your example of not using automake simplified rules in order to
workaround the lack of ability to customize the soname attribute
is correct. But it is a workaround that makes build system much
more complex, just because customization is missing.
What you recommend is instead the following automake rules:
lib_LTLIBRARIES=module1.la
module1_la_SOURCES=m1.c m2.c m3.c m4.c
module1_la_LDFLAGS=-module -avoid-version -soname @MYNAME@
install-exec-local: install-libLTLIBRARIES
mv -f $(DESTDIR)$(libdir)/module1.so $(DESTDIR)$(libdir)/@MYNAME@
Write the following make rules:
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
my_objects=m1.lo m2.lo m3.lo m4.lo
@MYNAME@: $(my_objects)
$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
-module -avoid-version $(LDFLAGS) -o $@ \
-rpath $(libdir) $(my_objects) $(LIBS)
lib_LTLIBRARIES=#create
install-exec-hook: install-libLTLIBRARIES @MYNAME@
$(LIBTOOL) --mode=install $(INSTALL) @MYNAME@ \
$(DESTDIR)$(libdir)
all-local: @MYNAME@
.c.lo:
if am__fastdepCC
$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $
mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
else
if AMDEP
source='$' object='$@' libtool=yes @AMDEPBACKSLASH@
DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
endif
$(LTCOMPILE) -c -o $@ $
endif
But you request is not what I expect from soname:
$echo void foo(void) {} module.c
$ gcc -shared -o module.so -Wl,-soname=test.so module.c
$ objdump -x module.so | grep SONAME
SONAME test.so
$ /sbin/ldconfig -v -l module.so
test.so - module.so
You request is to change library name. So I could not understand what is
related to SONAME. It came as a surprise to me to allow user(verdor) to
change library name at configure time.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote: On 3/28/08, Roumen Petrov [EMAIL PROTECTED] wrote: You request is to change library name. So I could not understand what is related to SONAME. It came as a surprise to me to allow user(verdor) to change library name at configure time. It for generating a differnet module using automake. At the end SONAME matches the module name. So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote: On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote: So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Thanks! It works. Although I am sure I tried this in several notations, and in all I got automake error that this must not be none constant. Strange... I still think that libtool should enable soname to be customized :) May be is good libtool to preserve some variables from CONFIG_SITE file (libname_spec, soname_spec, etc ??? ) . In was my case http://lists.gnu.org/archive/html/libtool/2007-07/msg00044.html . It is similar to you case since I would like to be able to define name of library file on a particular platform(host), but I don't like to change library internal name (soname). Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool(2.2.4) detect native java compiler in cross-compilation environment
Hello libtool Team, In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure output I see : checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! checking if gcj supports -fno-rtti -fno-exceptions... (cached) no checking for gcj option to produce PIC... checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking if gcj supports -c -o file.o... (cached) yes checking whether the gcj linker (/opt/mingw/i386-mingw32msvc/bin/ld) . Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? The check for Fortran compiler look similar but I don't have installed native Fortran-compiler so libtool configure don't detect any. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
Bob Friesenhahn wrote: On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like it did not detect a prefix for the program in the above example, so, as a last-ditch effort, it tried without a prefix. If it picks up the wrong tools, does libtool's configure end up using them or does it eventually reject them? Dunno. May be it try to use. As example file builddirtests/testsuite.dir/35/run contain (after make check-local) contain: = ... CPP='i386-mingw32msvc-gcc -E' ... STRIP='i386-mingw32msvc-strip' ... GCJ='gcj' GCJFLAGS='-g -O2' ... = Also in the file srcdir/tests/convenience.at I found: = 262: # There are just too many broken gcj installations out there, either missing 263: # libgcj.spec or unable to find it. Skip this test for them. 264: if test $i -eq 1; then 265:AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) 266:AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) 267:AT_CHECK([./foo1$EXEEXT || exit 77],[],[ignore],[ignore]) = and the command make check-local report: 23: Java convenience archives skipped (convenience.at:267) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
Ralf Wildenhues wrote: Hello Roumen, * Roumen Petrov wrote on Fri, May 09, 2008 at 09:39:11PM CEST: In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure output I see : checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! checking if gcj supports -fno-rtti -fno-exceptions... (cached) no checking for gcj option to produce PIC... checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking if gcj supports -c -o file.o... (cached) yes checking whether the gcj linker (/opt/mingw/i386-mingw32msvc/bin/ld) . Is above detection correct ? Well, yes and no. It's not nice and clean, but a compromise out of more or less necessity. For example, not always are cross compilers prefixed correctly. This happens with non-GNU cross compile setups, but can also happen with, for example, compiling for MSYS under Cygwin. Users complain if this is turned off. Thanks. Now I understand why macros don't use first prefix found. May be there is no solution to test that a specific compiler is cross-compiler. The workaround for you is to ./configure GCJ=no The check for Fortran compiler look similar but I don't have installed native Fortran-compiler so libtool configure don't detect any. Same thing (FC=no F77=no) if you have a Fortran compiler installed. Sorry. Ralf Workarounds can be found after internet search. If they are stable(standard) may be few words into source files, like - INSTALL, README, info pages or etc, could help more. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Separate CPPFLAGS for static and shared libs
Vincent Torri wrote: On Wed, 4 Jun 2008, Ralf Wildenhues wrote: * Vikram Ambrose wrote on Wed, Jun 04, 2008 at 03:54:35PM CEST: However I need to pass separate CPPFLAGS to the objects destined for the shared library as opposed to the objects destined for the library archive. As Andreas already replied, just use #ifdef PIC for shared and #ifndef PIC for static code. That usually works. I think that it will not work with MinGW. But then you can use DLL_EXPORT. Vincent Torri -DPIC is defined in conjunction with -DDLL_EXPORT Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Alon Bar-Lev wrote: Hello, I looked at recent libtool-2 versions and could still not find a solution to compile into chroot. I want to create an image to embedded device using a cross compiler. So I do: mkdir /tmp/device-root cd /package1 ./configure --host= --prefix=/usr make install DESTDIR=/tmp/device-root cd /package2 ./configure --host= --prefix=/usr make install DESTDIR=/tmp/device-root But package2 cannot find libraries as the .la files constains pathes to /usr/lib and not /tmp/device-root/usr/lib. Is there any way to make libtool search the /tmp/device-root prefix, and behave correctly? I am thinking like an environment variable so that packages will not be effected. Thanks, Alon Bar-Lev. Hmm. What is related to chroot ? Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Bob Friesenhahn wrote: On Thu, 12 Jun 2008, Alon Bar-Lev wrote: After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Why not just add a /tmp/device-root symbolic link to '/' in your chrooted space? Then everything will be happy. The alternative is to use a script to update all of the installed .la files to use the new paths. This is not libtool's problem. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ It look like an enhancement request. libtool to obey as example FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Bernd Jendrissek wrote: On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev [EMAIL PROTECTED] wrote: Building packages into chroot is more and more common, live-cd, live-usb, initramfs, embedded, vservers etc... A lot of packages use libtool, so using the standard gnu build for chroot environment, in order to build packages without change in the package is important. ./configure --prefix=/ make install DESTDIR=/tmp/myroot As far as I know libtool is the only tool that needs fixups or workaround. I've never gotten around to actually doing this, but I wonder if inverting the standard-ness of paths could help. You could set up a chroot environment that you use for building, where you have your *build* tools (compiler, linker, etc.) as /unexpected/location/bin/gcc etc., and install directly (without DESTDIR) into the root directory which has the sticky flag (like /tmp). It would mean that you never test proper DESTDIR support though. I don't think that compiling into chroot is the right subject. As I understand host system is accessible in build system under a prefix path_to_host_system. I don't think that only libtool is affected. During configure time autoconf macros has to detect presence of headers, functions, libraries in host system. At make time libtool has to compile and link against files in host system. What about a new configure flag --host-prefix. ./configure --prefix=/usr ... --host=... --host-prefix=/path_to_host_system In this case compiler has to prefix all include path by /path_to_host_system. Also note cross-compiler search path. The linked has to search in directories prefixed by same path, but rpath in shared libraries has to omit this prefix. Also note default library search-path (gnu linux - /path_to_host_system/etc/ld.so.conf). Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MinGW DLLs and autoconf parsing
Jason Curl wrote: Hello, Recently some info was posted about using resource files with Windows compilers. I'm trying to generate a reasonably simple Version resource and there's some information I'm not sure how I can extract from the build process. I'm using libtool-1.5.27a on MSYS-1.0.10 with MinGW-5.1.4. Question 1: One of the fields is OriginalFilename. When the shared DLL is built, it is installed libfoo-1.dll. I've created a rsrc.rc.in file that autoconf generates for me, substituting information from the build process directly into this resource file. However, how might I get the name of the library before it is built? You may create library with name libfoo.dll if you call make with LDFLAGS=--avoid-version. Also you may set this flag in configure script for mingw host. libtool don't preserve LIBRARY statement specified by def-file. The string -1 is suffix appended by libtool for cygwin/mingw host. The number is equal to $current - $age from version info. Question 2: The second task is the versioning. There are two fields, both of the format: FILEVERSION major,minor,revision,build I need to substitute them based on the version information given to libtool during the linking phase. WINSERLOG_VERSION_INFO=1:0:0 AC_SUBST(WINSERLOG_VERSION_INFO) How can I convert the string 1:0:0 to a major.minor.revision field? How does this work? awk, sed , shell ? - born shell sample: IFS=:; set -- `echo a:b:c`; echo $1.$2.$3 Question 3: As the libtool --tag=RC doesn't work for 1.5.27a (it complained about an unknown tag), I wrote the rule: I guess that configure script is without macro AC_LIBTOOL_RC .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(RC) $(RCFLAGS) $ -o $@ where RC=windres and RCFLAGS is empty. It works, but is it safe? I don't know when MinGW will upgrade the autotools. May be you need two rules : one to create %.lo file and one for object file (%.o): --- RCFLAGS = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) RCCOMPILE = $(RC) $(RCFLAGS) LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE) .rc.lo: $(LTRCCOMPILE) -i $ -o $@ .rc.o: $(RCCOMPILE) -i $ -o $@ --- Thanks Best Regards, Jason. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. [...] I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? Please provide more information, like exactly how you invoked configure, post the command that was used that produced the above output, and all its output, not just the warnings. configure call: ./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. Libtool try to convert path from build system to the path from host system. In file included from ./.libs/lt-suite.c:40: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25: error: no include path in which to search for errno.h ./.libs/lt-suite.c: In function 'find_executable': ./.libs/lt-suite.c:617: warning: initialization makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_exe_path': ./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_lib_path': ./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast arm-mingw32ce-strip: './suite.exe': No such file About the errno problem, I've sent a mail about that. There is also a problem with Windows CE: there is no environment variables in that OS, hence no getenv / setenv functions. If exist emulator for this host os libtool may generate binary wrapper. If I remember well the libtool contain cases for *mingw* (or *mingw32*) and may be this is problem - mingw32ce isn't for this category. Vincent Torri Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
[...]
I've never seen those message. Again, I would like to know what is
happening.
No idea where I should look in ltmain.sh to fix those messages ?
Please provide more information, like exactly how you invoked
configure,
post the command that was used that produced the above output, and all
its output, not just the warnings.
configure call:
./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g
-O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
memcpy_glibc_arm.o ../../src/lib/libevil.la
libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o
.libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o
-L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib
../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
Libtool try to convert path from build system to the path from host
system.
So, where and how can I correct that in ltmain.sh
In file included from ./.libs/lt-suite.c:40:
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25:
error: no include path in which to search for errno.h
./.libs/lt-suite.c: In function 'find_executable':
./.libs/lt-suite.c:617: warning: initialization makes pointer from
integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend':
./.libs/lt-suite.c:873: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_append':
./.libs/lt-suite.c:894: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_exe_path':
./.libs/lt-suite.c:910: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_lib_path':
./.libs/lt-suite.c:931: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
arm-mingw32ce-strip: './suite.exe': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: there is no environment
variables in that OS, hence no getenv / setenv functions.
If exist emulator for this host os libtool may generate binary wrapper.
If I remember well the libtool contain cases for *mingw* (or
*mingw32*) and may be this is problem - mingw32ce isn't for this
category.
maybe. I don'tt know much about how ltmain.sh works.
Nevertheless, I have a question about all that stuff:
for me, libtool is about libraries (libtool == library tool ?). Anyway,
the doc is saying that libtool is for making life easier when dealing
with libraries. So why is libtool so much involved when dealing with
binaries (it is my case here) ??
The libtool create wrapper script to allow user to run tests programs.
The wrapper script set environment so that test programs to use project
libraries , not system one. For the w32 platform since libtool version
2.{2|4}(?) the wrapper script is replaces by binary executable.
The host triplet *-*-mingw* is used in scripts to detect mingw build
for win32 platform. I mean mingw32msvc as host_os
Re: [PATCH] Don't install .la files when --no-la-files is used
Dan Nicholson wrote: On Mon, Nov 3, 2008 at 2:05 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote: [SNIP] Oh, well. You do know that all the linux distros (that I know of) remove the .la files, right? NO I was sort of hoping there would be a nice way to do that. Check content of so called dev-packages. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Hi Russ, Russ Allbery wrote: Ralf Wildenhues [EMAIL PROTECTED] writes: Hello Russ, * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles package dependencies and makes upgrades unnecessarily hard. (This is the long-standing problem of including all dependencies required for static libraries, which aren't needed for shared libraries on systems that handle transitive dependency closures when loading shared libraries.) Which is nicely solved with --as-needed, as long as you don't need to stick in extra, seemingly-unneeded library dependencies that only become useful for dlopen'ed modules. Debian's experience to date is that --as-needed is buggy and breaks a lot of software, and overall is not a particularly stable solution. Removing *.la files so that the unneeded shared libraries aren't linked in the first place works considerably better at the moment. Could you point by example how libtool add pile of unnecessary dependencies ? Whit this example could you confirm that libtool add more(extra) libraries then specified by project authors ? [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Russ Allbery wrote: Roumen Petrov [EMAIL PROTECTED] writes: Russ Allbery wrote: Debian's experience to date is that --as-needed is buggy and breaks a lot of software, and overall is not a particularly stable solution. Removing *.la files so that the unneeded shared libraries aren't linked in the first place works considerably better at the moment. Could you point by example how libtool add pile of unnecessary dependencies ? Whit this example could you confirm that libtool add more(extra) libraries then specified by project authors ? When you create a libtool library, libtool records every library against which that library was linked into the *.la file. If you then link another shared library against that shared library using libtool, libtool reads that list of libraries from the *.la file and links the new library against them as well. But problem is not in the libtool. This is not necessary. For distribution packages, it's actually harmful. This depend from platform. To see why, consider some library libfoo which uses readline. Suppose that libreadline is linked and installed with libtool, so it has a *.la file saying that it depends on libncurses. When you link libfoo against libreadline using libtool, libtool will also link it against libncurses, so it now acquires a dependency on libncurses as well. This is one of the good samples. Libtool don't add dependency if is not specified by project makefiles, i.e. LDFLAGS/LDADD. Readline has to be build without dependent libraries to allow application to link with readline but with different compatible libraries: ncursesw, ncurses, curses, termcap, etc. But if readline project make rule specify that library has to linked with a particular curses library, libtool has to use this rule, when link an application with readline. So I think that projects are responsible how to list library dependencies. Also this mail thread show that --as-needed flag is not universal solution for platforms that allow shared libraries with unresolved externals. I quick internet search show problems with ld from binutils series 2.17 and some version of 2.17.x. Another --as-needed problem is that some projects use xxx_LDFLAGS to add libraries to applications instead xxx_LDADD in Makefile.am. Other projects use LDFLAGS instead LIBS in configure scripts. This is most common problem for package build rules and I could not understand why libtool is responsible to fix incorrect project build rules. Also removing la-files won't help. Another tool that list all package libs is pkg-tool. It is so common projects to append all libraries returned from pkg-tool :) . And of course the whole list go in la-files. Libtool is for multi-platform use and list with complete dependent libraries help me to build binaries on platform that don't support unresolved symbols, as example windows. On this platform libtool don't create shared library if flags -no-undefined is not specified. Many projects don't set this libtool flags and patches for their build system stay open couple of years. In this case command 'make LDFLAGS=-no-undefined ...' help a lot to build without to touch project files. I guess that a new flag that order libtool do not link a shared library with dependent libraries is more useful then removing la-files. This flag may overcome --as-needed problems. In this case is vendor decision how to build a library [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
[SNIP] But problem is not in the libtool. Yes it is. If you're linking to libfoo, libtool reads libfoo.la and adds direct links to everything in dependency_libs. Let's say libfoo depends on libbar and libbaz. You're application ends up directly linking to libfoo, libbar and libbaz instead of just libfoo. No. If project when build a library don't add dependent libraries to xxx_LIBADD libtool left dependency_libs empty in la-file. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Russ Allbery wrote: Roumen Petrov [EMAIL PROTECTED] writes: Russ Allbery wrote: When you create a libtool library, libtool records every library against which that library was linked into the *.la file. If you then link another shared library against that shared library using libtool, libtool reads that list of libraries from the *.la file and links the new library against them as well. But problem is not in the libtool. Yes. It is. This is not necessary. For distribution packages, it's actually harmful. This depend from platform. Yes. I said that. But it's harmful for the platforms that are in most common use (anything that uses ELF, for example). To see why, consider some library libfoo which uses readline. Suppose that libreadline is linked and installed with libtool, so it has a *.la file saying that it depends on libncurses. When you link libfoo against libreadline using libtool, libtool will also link it against libncurses, so it now acquires a dependency on libncurses as well. This is one of the good samples. Libtool don't add dependency if is not specified by project makefiles, i.e. LDFLAGS/LDADD. But if readline project make rule specify that library has to linked with a particular curses library, libtool has to use this rule, when link an application with readline. Only on non-ELF platforms. It was old build bug when building readline library on some linux-es. In my memory is suse 7.1 but I'm sure that only this particular version was affected. Many other linux verdors build readline without dependent libraries and this allow application to be linked against different curses compatible libraries. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Dan Nicholson wrote: On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov [EMAIL PROTECTED] wrote: [SNIP] But problem is not in the libtool. Yes it is. If you're linking to libfoo, libtool reads libfoo.la and adds direct links to everything in dependency_libs. Let's say libfoo depends on libbar and libbaz. You're application ends up directly linking to libfoo, libbar and libbaz instead of just libfoo. No. If project when build a library don't add dependent libraries to xxx_LIBADD libtool left dependency_libs empty in la-file. Um, but what if the libraries actually needs to link to other libraries? Just emptying LIBADD means you're building a broken library. building a broken library please explain. I just answer to another mail in this mail thread. You state that all linux vendor build broken readline library ! Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
It was old build bug when building readline library on some linux-es. In
my memory is suse 7.1 but I'm sure that only this particular version was
affected.
Many other linux verdors build readline without dependent libraries and
this allow application to be linked against different curses compatible
libraries.
libreadline is linked against libncurses on Debian.
Which version ?
This is an 7(5?) years old linux bug.
But surely it's obvious that this isn't an interesting argument and has
nothing to do with my point? It may be that my specific example doesn't
apply on the system that you're looking at right now, but I'm sure that
you can find dozens or hundreds of others without even trying. Any shared
library that is linked with other shared libraries and is built with
libtool can present this problem.
[SNIP]
The sample is attached.
save attached files:
- pkg1_bootstrap.sh as pkg1/bootstrap.sh
- pkg2_bootstrap.sh as pkg2/bootstrap.sh
- app_bootstrap.sh as app/bootstrap.sh
Adjust prefixes to libtool, automake, autoconf paths..
Details:
- library foo1 for pkg1 export function foo1
- library foo2 for pkg2 export function foo2 and use function foo1
- application use functions foo1 and foo2 and and to link with libraries
that export them.
Where is libtool bug ?
Roumen
#! /bin/sh
set -e
testPREFIX=/tmp/test/lt/pkg-deplibs-minlibs
libtoolPREFIX=/usr/local/libtool/1.5.26
#libtoolPREFIX=/usr/local/libtool/2.2.2
automakePREFIX=/usr/local/automake/1.10.1
autoconfPREFIX=/usr/local/autoconf/2.61
PATH=${libtoolPREFIX}/bin:$PATH
PATH=${automakePREFIX}/bin:$PATH
PATH=${autoconfPREFIX}/bin:$PATH
export PATH
cat foo.c EOF
#include stdio.h
extern void foo1(long n) {
fprintf(stderr, foo1(%ld)\n, n);
}
EOF
cat Makefile.am EOF
lib_LTLIBRARIES = libfoo1.la
libfoo1_la_SOURCES = foo.c
libfoo1_la_LDFLAGS = -avoid-version
EOF
test -d build-aux || mkdir build-aux
cat configure.ac EOF
AC_INIT([test1], [0.0])
AC_PREREQ(2.50)
AC_CONFIG_AUX_DIR(build-aux)
AC_CANONICAL_HOST
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_LIBTOOL
AC_OUTPUT([Makefile])
EOF
libtoolize --force --copy --automake
aclocal -I ${libtoolPREFIX}/share/aclocal
automake --foreign --add-missing --copy
autoconf
( set -e
D=build-linux
test -d $D || mkdir $D
cd $D
../configure --prefix=${testPREFIX}
make
make install
)
#! /bin/sh
set -e
testPREFIX=/tmp/test/lt/pkg-deplibs-minlibs
libtoolPREFIX=/usr/local/libtool/1.5.26
#libtoolPREFIX=/usr/local/libtool/2.2.2
automakePREFIX=/usr/local/automake/1.10.1
autoconfPREFIX=/usr/local/autoconf/2.61
PATH=${libtoolPREFIX}/bin:$PATH
PATH=${automakePREFIX}/bin:$PATH
PATH=${autoconfPREFIX}/bin:$PATH
export PATH
cat foo.c EOF
#include stdio.h
extern void foo1(long n);
extern void foo2(long n) {
foo1(n);
fprintf(stderr, foo2(%ld)\n, n);
}
EOF
cat Makefile.am EOF
lib_LTLIBRARIES = libfoo2.la
libfoo2_la_SOURCES = foo.c
libfoo2_la_LDFLAGS = -avoid-version
#libfoo2_la_LIBADD = -L${testPREFIX}/lib -lfoo1
EOF
test -d build-aux || mkdir build-aux
cat configure.ac EOF
AC_INIT([test2], [0.0])
AC_PREREQ(2.50)
AC_CONFIG_AUX_DIR(build-aux)
AC_CANONICAL_HOST
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_LIBTOOL
AC_OUTPUT([Makefile])
EOF
libtoolize --force --copy --automake
aclocal -I ${libtoolPREFIX}/share/aclocal
automake --foreign --add-missing --copy
autoconf
( set -e
D=build-linux
test -d $D || mkdir $D
cd $D
../configure --prefix=${testPREFIX}
make
make install
)
#! /bin/sh
set -e
testPREFIX=/tmp/test/lt/pkg-deplibs-minlibs
libtoolPREFIX=/usr/local/libtool/1.5.26
#libtoolPREFIX=/usr/local/libtool/2.2.2
automakePREFIX=/usr/local/automake/1.10.1
autoconfPREFIX=/usr/local/autoconf/2.61
PATH=${libtoolPREFIX}/bin:$PATH
PATH=${automakePREFIX}/bin:$PATH
PATH=${autoconfPREFIX}/bin:$PATH
export PATH
test -d build-aux || mkdir build-aux
cat foo.c EOF
#include stdio.h
extern void foo1(long n);
extern void foo2(long n);
int main() {
foo1(11);
foo2(22);
fprintf(stderr, main()\n);
return(0);
}
EOF
cat Makefile.am EOF
bin_PROGRAMS = foo
foo_SOURCES = foo.c
foo_LDADD = -L${testPREFIX}/lib -lfoo2 -lfoo1
EOF
cat configure.ac EOF
AC_INIT([test], [0.0])
AC_PREREQ(2.50)
AC_CONFIG_AUX_DIR(build-aux)
AC_CANONICAL_HOST
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_LIBTOOL
AC_OUTPUT([Makefile])
EOF
libtoolize --force --copy --automake
aclocal -I ${libtoolPREFIX}/share/aclocal
automake --foreign --add-missing --copy
autoconf
( set -e
D=build-linux
test -d $D || mkdir $D
cd $D
../configure --prefix=${testPREFIX}
make
)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
libreadline is linked against libncurses on Debian.
Which version ?
readline 5.2-3, ncurses 5.7-2.
No,no debian version/release.
This is an 7(5?) years old linux bug.
I'm very dubious of that assertion. Applications which use readline but
do not directly use any curses functions should not need to link with any
curses library.
Linking readline against ncurses prevent application to link against
readline against ncursesw and to offer wide characters support.
Details:
- library foo1 for pkg1 export function foo1
- library foo2 for pkg2 export function foo2 and use function foo1
- application use functions foo1 and foo2 and and to link with libraries
that export them.
Where is libtool bug ?
Your example as described above has nothing to do with the case that we're
talking about since it contains no implicit dependencies. I'm afraid I
can only conclude that I've not been sufficiently clear and you're not
following my point at all. I've explained this as clearly as I can,
though. Maybe someone else can do a better job.
But is a package author uncomment line:
#libfoo2_la_LIBADD = -L${testPREFIX}/lib -lfoo1
from pkg2/bootstrap.sh you will see dependency added in la-file.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: func_emit_cwrapperexe_src() errors with mingw32ce
Vincent Torri wrote: Hey, Natively, the Windows CE OS has no concept of environment variable. Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because of missing getenv() and putenv() (or setenv() also, of course). I don't know what to do here (removing or not thee calls, as I don't know why they are used. There are also 2 other functions that are missing with that compiler: * getcwd() May be a port function that return always \Temp is work around? it's possible to get the path where the current process is launched. Again, i don't know if it's simpler to remove that call or if one should provide a way to have the path where the process is launched. * _spawnv() A code based on CreateProcess ? i don't know any simple way to fake that function. Maybe one should add another test in the 'host' case for that specific compiler which wo do nothing (in that case, one can remove the #ifndef in the case the host is mingw*) Vincent Torri If wince lack working emulator may libtool omit creation of wrapper ? Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: Hey, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' [SNIP] Note that I also have those warnings when I cross-compile on linux using the host i586-mingw32msvc. So it's not specific to the arm-mingw32ce host Vincent Torri You environment lack emulator, or winepath isn't in PATH. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: On Sat, 6 Dec 2008, Roumen Petrov wrote: You environment lack emulator, or winepath isn't in PATH. WHY do I need an emulator ? I need it to run the project tests including libtool tests. I don't care about that. I just want my executables being installed (copied) in the prefix/bin directory I passed when I exec 'make install'. That's all. WHY does libtool does not want to do so ? Is there a way to forbid libtool executing that wrapper ? like -do-not-exec-the-stupid-wrapper It is just a warning. Is there a real issue ? Vincent Torri Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting filenames for libraries
Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: [SNIP] I've attached a sample of the macros if there are comments. e.g. configure.ac (only the interesting bits) [SNIP] LX_PROG_RC use AC_LIBTOOL_RC AC_CONFIG_FILES([src/rsrc.rc]) Makefile.am [SNIP] .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(RC) $(RCFLAGS) $ -o $@ after AC_LIBTOOL_RC in configure you may use .. --tag=RC $(RC) .. [SNIP] windows) major=`expr $current - $age` versuffix=-$major ;; In case of make LDFLAGS=-avoid-version versuffix has to be ! [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool.git cl.exe Mingw32
Akim Demaille wrote: Hi friends, It's cold, the win32ter's back, and I'm a lonely winderer in the winderful country to losedows. As you suggested, I'm moved from pw32 to ming32, and as a result, I now have a wrapper.exe instead of a shell script wrapper. This is wonderful news, since I was wasting a lot of time in useless recompilations, because libtool -o foo.exe used to create foo, which cause the Makefiles to never be satisfied and relaunching endless recompilations. Yet I have a slight problem: for some reason the top-level wrapper (lt-cli.exe in my case) tries to launch .libs/lt-cli.exe, which does not exist. What does exist is .libs/cli.exe (and actually it makes more sense to me). So I had to change libtool: [SNIP] What about libtool version ? Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: uninstalled modules do not build .so files
Andy Wingo wrote: Hi, So, this is a resend, as for some reason the silliest of autotools projects creates 300 kB tarballs. Attaching the files individually: unpack in a directory of their own please. *** Unpack the attached tarball (it will create its own directory). It is a standard autotooled project with one file, foo.c. Expected results: ./autogen.sh make produces a .so file in .libs. Actual results: No .so file is produced. AC_ENABLE_SHARED ? Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making .lib import libraries with libtool
LRN wrote: I have a project that uses autoconf/automake/libtool, and it produces shared libraries (on Windows that would be .dll) and static libraries (.a). Which modifications are necessary for it to start outputing .lib libraries (the ones that could be linked with link.exe) along with .dll's? I can hack configure script and add calls to lib.exe, but that doesn't seem right, and i would rather try doing that in configure.ac. You didn't specify compiler. If it is GCC(mingwXX target) compiler produce import libraries with suffix .dll.a. In most cases just changing suffix work. Exception is both direction (.lib-.dll.a) is for exported variables. In general even MSVC didn't produce compatible import libraries. Library created by compiler version X may not work for version Y. I'm not informed that this issue is resolved. Def-files are more portable and some projects prefer this way. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. Some of those libraries are always linked as example mingwex. Also you may pass flags to the linker: -Wl... Libtool pass it to the linker, i.e. you may pass def-file or library (-lXXX) . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive import or x86 DLL, but not x86 archive static.
Some of those libraries are always linked as example mingwex.
Which libraries are this exactly (for various MinGW versions), and are
any of these import libs?
quote for gcc spec file:
==
*lib:
%{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32
-ladvapi32 -lshell32
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
==
- mingwthrd: import, specific
- mingw32: static
- moldname: import (for functions without underscore)
- mingwex: static
- msvcrt+other xx*32: import (runtime)
mingwex is a specific extension. As example library add float and long
double functions missing in msvcrt. Version 3.15 (3.14 ?) add posix
compatible IO.
For the non-import default-linked ones, we should probably add
exceptions to libtool to accept them, but I'm not sure whether
that is the right thing here.
Thanks,
Ralf
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Ralf Wildenhues wrote:
Hello Vincent, Bob,
[SNIP]
But anyway, I don't see how the current git code generates C wrappers
for wince.
The host is usually xxx-mingw32ce and will match patterns like
{*-}*-mingw*, i.e. it will generate wrappers as for mingw32.
But the C-wrapper-code of current (my repository close is about one
month old) libtool don't include error.h :
.
#ifndef __MINGW32CE__
# include errno.h
#endif
.
[SNIP]
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: d3dx9.lib is not managed by ld, but libd3dx9.a is
Vincent Torri wrote: Hey, I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass -ld3dx9 and i have added everything so that the dll is built. If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual warning message from linker / libtool: *** Warning: linker path does not have real file for library -ld3dx9. blah blah blah and only the static lib is built. If I rename d3dx9.lib to libd3dx9.a, then the DLL is built. I don't understand why because, according to the doc of ld for win32: http://sourceware.org/binutils/docs/ld/WIN32.html if I pass -ld3dx9, then d3dx9.lib should be used. What is the reason of the failure ? thank you Vincent Torri I'm not sure that libtool has to deal with library '.lib' suffix. From the suffix is not clear type of library file - static or import library. GNU compiler(mingw) use suffix '.a' for static library and '.dll.a' for import libraries. If a xx.lib file is found in search path libtool has to process file and to find its type(static/import). This impact performance. Also support for MSVC import libraries isn't perfect and linker will fail to link if a library export variables. Note in this case GNU linker succeed to link directly shared(DLL) library. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Multipurpose binaries with different names
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jan Engelhardt on 7/24/2009 3:25 AM: Hi, when one has a program that does something like if(strcmp(argv[0], gunzip) == 0) uncompress(); else compress(); GNU Coding Standards frown on this practice: http://www.gnu.org/software/automake/manual/standards.html#User-Interfaces The Multipurpose binaries are born before GNU Coding Standards. So I think that libtool has to support them for historical reasons. Regards Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues wrote: * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET: Ralf Wildenhues wrote on 10/12/2009 06:16:40: * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET: Ralf Wildenhues wrote on 08/12/2009 20:13:13: ./configure --prefix=/opt/x/y make make install DESTDIR=/some/dir I getting back to this now that my libtool problem seem to be over. Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at configure time so one does have to remember/type DESTDIR=.. at every make No, but you can just `export DESTDIR' in your environment. Yeah, but that isn't going to work in here, too easy to get wrong. I image I could add something to configure.ac that will allow me to set it at configure time? Not sure what would work though, any ideas? Well you can AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR]) This require makefiles generated by configure script to contain line like this one: destd...@destdir@ otherwise it is useless I won't like to discuss more what happen if user forget DESTDIR as it is not required at every make. DESTDIR is usefull only if user would like to create distribution archive and for every package DESTDIR is good to point to clean directory tree. Other point is that on unix(linux) user work under unprivileged account and only for install is required a privileged account(root). but it will require your users to either specify it at configure time already, or, if they want to specify it at `make install' time only, use GNU make. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool mail lists
Hi libtool webadmin, This page http://www.gnu.org/software/libtool/ currently refer to site http://mail.gnu.org/;... for libtool related mail lists . It seems to that correct site is http://lists.gnu.org/...;. Also not all links point to final location as example http://lists.gnu.org/pipermail/libtool-patches/; (note s/mail/lists/ ) it moved permanently to href=http://lists.gnu.org/archive/html/libtool-patches;. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool mail lists
Hi Ralf, Ralf Wildenhues wrote: Hi Roumen, * Roumen Petrov wrote on Sat, Jan 09, 2010 at 04:33:00PM CET: This page http://www.gnu.org/software/libtool/ currently refer to site http://mail.gnu.org/;... for libtool related mail lists . It seems to that correct site is http://lists.gnu.org/...;. Also not all links point to final location as example http://lists.gnu.org/pipermail/libtool-patches/; (note s/mail/lists/ ) it moved permanently to href=http://lists.gnu.org/archive/html/libtool-patches;. These should be fixed now. Thanks for reporting them! Cheers, Ralf As example you could test missing /moved with wget $ wget http://www.gnu.org/software/libtool/ -O libtool-index.html $ wget --spider --force-html --verbose=off --debug=off --base=http://www.gnu.org/software/libtool/ -i libtool-index.html After fixes for libtool lists the result is : https://my.fsf.org/associate/support_freedom?referrer=4052: Remote file does not exist -- broken link!!! May be it is https://my.fsf.org/associate/support_freedom/join_fsf?; or https://my.fsf.org/associate/support_freedom/; ? Also with verbose and/or debug set you could find some references with 301 Moved Permanently response first (Note not so important). As example for .../XXX (.../manual and .../libtool-commit) server respond moved to .../XXX/. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool did not search ws2_32.dll
Kuang-Chun Cheng wrote: Hi, I'm using mingw cross compiler (with GNU autotools) under Linux to build DLL. One of the package I build is gnet2-2.0.8 which will link winsock library. Everything is OK, the DLL is created under Linux. When I copy the library to WinXP and use gnet2-2.0.8 to create network my app. The libtool complain that it can't handle -lws2_32 and show me error message: *** Warning: linker path does not have real file for library -lws2_32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting I try to trace what's wrong in libtool ... and found that libtool try to search libws2_32.dll under couple paths ... but libtool does not know the real DLL is c:\windows\system32\ws2_32.dll !! cross compiler ? In cross-environment import library is .../TARGET_ALIAS/lib/libws2_32.a along with other import libraries. If I copy/rename c:\windows\system32\ws2_32.dll to c:\mingw\bin\libws2_32.dll then everything work OK. Is this expected ? or a libtool bug ? Not sure what is cause of issue. The process of you copy is not clear. ... and use gnet2-2.0.8 to create ... .. Warning: linker path does not have real file for library -lws2_32 Look like issue with native build and missing installation of w32api dev. package. Thanks KC Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
Matěj Týč wrote:
On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...
I suggest the following naming scheme.
mingw.org: libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64): lib64name-major.dll
mingw-w64(32): lib32name-major.dll
libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).
Comments?
AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?
No http://lists.gnu.org/archive/html/libtool/2007-07/msg00064.html
[SNIP]
This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.
I'm not sure that idea for lib{64|32} is so good.
As I know for 32 bit process 64 bit microsoft windows os will return
%WINDOWS%\SysWOW64 as system folder. For 64 bit process it is
%WINDOWS%\System32 (no comment on design), Program Files for 64-bit
and Program Files (x86)(?) for 32-bit (more on MSDN).
I'm not sure that libtool has to know how lets call it redirection work.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
Matěj Týč wrote: [SNIP] Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silence complaints. [SNIP] -module flag will install dll in $libdir and without flag in $libdir/..bin for stable release . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
JonY wrote: On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Hi, If you looked at the concept patch, it changes how libtool names the DLL by soname_spec, libname_spec stays the same. The makefiles do not see the DLLs at all, only the .la files if libtool is in use. The .la filenames stay the same. That is the whole point of libtool, devs don't need to bother about platform specific details and implementation of shared libs. Uhh and the libtool install la files and process installed. So after installation xx-bit will override yy-bit. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Gary V. Vaughan wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. The Libtool Team is pleased to announce release candidate 2.2.7b of GNU Libtool. If there are no serious deficiencies reported in this release, it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix any problems and put out 2.2.7d first). [SNIP] I not sure that this is resolved : http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00028.html; Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Gary V. Vaughan wrote: Hi Roumen, On 22 May 2010, at 03:26, Roumen Petrov wrote: Gary V. Vaughan wrote: The Libtool Team is pleased to announce release candidate 2.2.7b of GNU Libtool. If there are no serious deficiencies reported in this release, it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix any problems and put out 2.2.7d first). [SNIP] I not sure that this is resolved : http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00028.html; Can you confirm that the testcase at the end of this link still shows a failure on Windows? I haven't used a Windows machine in almost a decade, and don't have access to one. I don't have windows host and for some test I must wait feedback from friends. I'm not sure that test case is only windows issue. Yes I know that similar test pass on elf shared libraries. Right now I'm not able to write test that fail on linux except the case described here http://www.aleksey.com/pipermail/xmlsec/2010/008866.html The patch that resolve issue for xmlsec is to move libxmlsec1.la as dependend library at end: libxmlsec1_openssl_la_LIBADD = \ - ../libxmlsec1.la \ $(OPENSSL_LIBS) \ $(LIBXSLT_LIBS) \ $(LIBXML_LIBS) \ + ../libxmlsec1.la \ $(NULL) This build against dependent libraries with and without la-files (openssl is one of them) and one of attachments is difference : libtool output before and after patch. Is the problem due to Windows searching for DLLs along $PATH? And, if so, do you know whether the current directory is always searched first irrespective of the PATH setting? If your answers are 'yes' and 'no' respectively, I might be able to look into the wrapper script code and figure out why PATH is not being set correctly. In either case, I'll be happy to accept a patch :) As I post here http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html very simple issue is to prepend to PATH value of EXE_PATH_VALUE first and LIB_PATH_VALUE second. Cheers, Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool, multilib and test duplicate convenience archive names
Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to 'gcc|g++ -m32', i.e. multilib . The libtool regression suite fail in test case : 25: duplicate convenience archive names FAILED (duplicate_conv.at:83) From testsuite.log: .../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la stderr: .../ld: Relocatable linking with relocations from format elf32-i386 (.libs/c.o) to format elf64-x86-64 (cee.o) is not supported stdout: libtool: link: .../ld -r -o cee.o .libs/c.o --whole-archive a/.libs/liba.a b/.libs/liba.a --no-whole-archive Eric PAIRE post a patch about linker emulation mode - ref. http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html . Based on Eric's suggestion I try to build without to set --host, i.e. as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers. As result -m elf_i386 is added to linker (LD) and libtool regression test pass with: 114 tests behaved as expected. 12 tests were skipped. Any thought on this ? Regards, Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, multilib and test duplicate convenience archive names
Hi Andreas and Bo, Please could you clarify build of 64-bit system for 32 bit. Roumen Petrov wrote: Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to 'gcc|g++ -m32', i.e. multilib . The libtool regression suite fail in test case : 25: duplicate convenience archive names FAILED (duplicate_conv.at:83) From testsuite.log: .../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la stderr: .../ld: Relocatable linking with relocations from format elf32-i386 (.libs/c.o) to format elf64-x86-64 (cee.o) is not supported stdout: libtool: link: .../ld -r -o cee.o .libs/c.o --whole-archive a/.libs/liba.a b/.libs/liba.a --no-whole-archive Eric PAIRE post a patch about linker emulation mode - ref. http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html . Based on Eric's suggestion I try to build without to set --host, i.e. as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers. As result -m elf_i386 is added to linker (LD) and libtool regression test pass with: 114 tests behaved as expected. 12 tests were skipped. Any thought on this ? Traced to 2002-11-18 Andreas Jaeger a...@suse.de, Bo Thorsen b...@suse.de * libtool.m4: Support linking of 32-bit libraries with ld on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems. Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Hi Gary, Gary V. Vaughan wrote: Hi Chuck, I note that no other GNU projects that I'm aware of jump through all the __declspec hoops that the libltdl API tries to provide through LT_SCOPE. Is any of this stuff still required on any non-museum Windows compiler that would break if I removed it? [] The export decorator cannot be removed as is unknow how one project will build and try to export symbols. Please find attached file bootstrap.sh with test cases that show export functionality on windows platform gcc compiler - function export depend from export statement and export attribute: Test cases 1 are without export decorator as 1x export only one of functions. Application 1x fail to link Test cases 2 are with export attribute as 2x export only one of functions. Boot application will be linked due explicitly defined export attribute. Export of variables is other case . Also if export attribute is applied only to variables if I remember function will not be exported. Regards, Roumen bootstrap.sh Description: Bourne shell script bootstrap.sh.gz Description: GNU Zip compressed data ___ https://lists.gnu.org/mailman/listinfo/libtool
bootstrap --copy
Hello Gary, After monster updates in repository please could you help me to bootstrap libtool. I don't like to create symbolic links, so I use --copy argument , but since 2011-11-08 it does not work. The command is ./bootstrap \ --copy \ --force \ --gnulib-srcdir= Output is: Current branch is up to date. Usage: bootstrap MACRO_NAME FILE [...] Try `bootstrap --help' for more information. bootstrap: error: unrecognised option: `--copy' $ ./bootstrap --help bootstrap MACRO_NAME FILE [...] Bootstrap this package from checked-out sources. Common Bootstrap Options: -c, --copy copy files instead of creating symbolic links. --debugenable verbose shell tracing . Best Regards, Roumen Pertov ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Bad LD_LIBRARY_PATH set in the libtool wrapper
Sam Varshavchik wrote: My source tree builds two libraries, from two separate directories in the source tree. libxtls.la gets linked against libx.la in a different directory, as well as some system libraries in /usr/local/lib. Makefile.am declares thusly: libxtls_la_LIBADD=../base/libx.la libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread libtool use LDFLAGS before LIBADD as result paths form LDFLAGS will be used first. Move $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread to LIBADD adn try again. Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
Hi Filipe, Filipe Brandenburger wrote: Hi, I'm trying to link binaries to libraries that are not installed on the system, but just unpacked to a staging directory. [SNIP] Is this a libtool bug? Any suggestions of workarounds? (I also filed a bug at http://savannah.gnu.org/support/index.php?108637 in case this is actually a libtool bug.) Libtool exclude directories from RPATH if path is listed in sys_lib_dlsearch_path_spec - list of space separated directories. Variable sys_lib_dlsearch_path_spec is generated from a libtool macro. On linux with FSF libtool version value start with /lib /usr/lib and existing directories from /etc/ld.so.conf . After configuration user could check current value with command: $ ./libtool --config | grep sys_lib_dlsearch_path_spec ( I assume that package build process generate libtool script in build directory ) You could use lt_cv_sys_lib_dlsearch_path_spec to override it at configure time. .../configure \ ... lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH ... Regards Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: merging various libraries into a single DLL on windows
Werner LEMBERG wrote: Folks, my ttfautohint library exports a single function (`TTF_autohint') and depends on freetype and harfbuzz. A user posted the following recipe to merge these three libraries into a single DLL in Windows. Looks like use of libtool "Convenience" libraries. [SNIP] Regards, Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Why is Guile unable to find libtool?
Hi Bruce, Bruce Korb wrote: $ ./configure . checking for libltdl... no configure: error: GNU libltdl (Libtool) not found, see README. This error is for "libtool dynamic loader library" ltdl. Perhaps you system distribute separate libtool and libltdl packages. $ type libtool bash: type: libtool: not found libtool is generated script. Some vendors decided do not distribute script generated (build) by libtool package. Usually there is no such need. [SNIP] $ type libtool bash: type: libtool: not found After successful configuration of you project 'libtool" script(s) will be generated in build tree. Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Does libtool need to escape plus signs in egrep expressions?
Hello, LRN wrote: While looking though ltmain source code i've stumbled upon this egrep invocation: $EGREP ' (_head_[A-Za-z0-9_]+_[ad]l*|[A-Za-z0-9_]+_[ad]l*_iname)$' I've tried to see how it behaves on some import libraries that i have, and it turned out that i could never get it to detect the iname lines, unless i escape the plus sign. May be I misunderstand issue. $ echo ' _head_ABC_a' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' _head_ABC_a $ echo ' _head_ABC_al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' _head_ABC_al but: $ echo ' _head__al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' $ echo ' __head_ABC_al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' $ echo ' _head_ABC_zl' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' Are you sure this actually works? I'm not expert in regular expressions but according above tests "plus" in RE works - see case _head__al . Note that the function that does this is only used in rather exotic corner-cases (old dlltool and/or ms dumpbin being in use), so it's plausible that it could have been broken since 2010, when it was added. Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Accounting for -rpath when libtool isn't helping
Hi Paul,
Paul "LeoNerd" Evans wrote:
[SNIP]
Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libtool to link it
(such as is the case here).
No , I don't think that this is valuable.
With that in mind, I now generate those if required, in the little
shell fragment I use to create the .pc file:
#!/bin/sh
LIBS='-L${libdir} -ltickit'
CFLAGS='-I${includedir}'
case "$LIBDIR" in
/usr/lib) ;;
/usr/local/lib) ;;
*)
LIBS="$LIBS -Wl,-rpath -Wl,$LIBDIR"
;;
esac
cat <
Like you perl (first email) and shell (above) scripts libtool do similar
to decide when to add "runpath" linker flag. Libtool parses
/etc/ld.so.conf and "build-in default paths" and if a library path is
not in list adds "runpath" flag.
On most platform you control this via variable
lt_cv_sys_lib_dlsearch_path_spec. Pattern *_cv_* mean that this is a
"autoconf cache variable" and "lt" is custom namespace prefix.
Add $HOME/lib to list to avoid -rpath flag.
For some autoconf builds with use of libtool you could force -rpath if
needed - add those options to LDFLAGS ( see ./configure --help) .
Regards,
Roumen Petrov
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
Yuri wrote: On 2019-06-23 12:19, Roumen Petrov wrote: cc ? I'm not sure which compiler suite is used on FreeBSD but it seems to me C++ compiler is not installed. clang8 is used. cc is a C compiler, c++ is a C++ compiler. Ok. Dunno why is not detected c++ at configure time. I'm not familiar with clang as C++ compiler, especially installed symbolic links. Please check configure output and then config.log to find why detection(tests) for C++ compiler fail. Also check detection of C complier. For instance autoconf macro should search for availability of g++ or c++ or cxx or CC and etc as C++ compiler commands. If clang C++ is not in list detection fail. If clang is default OS compiler is expected symbolic link c++ to clang++ or similar. May be some OS setup commands could set such links. Remark: At end ./configure --help outputs environment variables . Those variables could be used to tune build process. For instance CXX=my-c++ ./configure ... could be used to change C++ compiler. Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
Yuri wrote: On FreeBSD libtool can't find operator new[] because it is in C mode: libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize -pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o RNALfold RNALfold_cmdl.o RNALfold.o ../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm -pthread -fopenmp libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize -pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o RNALalifold RNALalifold_cmdl.o RNALalifold.o ../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm -pthread -fopenmp ld: error: undefined symbol: operator new[](unsigned long) >>> referenced by svm.cpp >>> svm.o:(Kernel::Kernel(int, svm_node* const*, svm_parameter const&)) in archive ../../src/ViennaRNA/.libs/libRNA_conv.a cc ? I'm not sure which compiler suite is used on FreeBSD but it seems to me C++ compiler is not installed. Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
Dunno what is wrong in Yuri's FreeBSD environment Bob Friesenhahn wrote: On Sun, 23 Jun 2019, Yuri wrote: So is there an easy way to override this and always use C++ way of linking? To do this you might need to set LD or CC to your C++ compiler. A better way is to make your main program be C++ since that assures it can work. Consider that C++ exceptions can not be thrown into C code unless a special compiler option is used so that C supports the exception framework. Without this you are likely to get a core dump. C++ is very good at using C code but C code is not very good at using C++ code. Bob In my environment /usr/bin/cc is link to gcc , linked to gcc-5.5.0, and c++ is linked to g++, linked to g++-gcc-5.5.0. In my environment. At configure time both compiles are detected as usable. At build time I could see: - for C code: CC foo CCLD bar - for C++ code: CXX alice CXXLD bob And projects builds just fine! Conclusion - there is no defect neither in libtool nor in automake nor in project autotool files. Reporter still does not provide feedback with information from configuration time (requested in a previous post) => resolution is - broken build environment. Regards, Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
uri wrote: > On 2019-06-24 09:55, Roumen Petrov wrote: >> >> And projects builds just fine! >> Conclusion - there is no defect neither in libtool nor in automake nor >> in project autotool files. >> >> Reporter still does not provide feedback with information from >> configuration time (requested in a previous post) => resolution is - >> broken build environment. > > > configure and Makefile.in contain -lstdc++. These could be different > between systems. On FreeBSD it should be -lc++. Both configure and Makefile.in are generated . You cannot blame configure for -lstdc++ as more or less is expected. It depend from so many things. For instance is normal a autoconf based project to check for function or libraries. Next is Makefile.in. It is generated from Makefile.am. Please check again ;). > > It worked when I patched these lines, Dunno why you shut in the dark. but this is error-prone because > some other toolchains might use a different C++ library. Yes , and instead to update generated scripts you could help project ViennaRNA to improve build with correct report. > > > Once the error-prone -lstdc++ are removed, libtool fails because it > links with the C compiler. Ha-ha. Interesting. Now I have idea how broke your build system . Please avoid to update randomly some scripts. One again ViennaRNA build fine in my environment. Build system uses proper compiler. NO ISSUE WITH LIBTOOL! > Yuri Regards, Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers
anonymous wrote: URL: <https://savannah.gnu.org/support/?109844> Summary: Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers Project: GNU Libtool Submitted by: None Submitted on: Sat 13 Jul 2019 09:50:51 AM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux ___ Details: ltmain.sh now (at least in Ubuntu 18.04) overrides the LD_LIBRARY_PATH with a It seems to me libtool does not override path. It should prepend projects specific paths to environment variable. Existing code: ... # Add our own library path to $shlibpath_var $shlibpath_var=\"$temp_rpath\$$shlibpath_var\" ... system library path, thus forcing the system libs over the user's custom path installed ones. I fixed this in TCE build by patching ltmain.sh in our build script generator script: https://github.com/cpc/tce/commit/820fe4475f65b38f4ec6c7013d1ddfe4510058c0#diff-36fd0e6bb489c013aa25e9a5fd4467a2 I'm not convinced that patch is correct. Let project build new version of a system library and try to perform some tests. Executable from regression tests should use library from "build tree" not system one. Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Martin Liška wrote: [SNIP] However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output. Thank you for identification of the root cause. I've just created a nm issue for that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355 It is clear that defect 25355 never will be fixed - by design plugin architecture is not suitable for lto and nobody would like to work on new version ( LD_PLUGIN_API_VERSION 2? ). So apparently it's a known limitation of the LTO plugin. Question is whether we can somehow workaround that? Work-around was already provided - please see following feedback : https://lists.gnu.org/archive/html/libtool/2020-01/msg00027.html Let me quote Nick Bowler feedback: Workaround: add -ffat-lto-objects to CFLAGS so you get proper symbol tables in object files and then set NM='nm --plugin ""' to completely disable the busted LTO support in nm. For example: ./configure CFLAGS='-flto -fno-common -ffat-lto-objects' NM='nm --plugin ""' Martin [SNIP]
Re: transitive shared library dependencies and installation
Hi Feri, wf...@niif.hu wrote: [SNIP] On the other hand, this overlinks the final binary: $ objdump -p .libs/translib | fgrep NEEDED NEEDED liba.so NEEDED libb.so NEEDED libc.so.6 libb.so is unneeded here (but is present in the installed program as well). Coincidentally, the most prominent search result https://wiki.mageia.org/en/Overlinking_issues_in_packaging Urgh, article with very limited niche. First is only for shared libraries, next unresolved externals in shared library, and finally requires "advanced" loader. For instance on Microsoft Windows shared library (DLL) does not allow "unresolved symbols". Remark: Initial example requires -no-undefined flags as library LDFLAGS (libtool requirement) for mingw* builds. Even that fact that for executable build command includes all libraries linker may exclude some of them. I guess that this is because usually build uses "import libraries". Dunno what is behavior if build is directly with DLLs. Another system is Android. System allows unresolved externals but loader is quite simple. To load dynamically shared library is must not contain unresolved externals. Static build: partial or complete. There is no rule in general. Linker picks required symbols from archives and may require some dependent libraries. So in some cases environment variable PKG_CONFIG set to pkg-config --static is solutions. mentions that "this is fixed using a patch from Debian" for libtool. I wonder why is patched libtool. Libtool is not only Debian. Is is supposed to work on all supported OS-se, distributions and etc. Because of those "fixes" it is mandatory to bootstrap source tarbal generated on Debian with M4 macros from FSF sources. Now I do this unconditionally on all source tarballs - it save my time. What's your position on this? Is overlinking a problem or not? (It causes problems for distributions.) No Idea. I guess that this is more related to the rules describing package dependencies. A package could be split into multiple sub-package. A project may produce one "big" library or several "small" libraries. In both cases upgrade of related package is maintenance hassle. Topic is not for libtool . It is more general. Should everybody use --as-needed globally to combat it? Something else entirely? On some OS-es --as-needed is enabled by default. I'm not aware why this model was chosen instead "s/tatus quo"./ As needed is fine with limited shared library format like those used on Microsoft windows (COFF?) - no unresolved, no weak symbols. In the past loader does not guarantee that load of library follow dependency rules. Also as needed may break use of weak aliases (ELF format). I'm not sure that libtool respect order of linker options like --no-as-needed or --as-needed. As alternative could be used patchelf. It seems to me question is how to remove some extra dependencies : automatically (--as-needed) or manually (using tools like patchelf). May be topic is not for libtool list. Regards, Roumen Petrov
Re: transitive shared library dependencies and installation
Hi Russ, libtool members, I work on open source projects in my spare time. And so I can not provide feedback promptly. Today I have time to re read mail thread and to clarify my strong position. Russ Allbery wrote: Roumen Petrov writes: Urgh, article with very limited niche. First is only for shared libraries, next unresolved externals in shared library, and finally requires "advanced" loader. Overlinking isn't about unresolved externals in shared libraries. With unresolved I think about something different but this area is mostly out of scope to this thread. It's about avoiding linking with shared libraries that *don't* resolve any external symbols. This is one point - limited to "shared". Issue is not applicable for "static". It doesn't require an advanced loader, just any reasonably modern shared library system; Solaris 2.6 from many years ago had the same issue. I'm thinking about Android - with modern shared library system and poor loader. Autotools should work for such hosts as well. It is specific to systems where the linker is willing to encode dependencies to libraries (in NEEDED, for instance) that aren't actually required, but that's the default behavior of, say, GNU binutils. Yes binutils adds to "needed" all passed on command line libraries for ELF but not for COFF. The standard problem is that liba depends on libb, and a binary depends on liba (but not libb). Yes if you mean that binary uses only functions from "liba" and no one of all those functions need function from "libb". Let skip use of "data" from a library. If B [binary] uses Fa() [function from a] and Fa() uses Fb() [function from] the thinks are different. If we perform static build we must list both libraries. Another case is shared build. For COFF is used import library. Import library does not add "dependency". So we must list both libraries. Also for COFF list may contain "extra libraries". Binutil linker will link(pick) only ready used - there is no overlinking! Libtool's default behavior in the presence of *.la files will link the binary with both liba and libb, even though it only needs to be linked with liba. Only in "shared" build for ELF. This causes a lot of problems for the dependency management in a distribution if allowed to happen archive-wide, since it creates tons of unnecessary dependency edges that make dependency resolution and archive management much harder. And the main question is who is responsible to resolve this issues. Avoiding *.la files solves most of this. Using *la files is very helpful for static or for COFF shared builds! --as-needed helps when the upstream Makefiles are designed to support static linking (where all the libraries have to be listed), or where upstream just didn't pay attention to this or didn't consider overlinking to be a problem, but has been known to have bugs where it leaves out dependencies that actually are required. This is specific for ELF. It seems to me discussion for linker capability exceed scope of this mail list. For the software I personally maintain, --enable-reduced-dependencies changes the behavior of Autoconf macros to not add the full transitive set of libraries and instead only link with the immediate dependencies. But I think I'm the only person who uses that convention. For newer software that uses pkg-config, pkg-config supports this inherently if the library maintainers write correct pkg-config files (which a lot of them don't). The article may have limited applicability in the grand picture of all systems and all ways of linking libraries, but it applies to pretty much every Linux distribution (and probably any other distribution of any kind of UNIX that uses shared libraries and package dependencies). So by quantity of Libtool installs and invocations, it's significant. Open source is not limited to Linux. Build should be work on many OS-es(complilers, linkers, loaders). Article https://wiki.mageia.org/en/Overlinking_issues_in_packaging inform us about issue in preamble. Unfortunately context is totally misleading. It proposes correction in some build helpers - this definitely breaks other platforms. As exercise: Write configure script that test for presence of OpenSSL function EVP_add_cipher. Use existing macro AC_LINK_IFELSE. Ensure that it will work for shared and static build. Ensure that test will work on linux, mingw (solaris, android and etc.) hosts. Note configure script does not use linker wrapper scripts like libtool and I would like to suggest do not use macro PKG_CHECK_MODULES. I guess that after successful implementation my opinion about article will be more clear. Also article point to "underlinking". With other words proposed solutions for build helpers (pkg-config, libtool) will lead to underlinking on other platforms.. Off topic: For
Re: transitive shared library dependencies and installation
wf...@niif.hu wrote: Hi, I'm experimenting with the attached skeleton project on a Debian buster system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9): [SNIP] /usr/bin/ld: cannot find -lb collect2: error: ld returned 1 exit status libtool: error: error: relink 'a/liba.la' with the above command before installing it make[1]: *** [Makefile:446: install-libLTLIBRARIES] Error 1 make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib' make: *** [Makefile:798: install-am] Error 2 Libtool does not change "order" :(. Automake just uses project rules. Let view Makefile.in ... install-exec-am: install-binPROGRAMS install-libLTLIBRARIES ... install-binPROGRAMS: install-libLTLIBRARIES ... install-libLTLIBRARIES: $(lib_LTLIBRARIES) ... Above dependency explain all - lib_LTLIBRARIES is project (sample) specific. Project should ensure order. [SNIP] and use it from liba, linking the final binary fails: $ make [...] /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o translib translib.o a/liba.la libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so -Wl,-rpath -Wl,/tmp/translib/lib /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' As I understand it, the -rpath linker option on the above command makes a/.libs/liba.so use the already installed (old) version of libb, which lacks the b2 symbol. What's the solution here? Why isn't that -rpath option "delayed" until the relinking phase? Not reproducible with FSF release. Regards, Roumen Petrov
Re: transitive shared library dependencies and installation
Hi Feri, wf...@niif.hu wrote: [SNIP] It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has some issues with multiple dependent libraries (more then two). From debian was proposed a patch related to library dependencies. Unfortunately patch break existing regression test. From debian never was proposed version that pass regression test. Libtool 2.0 fixes his issues related to multiple libraries. On the same Debian did not stop to contribute patch that breaks libtool. As result when I decide to build something from source always to updated sources to FSF version. So the right question is did reporter test with FSF version? I'm the reporter, and I didn't test any other version, as I wasn't even sure whether my example was correct and was supposed to work. You sample is correct . One minor nit is AM_PROG_AR - it is not required for posted example. If you project requires use of this macro you should request automake 1.11.2 as minimum. Could you please provide some keywords to search for so that I can dig up the details of the above story? Please check libtool achives. To me situation on Debian is closed case. At the moment Debian carries 21 patches for libtool, if I could show that one of them breaks a valid use case, that would constitute a strong reason for dropping it. In moment I do tests on some sources from development or stable branches on an another system (archaic :) ): $ cat /etc/centos-release CentOS release 6.10 (Final) $ autoconf --version autoconf (GNU Autoconf) 2.63 $ automake --version automake (GNU automake) 1.11.1 $ libtool --version ltmain.sh (GNU libtool) 2.2.6b All is based on system packages except tested by me. Result on posted test case - pass: $ ./translib ; echo $? 12 $ readelf -a a/.libs/liba.so | grep RPATH 0x000f (RPATH) Library rpath: [/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib] $ readelf -a .libs/lt-translib | grep PATH 0x000f (RPATH) Library rpath: [/home/centos/.builds/test/autotools/translib/a/.libs:/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib] $ readelf -a .libs/translib | grep PATH 0x000f (RPATH) Library rpath: [/tmp/translib/lib] $ readelf -a /tmp/translib/lib/liba.so | grep PATH 0x000f (RPATH) Library rpath: [/tmp/translib/lib] Regards, Roumen Petrov
Re: transitive shared library dependencies and installation
Hello, wf...@niif.hu wrote: Roumen Petrov writes: wf...@niif.hu wrote: I'm experimenting with the attached skeleton project on a Debian buster Debian is key word. system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9): Libtool is patched, not FSF. [SNIP] /usr/bin/ld: cannot find -lb collect2: error: ld returned 1 exit status libtool: error: error: relink 'a/liba.la' with the above command before installing it make[1]: *** [Makefile:446: install-libLTLIBRARIES] Error 1 make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib' make: *** [Makefile:798: install-am] Error 2 [SNIP] and use it from liba, linking the final binary fails: $ make [...] /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o translib translib.o a/liba.la libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so -Wl,-rpath -Wl,/tmp/translib/lib /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' As I understand it, the -rpath linker option on the above command makes a/.libs/liba.so use the already installed (old) version of libb, which lacks the b2 symbol. What's the solution here? Why isn't that -rpath option "delayed" until the relinking phase? Not reproducible with FSF release. Could you please share your link command? Does you system use the new dynamic tags (DT_RUNPATH instead of DT_RPATH)? This does not make sense. With and without new dtags result will be the same. It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has some issues with multiple dependent libraries (more then two). From debian was proposed a patch related to library dependencies. Unfortunately patch break existing regression test. From debian never was proposed version that pass regression test. Libtool 2.0 fixes his issues related to multiple libraries. On the same Debian did not stop to contribute patch that breaks libtool. As result when I decide to build something from source always to updated sources to FSF version. So the right question is did reporter test with FSF version? Regards, Roumen Petrov
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
Hi Vincent,
Sorry for top posting.
Perhaps is not easy visible for manual (
https://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html
) use of conditional code.
In this case #ifdef PIC.
Perhaps better solution is use of -export-symbols.
Vincent Torri wrote:
Hello
I contribute to an autotools project. The tree is :
src/lib/libfoo <--- the library, with libfoo.h declaring the public symbols
src/bin/bar <-- the binary which uses libfoo and includes libfoo.h in
its source files
I want to create the library 'libfoo' on Windows. I also want to
declare public symbols with __declspec(dllexport) and
__declspec(dllimport) in a macro that I call MY_API in libfoo.h
Thanks to DLL_EXPORT that libtool is passing to the preprocessor when
compiling the library 'libfoo', there is no problem to compile libfoo.
MY_API is correctly defined either when I build the static lib, or the
shared lib, or both.
The problem I am facing is when I build the 'bar' binary. On Windows:
1) if 'lifoo' is built as a shared library, when I include libfoo.h in
'bar' source files, MY_API must be defined as __declspec(dllimport)
2) if 'libfoo' is built as a static library, when I include libfoo.h
in 'bar' source files, MY_API must be defined as nothing
but, as far as I know, when I compile 'bar', I couldn't find a way to
know if 'libfoo' has been compiled as a static library or as a shared
library. I have looked at the 'bar' source files gcc calls, and they
are the same in both cases (libfoo compiled as a static or shared
lib). So I don't know how I can correctly define my macro MY_API.
Here is, for now, my macro:
#if defined(_WIN32) || defined(__CYGWIN__)
# ifdef FOO_BUILD // defined when building 'libfoo'
# ifdef DLL_EXPORT
# warning "BUILD DLL"
# define MY_API __declspec(dllexport)
# else
# warning "BUILD STATIC"
# define MY_API
# endif
# else
# warning "IMPORT DLL"
# define MY_API __declspec(dllimport)
# endif
in the last #else, I don't know what to do to correctly manage MY_API
for my problem above
One solution would be : never compile 'lbfoo' as a static lib ("DLL
are good on Windows"), but I would like to support both static and
shared libraries.
Does someone know how to solve my issue ? (I hope I've been clear enough...)
thank you
Vincent Torri
Regards,
Roumen Petrov
Re: disable invocation of winepath by libtool
Ozkan Sezer wrote: On 12/5/21, ilya Basin wrote: Dear List. I'm cross compiling a program on Linux for a mingw host and sometimes this shows Wine dialogs like "updating wine configuration" or "download and install Mono". I believe it's only needed to run `make check` successfully, but I want to skip the test suite. How to properly prevent the invocation if winepath? Using winepath in libtool really is an abomination and must be removed. Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 Using winepath is very useful to run regression tests in emulated environment on Linux. I cannot understand why wine in installed but not properly setup. Either remove wine or finish installation. Regards Roumen Petrov
Re: lt_dlopen an uninstalled library
Hi ilya,
ilya Basin wrote:
Hi List.
I'm making a program with plugins as shared libraries and when I run `make
check` I want my program to load the uninstalled plugins using lt_dlopen().
I expected that passing `-dlopen libname.la` to libtool would force the generation of a wrapper script
setting the proper LD_LIBRARY_PATH (just like regular linking with a shared .la does). However, an ELF binary
is generated and and attempt to call lt_dlopen("libname.la") fails with "File not found".
It only succeeds if the filename contains "./.libs/". What am I doing wrong?
No idea.
Just one note that environment variable is LTDL_LIBRARY_PATH - dynamically load
libtool library.
Path for shared libraries depend from OS.
[SNIP]
Roumen
Re: libtool is adding "-L/usr/lib" even for cross-compilation with sysroot
Hi, Xi Ruoyao wrote: Hi libtool dev, We've recently hit an issue cross-compiling some package using libtool for sysroot. Saying libfoo.la contains So there is a number of models . One to use system libtool and another one libtool script builds for project. First is not for cross-compilation. Second one should learn some thing related to build system . libdir=/usr/lib Then libtool will add "-L/usr/lib" to the linker command line during a "relink" against libfoo.la, because ltmain.in:6500: [SNIP] For instance my script hat builds packages for Android has: ... CC="$CC --sysroot=$ANDROID_SYSROOT" ... CONFIG_SITE=$TMPDIR/config.site-$FULLNAME-$PLATFORM cat > $CONFIG_SITE <
Re: new release?
Hi Alex Ameen, Alex Ameen wrote: This is a good question. I plan on making a new release this month. When I first adopted the project I ambitiously thought I'd manage to create a new release after about a month; but the truth is when I started doing a deep dive into the internals there was a lot of history and complexity for me to unpack. Things that are easy to overlook like how change-logs get generated, quirks in the testing framework, and tracing down disparate areas to align documentation took quite a while to navigate. Last maintainer heavy broke libtool scrips we "automatic" code formatting scrips. Happy hacking such brokenness. The good news is that I think I've got the confidence to push a release soon. One area that I was reading up on this weekend was whether the "alpha"/private releases of `libtool' might be appropriate, or whether I should just push a release immediately. I'll admit I am leaning towards just making a release to avoid the entire alpha process for the time being. I appreciate you reaching out; I definitely want to get a release out before March. More feasible is to apply patches to 2.4.6 branch and to release from this really stable and proven to work version. IN such case next could be 2.4.8. Next point is name of development branch. For some reasons projects switch to main branch. Following move libtool could create main branch based on 2.4.6. From main branch could be released 2.6. It seems to me more users will test release version then beta or release candidate. [SNIP] Regards, Roumen Petrov
Re: New libtool maintainer
Ozkan Sezer wrote: On 2/8/22, Julien ÉLIE wrote: Hi Alex, Feel free to reach out if you have pending patches/issues you want to "bump", ideas for improvements, general advice for a new GNU maintainer - and above all if you'd like to lend a hand toward getting `libtool' up and running again. Many thanks for your work on Libtool! I believe a good start would be to integrate suggestions and patches from the issue tracker https://savannah.gnu.org/patch/?group=libtool and maybe also some patches Debian (and other distributions) have added over the years to the last 2.4.6 release. For instance: https://sources.debian.org/patches/libtool/2.4.6-15/ We must be very careful with Debian patches! Only Debian distributes version (valid for 1.4 and 2*) that cannot pass libtool regression tests. As result is expected Debian to be flooded with defects. Some of the outstanding bugs with existing patches : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137 (and its dups at 22895, 31900, and 36762) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21503 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559 Some of the outstanding bugs without any suggested patches: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479 If those bugs are not Debian specific someone could look at them. Libtool projects must not care for defects that shows Debian libtool brokenness. Regards, Roumen Petrov
Re: Word splitting with zsh fix
Hi Raúl,
I would like to know if option SH_WORD_SPLIT is set problem is solved too ?
Test case:
===
#!/bin/zsh
VAR=v1 v2
for V in ${VAR}; do
echo V1=$V
done
setopt SH_WORD_SPLIT
for V in ${VAR}; do
echo V2=$V
done
===
When SH_WORD_SPLIT is set zsh work as bash, ksh, ash etc.
DervishD wrote:
Hi all :)
I've spotted a problem with libtool that has to do with the word
splitting that Zsh does in the expression '${1+$@}' (which, in
turn, is a workaround to fix the $@ expansion problem when the
variable is empty in old shells). GNU autoconf has already corrected
this problem, and I'm using a similar fix for libtool. The patch is
gzipped and attached to this message.
Looking at the SUS (POSIX) standard, I'm not sure if field
splitting should be performed in the above expression or not, so I
don't know if the correct behaviour is what Bash does or what Zsh
does. Anyway, I'm not here looking for a culprit but for a solution.
I will be glad to discuss the issue, anyway, just for curiosity's
sake ;)
I've tested the patch against littlecms sources, because that's
the package where the problem was spotted by David Gómez Espinosa
[EMAIL PROTECTED]. The patch was suggested by Andrey Borzenkov
[EMAIL PROTECTED].
Thanks in advance and happy hacking :)
Raúl Núñez de Arenas Coronado
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: portability of -Lrelative_directory_name
Bruno Haible wrote: Hi, A while ago someone said that if in a build directory I have a (not yet installed) ../lib/libfoo.la, to link with this library I should *not* use libtool ... -L../lib -lfoo but rather mention the .la file explicitly: libtool ... -L../lib ../lib/libfoo.la or libtool ... ../lib/libfoo.la Now I see the same advice in the second-to-last paragraph of http://wiki.finkproject.org/index.php/Fink:Porting_Notes Is it true that references to non-yet-installed libool libraries should not be made with -l? If so, it would be worth to document this in the libtool documentation. I didn't find it there. Bruno Automake document this in paragraph Program and Library Variables xxx_LIBADD and xxx_LDADD But if project don't use automake may be good libtool to detail too. Roumen ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Roumen Petrov wrote: Ralf Wildenhues wrote: * Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET: [SNIP] Hmm during the tests tests/demo/helldl.exe is compiled many times. First is ok, later don't produce output(exit code 127) and tests/demo/.libs/helldl.exe crash. Roumen ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote: On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote: [ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319 or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ] Hi Behdad, everyone, Hi again, Sorry for the delay again. So, yeah, replying after two years... I know. Hope you still remember this issue and the patch is not too stale by now... * Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET: On Wed, 1 Mar 2006, Ralf Wildenhues wrote: * Behdad Esfahbod wrote on Wed, Mar 01, 2006 at 05:15:17AM CET: This is a feature request for libtool. Let me describe the problem as I face it, so you may have a workaround for it already: I'm using libtool in the Pango text rendering engine. The Pango library accesses a file in $prefix/etc/pango/pangorc to find its modules at run-time. Now all I want to do is to be able to run the examples in pango/example when Pango is not installed. The easiest way that can be done is to set the PANGO_RC_PATH envvar to a special pangorc file. Another is to pass the --pangorc path-to-pango-rc to the examples if they understand it. What I need from libtool is to let me do one of these things in the wrapper it creates for uninstalled binaries. [ my concerns were: we don't always build a wrapper ATM. ] Sure, a wrapper is created if need be. And this feature can be just another reason to create a wrapper. If we can find an answer to this question to define coherent semantics, I'm all for it. Ok, this is my view of the problem: Running uninstalled programs requires some modifications to the environment. One is to make sure that the uninstalled libraries are linked. Other changes may be needed, on a per application basis. Libtool is free to choose how to implement these. So far it has only supported the library path modification, and implemented that using a wrapper script on some platforms, or using rpath on others (right?) More or less, yes. The same goes with the other modifications. They can be easily implemented using a wrapper. So if there are such modifications requested, a wrapper should be used. Yep. And that's really the easiest solution: as soon as extra arguments or extra environment variables are passed, we always build a wrapper. My current workaround has been making pango-view accept a --pangorc path-to-pangorc parameter and defaulting to ./pangorc. But that opens up a known security problem... So I really want to fix it the right way. I don't quite understand how this fixes any security problems... but here you go with a suggestion (against current CVS HEAD). The attached patch implements two new link flags, -wrapper-arg and -wrapper-env, to prepend arguments to programs, and modify their environment. They will force creating a (shell) wrapper. Here's the hairy part about it: somebody may eventually want to extend the C wrapper that is currently used on w32 to encompass all the functionality that the shell wrapper currently has. And while I don't have current plans about this, I still don't want to add any unnecessary obstackles to it. Fair enough. So whatever we add to the shell wrapper should be doable easily in a C wrapper as well. This led me to add these restrictions: the -wrapper-env works like putenv: you pass an argument `var=value', the variable will be exported, the value will _not_ be interpreted by the shell any more. For now you cannot unset variables (this is to cater for hosts with a shell that does not support `unset'), and, e.g., -wrapper-env 'foo=$bar' will cause the environment variable `foo' to contain the four characters $, b, a, and r, not the contents of the variable $bar. But make variables are expanded, right? Similarly, -wrapper-arg will add exactly one literal argument to the exec. I've put suitable quoting in place for this to work with most kinds of input, and of course a test to this end. What do you think? OK for HEAD right now, or do you think this is too intrusive now? Sounds good to me. Can it finally go in?! I think we should not backport this to 1.5.x, it is a new feature. Cheers, Ralf Cheers, I think that all above is out of libtool scope. It's is exceptional project specific (lets skip cross-compilation environment) and is subject of project regression test suite. The project is responsible to set appropriate test environment before to run regression test. Please let me know when I don't understand request properly. Roumen
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set appropriate test environment before
to run regression test.
Please let me know when I don't understand request properly.
It's not about regression testing at all. It's about making binaries in
uninstalled builds work. For example, many GNOME applications need to
load their UI from XML files. If you build and not install them and try
to run from the build dir, not surprisingly, the XML file is not found
at destination, and the program will fail to start. With my proposed
additions, programs can for example check for an env var for an
alternative prefix, and the Makefile.am can pass that information to
libtool to put into the wrapper. Then running from uninstalled build
will work.
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
Roumen
Cheers,
Exactly, libtool do home work and set LD_LIBRARY_PATH (DYLD_LIBRARY_PATH
, LIBRARY_PATH, PATH and etc. host/platform specific environment library
search paths) but for application specific environment is author/project
responsibility. I see that you understand case when a library isn't
installed at specified(system) location. This library will load
dependent libraries from default(system) library search path. So the
wrapper script help correct library to be loaded so the libtool home
work is done.
But if user run directly an application installed in non-default
location the user is responsible to set environment.
If its a regression/unit test the correct application environment has to
be set in Makefile{|.in|.am} and the program/library will inherit it.
Roumen
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
There is no significant difference !
If its a regression/unit test the correct application environment has
to
be set in Makefile{|.in|.am} and the program/library will inherit it.
No, it's not a test suite. It's a real, legitimate application the user
has built. Now he wants to run it before doing make install.
And if application don't read environment, next request is libtool
wrapper script to pass arguments to application command line.
The whole idea is libtool overkill.
Roumen
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
There is no significant difference !
I thought there is. The former is not supported, while I'm under the
impression that the latter is.
If its a regression/unit test the correct application environment has
to
be set in Makefile{|.in|.am} and the program/library will inherit it.
No, it's not a test suite. It's a real, legitimate application the user
has built. Now he wants to run it before doing make install.
And if application don't read environment, next request is libtool
wrapper script to pass arguments to application command line.
The argument passing is part of the patch too. But one or the other is
enough, because the application developer can use whatever is available
to them. Currently, there is no way to fix this problem with autotools.
With the proposed changes, there will be. That's all.
About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the tests
is created specific xml catalog and application is run with this catalog
instead with system.
The whole idea is libtool overkill.
Fair enough. Just suggest an alternative please, instead of acting as
if the problem does not exist.
Roumen
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote: On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote: In some cases application depend from other services. In this case a specific to project wrapper script has to run services, to check if service is run, to run project application and when application finish to stop service. The test can be run from makefile. Now I'm getting the impression that you selectively read the responses in this thread and ignore the rest. Please tell me *how*, from makefile or otherwise, the problem can be solved such that when my user goes into his build directory and runs the command: $ ./pango-view how as the developer, I can make that command run in a modified environment? I perfectly know this problem. Un-installed application cannot be run without to prepared suitable environment. About six years I maintain X.509 certificate support in OpenSSH and I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. Roumen
Re: Feature request: setting env vars for binary wrappers
Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST: The only substantial change is for static builds which currently don't have a wrapper. Yes. The static build is a more significant concern since static builds are often used for debugging purposes and if we hide the static binary in a subdirectory, it may be more difficult to debug. Good point, thanks. We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Well, did this cease to work (except for the bug which was fixed in 2.2.2)? ./libtool --mode=execute gdb ./prog --args ... I think that existing --mode=execute is enough. Roumen
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote: On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote: I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. And if you are happy with that, good for you. :) In GNOME Ohh no though, we want our users to be able to run uninstalled programs. If this feature is not interesting to you, fine. I don't understand why you are so opposing it. Apparently not on any technical reasoning. For my users, from make and some wrapper script, I setup environment, run some servers (as example openldap with preloaded data) run un-installed programs so my users see that things work before to install. Roumen
Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.
Hi Charles, About following comment: /* execv doesn't actually work on mingw as expected on unix */ Actually execXXX on microsoft windows create a new process and it is not mingw problem. What about to substitute mingw with windows ? Roumen Charles Wilson wrote: Charles Wilson wrote: 2008-05-05 Charles Wilson ... * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated pathlists. (func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]: ensure putenv and setenv are declared. Define HAVE_SETENV. (func_emit_cwrapperexe_src) [main]: add new constants to hold desired PATH settings; initialize and convert to native mingw format using functions above. Add new command-line options --lt-env-set, --lt-env-prepend, and --lt-env-append. No longer emit wrapper script as integral part of launching child. Remove support for (now) unnecessary $TARGETSHELL. Exec actual target executable directly. (func_emit_cwrapperexe_src) [lt_setenv]: new function. (func_emit_cwrapperexe_src) [lt_extend_str]: new function. (func_emit_cwrapperexe_src) [lt_split_name_value]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new function. (func_emit_cwrapperexe_src) [lt_update_exe_path]: new function. (func_emit_cwrapperexe_src) [lt_update_lib_path]: new function. The attached patch (to be applied over the previous one) addresses the comments received so far. I can post the merged patch if desired -- and of course, I'll squash into a single patch before I push. Cygwin: passes 115 (9 skip) on old test suite only two unexpected failures on new test suite -- but 25 and 72 are actually expected on cygwin. Mingw (msys): no regressions over previous results: old test suite: fails demo-exec after demo-shared (helldl) fails the fortran tests, but that's a peculiarity of my system new test suite: fails 25 and 72 (expected), and 58-60 (a problem with the autotool wrappers on my system) OK for push? -- Chuck
Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.
Charles Wilson wrote: Charles Wilson wrote: 2008-05-05 Charles Wilson ... * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated pathlists. (func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]: ensure putenv and setenv are declared. Define HAVE_SETENV. (func_emit_cwrapperexe_src) [main]: add new constants to hold desired PATH settings; initialize and convert to native mingw format using functions above. Add new command-line options --lt-env-set, --lt-env-prepend, and --lt-env-append. No longer emit wrapper script as integral part of launching child. Remove support for (now) unnecessary $TARGETSHELL. Exec actual target executable directly. (func_emit_cwrapperexe_src) [lt_setenv]: new function. (func_emit_cwrapperexe_src) [lt_extend_str]: new function. (func_emit_cwrapperexe_src) [lt_split_name_value]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new function. (func_emit_cwrapperexe_src) [lt_update_exe_path]: new function. (func_emit_cwrapperexe_src) [lt_update_lib_path]: new function. The attached patch (to be applied over the previous one) addresses the comments received so far. I can post the merged patch if desired -- and of course, I'll squash into a single patch before I push. Cygwin: passes 115 (9 skip) on old test suite only two unexpected failures on new test suite -- but 25 and 72 are actually expected on cygwin. Mingw (msys): no regressions over previous results: old test suite: fails demo-exec after demo-shared (helldl) fails the fortran tests, but that's a peculiarity of my system new test suite: fails 25 and 72 (expected), and 58-60 (a problem with the autotool wrappers on my system) OK for push? -- Chuck libtool 2.2.4 patched with both patches still fail: ... (lt_setenv) setting 'PATH' to ':/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:/tmp/test/pkg/lt-2.2.4-mingw-mlib/lib:/tmp/test/pkg/lt-2.2.4-mingw-mlib/bin:/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:c:\windows\system32;c:\windows;z:\opt\mingw\bin' (main) lt_argv_zero : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe (main) newargz[0] : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe err:module:import_dll Library libfoo2.dll (which is needed by LZ:\\\\lt-2.2.4-mingw-mlib\\appl\\.libs\\foo.exe) not found ... The PATH contain unix instead dos path-separator. Roumen
Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.
Charles Wilson wrote: Roumen Petrov wrote: libtool 2.2.4 patched with both patches still fail: ... (lt_setenv) setting 'PATH' to ':/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:/tmp/test/pkg/lt-2.2.4-mingw-mlib/lib:/tmp/test/pkg/lt-2.2.4-mingw-mlib/bin:/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:c:\windows\system32;c:\windows;z:\opt\mingw\bin' (main) lt_argv_zero : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe (main) newargz[0] : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe err:module:import_dll Library libfoo2.dll (which is needed by LZ:\\\\lt-2.2.4-mingw-mlib\\appl\\.libs\\foo.exe) not found ... The PATH contain unix instead dos path-separator. Right. With *this* patch, I do not expect improvement with cross-compiles. This is just the first step. To get cross-compiles working, I need to *extend* this change using some of the techniques demonstrated in the 'convert_mingw_paths_with_wine.sh' script -- which is the #3 attachment to this message: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html One step at a time -- Chuck I confirm that in cross environment (wine emulation) is enough to replace all ':' (unix) with ';' (dos) in LIB_PATH_VALUE and LIB_PATH_VALUE to get cwrapper to work. Roumen
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
Charles Wilson wrote: [mingw] Add cross-compile support to cwrapper * libltdl/config/ltmain.m4sh (func_to_host_path): If present, use winepath to convert from $build to $host if $host is mingw and $build is neither mingw (msys) nor cygwin. Also update comments. (func_to_host_pathlist): Ditto. --- This is a follow-on to the recent patch dealing with the cwrapper for mingw and cygwin. This patch adds the ability for cross-compile setups (where $host=mingw and $build=not mingw/msys, not cygwin, but some *nix with wine) to generate correct binary wrappers. winepath, if found, is used to convert $build (unix) paths to the appropriate windows-style paths /inside/ the wine environment. If winepath is not found, then the $build path will be used by the cwrapper (which is the current behavior for cross-compile to mingw $host). Obviously, the $build path is not correct, so the cwrapper won't work -- but the build will continue successfully after printing a warning, so no harm. However, I can't test this patch directly. The concepts work in my stripped-down wine-on-linux install, but I don't have a full mingw environment to test the whole thing in. I *did* verify that this patch causes no regressions for native cygwin, and native mingw. Also, I think that, even in the best of cases and everything works as I expect, you'll either have have the linux binfmt extension working to actually run the test suite in a cross-compile setup, because I don't know how you'd convince the testsuite machinery to prefix every program invocation with '/path/to/wine ...' Anyway; please /test/. Chuck libltdl/config/ltmain.m4sh | 97 +-- 1 files changed, 65 insertions(+), 32 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 0bfae76..197920c 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2515,12 +2515,19 @@ func_emit_wrapper () # # Convert paths to build format when used with build tools. # Intended for use with native mingw (where libtool itself -# is running under the msys shell). Ordinarily, the (msys) shell -# automatically converts such things for non-msys applications -# it launches, but that isn't available from inside the cwrapper. -# Similar accommodations are necessary for $host mingw and $build -# cygwin. Calling this function does no harm on other $build or -# for other $host. +# is running under the msys shell), or in the following cross- +# build environments: +#$build $host +#mingw (msys)mingw [e.g. native] +#cygwin mingw +#*nix + wine mingw +# where wine is equipped with the `winepath' executable. +# In the native mingw case, the (msys) shell automatically +# converts paths for any non-msys applications it launches, +# but that facility isn't available from inside the cwrapper. +# Similar accommodations are necessary for $host mingw and +# $build cygwin. Calling this function does no harm for other +# $host/$build combinations not listed above. # # ARG is the path (on $build) that should be converted to # the proper representation for $host. The result is stored @@ -2546,6 +2553,13 @@ func_to_host_path () func_to_host_path_result=`echo $func_to_host_path_tmp1 |\ $SED -e $lt_sed_naive_backslashify` ;; + * ) +if winepath -h /dev/null 21 ; then + func_to_host_path_tmp1=`winepath -w $1` + func_to_host_path_result=`echo $func_to_host_path_tmp1 |\ +$SED -e $lt_sed_naive_backslashify` +fi +;; esac if test -z $func_to_host_path_result ; then func_error Could not determine host path corresponding to @@ -2561,12 +2575,18 @@ func_to_host_path () # func_to_host_pathlist arg # # Convert pathlists to build format when used with build tools. -# See func_to_host_path(), above. +# See func_to_host_path(), above. This function supports the +# following $build/$host combinations (but does no harm for +# combinations not listed here): +#$build $host +#mingw (msys)mingw [e.g. native] +#cygwin mingw +#*nix + wine mingw # -# Path separators are also converted from ':' to ';', and if -# $1 begins or ends with a ':' it is preserved (as ';') on -# output. This description applies only when $build is mingw -# (msys) or cygwin, and $host is mingw. +# Path separators are also converted from $build format to +# $host format. If ARG begins or ends with a path separator +# character, it is preserved (but converted to $host format) +# on output. # # ARG is a pathlist (on $build) that should be converted to # the proper representation on $host. The result is stored @@ -2578,16 +2598,12 @@ func_to_host_pathlist () case $host in *mingw* ) lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g' -case $build in - *mingw* | *cygwin* ) -
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
Charles Wilson wrote: Roumen Petrov wrote: Charles Wilson wrote: [mingw] Add cross-compile support to cwrapper May be the patch can be more simple. In a previous post I confirm that for the wine emulator is enough items in path list, where every item is absolute path from build system, to be separated by DOS path-separator only. Right, and thank you for that. What wasn't clear, however, was whether this automatic path translation was a peculiarity of your wine setup (e.g. identity mounts or something) or is a documented feature of wine. Automatic path translation work for me. I may ask wine-developers to confirm. This is enough and at run-time wine(wineloader?) will translate internally from build system absolute path to the path from emulated environment. So it only works for absolute paths, but is applied to all environment variables (like PATH)? winepath will convert relative paths, AFAICT, although it converts them to absolute first, and canonicalizes if you have permissions to chdir to the target: No it work for relative paths too, but with limitation: path can be relative to the executable location and current work directory is equal to executable path it works. I attach my test case (bootstrap.sh) executabel + two dependent shared libraries from different directories. The wine is setup with $WINEPREFIX/dosdevices/m: linked MINGWCROSS Note that MINGWCROSS is absolute path in build system. Lets see output from the script: autotool build === ./foo-t1.exe === in main() in foo1(11) in foo2(22) in foo1(22) (main) argv[0] : ./foo-t1.exe (main) program_name : foo-t1.exe (find_executable) : ./foo-t1.exe (check_executable) : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) found exe (before symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) found exe (after symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) libtool target name: foo.exe (lt_setenv) setting 'BIN_SH' to 'xpg4' (lt_setenv) setting 'DUALCASE' to '1' (lt_update_lib_path) modifying 'PATH' by prepending 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;' (lt_setenv) setting 'PATH' to 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (lt_update_exe_path) modifying 'PATH' by prepending ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' (lt_setenv) setting 'PATH' to ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe (main) newargz[0] : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t1.exe DONE[t1]=126 === ./foo-t2.exe === in main() in foo1(11) in foo2(22) in foo1(22) (main) argv[0] : ./foo-t2.exe (main) program_name : foo-t2.exe (find_executable) : ./foo-t2.exe (check_executable) : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) found exe (before symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) found exe (after symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) libtool target name: foo.exe (lt_setenv) setting 'BIN_SH' to 'xpg4' (lt_setenv) setting 'DUALCASE' to '1' (lt_update_lib_path) modifying 'PATH' by prepending 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;' (lt_setenv) setting 'PATH' to 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (lt_update_exe_path) modifying 'PATH' by prepending ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' (lt_setenv) setting 'PATH' to ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe (main) newargz[0] : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t2.exe DONE[t2]=126 The libtool create C-wrapper with absolute paths. - foo-t1.exe, where ':' is replaced with ';' : can be run from any location. - foo-t1.exe, where path to one of libraries is relative
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
No answer from wine-developers ( http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html ) As expected you patch pass my test :). Lets go upstream. Roumen Roumen Petrov wrote: Charles Wilson wrote: Roumen Petrov wrote: Charles Wilson wrote: [mingw] Add cross-compile support to cwrapper May be the patch can be more simple. In a previous post I confirm that for the wine emulator is enough items in path list, where every item is absolute path from build system, to be separated by DOS path-separator only. Right, and thank you for that. What wasn't clear, however, was whether this automatic path translation was a peculiarity of your wine setup (e.g. identity mounts or something) or is a documented feature of wine. Automatic path translation work for me. I may ask wine-developers to confirm. This is enough and at run-time wine(wineloader?) will translate internally from build system absolute path to the path from emulated environment. So it only works for absolute paths, but is applied to all environment variables (like PATH)? winepath will convert relative paths, AFAICT, although it converts them to absolute first, and canonicalizes if you have permissions to chdir to the target: No it work for relative paths too, but with limitation: path can be relative to the executable location and current work directory is equal to executable path it works. I attach my test case (bootstrap.sh) executabel + two dependent shared libraries from different directories. The wine is setup with $WINEPREFIX/dosdevices/m: linked MINGWCROSS Note that MINGWCROSS is absolute path in build system. Lets see output from the script: autotool build === ./foo-t1.exe === in main() in foo1(11) in foo2(22) in foo1(22) (main) argv[0] : ./foo-t1.exe (main) program_name : foo-t1.exe (find_executable) : ./foo-t1.exe (check_executable) : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) found exe (before symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) found exe (after symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe (main) libtool target name: foo.exe (lt_setenv) setting 'BIN_SH' to 'xpg4' (lt_setenv) setting 'DUALCASE' to '1' (lt_update_lib_path) modifying 'PATH' by prepending 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;' (lt_setenv) setting 'PATH' to 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (lt_update_exe_path) modifying 'PATH' by prepending ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' (lt_setenv) setting 'PATH' to ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe (main) newargz[0] : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t1.exe DONE[t1]=126 === ./foo-t2.exe === in main() in foo1(11) in foo2(22) in foo1(22) (main) argv[0] : ./foo-t2.exe (main) program_name : foo-t2.exe (find_executable) : ./foo-t2.exe (check_executable) : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) found exe (before symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) found exe (after symlink chase) at : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe (main) libtool target name: foo.exe (lt_setenv) setting 'BIN_SH' to 'xpg4' (lt_setenv) setting 'DUALCASE' to '1' (lt_update_lib_path) modifying 'PATH' by prepending 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;' (lt_setenv) setting 'PATH' to 'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (lt_update_exe_path) modifying 'PATH' by prepending ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' (lt_setenv) setting 'PATH' to ';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' (main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe (main) newargz[0] : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t2.exe DONE[t2]=126
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
Charles Wilson wrote: Roumen Petrov wrote: No answer from wine-developers ( http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html ) As expected you patch pass my test :). That's good to know. Except for one issue [1], I'm of the opinion that my current patch is pedantically correct -- but slow, while your proposed modifications are optimizations. Lets go upstream. By this do you mean 'push to the git repo'? yes (push/commit/put/add in head/trunk/origin/master/main branch) I'd rather wait for Ralf to get back and comment; should be later this week I think. Roumen Petrov wrote: Charles Wilson wrote: But I'm not sure that supporting changing the mapping after building the wrapper is something we should support (e.g. deliberately code the wrapper to allow it, and then have to answer questions about why it does or does not work in some user's wacky wine setup, down the road.) Is there a realistic use case where this facility is important, that couldn't be solved by okay, then rm -f wrapper.exe, make wrapper Expanding on this point, right now we do not expect the wrapper *scripts* to work outside of their build directory: #! /bin/sh # mdemo_static - temporary wrapper script for .libs/mdemo_static # Generated by ltmain.sh (GNU libtool 1.2980 2008-05-13) 2.2.5a ... # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. And, if you change your fstab so that the effective path to the wrapper script changes -- even if you don't physcially mv from-here/wrapper to-there/wrapper I would still expect the wrapper script to be broken. Not to move - to change mapping: Let $WINEPREFIX/dosdevices contain: lrwxrwxrwx ... c: - #not important lrwxrwxrwx ... l: - /usr/local/ lrwxrwxrwx ... s: - /usr/local/src/ Let top_builddir is /usr/local/src/test, library lib1 in /usr/local/src/test/lib1, and program foo in /usr/local/src/test/appl . In this case c-wrapper program will contain in xxx_PATH_VALUE s:\lib1\.libs . If the mapping s: is removed the program will fail without to be moved physically on build system. Strictly speaking it is moved on host system - now valid path is l:\src\lib1\.libs. That same limitations apply to the binary wrapper executables. Change the wine fstab after you build, and you'll probably break the wrappers. So if the wine developers confirm that run-time translation in not side-effect we may skip winepath and the problem will disappear and will not depend of $WINEPREFIX/dosdevice links. In well setup environment z in link to the root of the filesystems on build. In my test-environment m: is an additional link (to MINGWCROSS) and z: is removed intentionally before tests. But, if I understand your text above correctly, even with no Z: mapping (as long as you have SOME suitable mapping to the build directly), my current proposed patch works. The patch work if exist translation from absolute 'subpath' to build directory to DOSDEVICE, i.e. work if winepath -w top_builddir return DOSPATH c-wrapper. This is in the case when project don't use external shared libraries. If project use external shared libraries, but absolute path on build host cannot' be translated, at link phase libtool output: libtool: link: Could not determine host path corresponding to libtool: link: '/.' libtool: link: Continuing, but uninstalled executables may not work. for all missing paths. So it is fine with me. The check for empty func_to_host_pathlist_result is after path-list translation but all missing path are reported by func_to_host_path. May be this check is extra. The problem I have with echo $val | sed -e 's|:|;|g' is what if, somehow, a dos-style path is in $val? C:\bob - C;\bob May we left the build path cannot contain ':' as limitation of libtool in case of cross-compilation environment ? But that's a rather arbitrary restriction, simply to enable an optimization in the wrapper generation, isn't it? May be if ltmain.m4sh, during creation of dllsearchpath and some other variables, separate items by host system dir-separator the problem will be solved. Oh, boy. I *really* don't know about that: because then the changes we are talking about are no longer isolated to one little corner of libtool, but could propagate everywhere -- and affect other platforms. No, thanks -- in that case, the cure is worse than the disease. P.S.: Also winepath exit with zero(!?!?!?) even if path cannot be translated: == $ winepath -w `pwd`; echo $? Warning: could not find DOS drive for current working directory '/./lt-HEAD-mingw-mlib', starting in the Windows directory. 0 Well, that's just...evil. Is it possible that this is a bug in winepath that should be reported upstream? Surely exit-with-0-on-error is not the *design* behavior, is it? I'm going to have to think hard about how to detect error status...there is a very ugly
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
Charles Wilson wrote:
Roumen Petrov wrote:
[SNIP]
Try replacing the section above with:
* )
# Unfortunately, winepath does not exit with a non-zero
# error code, so we are forced to check the contents of
# stdout. On the other hand, if the command is not
# found, the shell will set an exit code of 127 and print
# *an error message* to stdout. So we must check for both
# error code of zero AND non-empty stdout, which explains
# the odd construction:
func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
func_to_host_path_winepath_exitcode=$?
if test $func_to_host_path_winepath_exitcode -eq 0 \
test -n ${func_to_host_path_tmp1} ; then
func_to_host_path_result=`echo $func_to_host_path_tmp1|\
$SED -e $lt_sed_naive_backslashify`
fi
;;
And let me know if that works better for you.
[SNIP]
Looks good. I may test this weekend.
Roumen
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
Charles Wilson wrote:
Roumen Petrov wrote:
# func_to_host_path arg
[SNIP]
# ARG is the path (on $build) that should be converted to
# the proper representation for $host. The result is stored
@@ -2546,11 +2553,28 @@ func_to_host_path ()
func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
$SED -e $lt_sed_naive_backslashify`
;;
+ * )
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check stderr for an
+# error message. On the other hand, if the command is not
+# found, the shell will set an exit code of 127. So we
+# must check for both, which explains the odd construction:
+func_to_host_path_winepath_stderr=`winepath -w $1
/dev/null 21`
+func_to_host_path_winepath_exitcode=$?
+if test $func_to_host_path_winepath_exitcode -eq 0 \
+ test -z ${func_to_host_path_winepath_stderr} ; then
+ func_to_host_path_tmp1=`winepath -w $1`
+ func_to_host_path_result=`echo
$func_to_host_path_tmp1 |\
+$SED -e $lt_sed_naive_backslashify`
+fi
+;;
[SNIP]
So it winepath fail to convert a build-system path it output only LF
on standard output(stdout).
I cannot confirm that exists relation: 'non-empty' stderr output and
path-translation failure.
My point of view is that check for 'empty' stdout is enough as
indication for translation-failure.
The problem with that is, bash puts the following on stdout -- NOT
stderr -- if it cannot find winepath:
bash: winepath: command not found
So, at the very least, we have failure if either
stdout is empty
or
exit code is nonzero
Try replacing the section above with:
* )
# Unfortunately, winepath does not exit with a non-zero
# error code, so we are forced to check the contents of
# stdout. On the other hand, if the command is not
# found, the shell will set an exit code of 127 and print
# *an error message* to stdout. So we must check for both
# error code of zero AND non-empty stdout, which explains
# the odd construction:
func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
func_to_host_path_winepath_exitcode=$?
if test $func_to_host_path_winepath_exitcode -eq 0 \
test -n ${func_to_host_path_tmp1} ; then
func_to_host_path_result=`echo $func_to_host_path_tmp1|\
$SED -e $lt_sed_naive_backslashify`
fi
;;
And let me know if that works better for you.
[SNIP]
--
Chuck
It seems to me that the patch work with one addition:
func_to_host_path ()
{
func_to_host_path_result=$1
if test -n $1 ; then
case $host in
*mingw* )
func_to_host_path_result= # clean result
lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
case $build in
*mingw* ) # actually, msys
.
Without to clean result we cannot get warning in cross-compilation case
it winepath fail.
Or maybe to clean only in default build case if winepath fail since if
build is mingw/cygwin code always assign value to func_to_host_path_result:
.
func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
func_to_host_path_winepath_exitcode=$?
if test $func_to_host_path_winepath_exitcode -eq 0 \
test -n ${func_to_host_path_tmp1} ; then
func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
$SED -e $lt_sed_naive_backslashify`
else
func_to_host_path_result= # clean result
fi
;;
.
Roumen
