Re: libtool problem
On 2018-06-27 09:44, Roumen Petrov wrote:
Hello Alice,
Alice Wonder wrote:
Hello,
[SNIP]
Software (audacity)
[SNIP]
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
[SNIP]
LIBTOOL=/opt/gnu/bin/libtool
libtool is generated script . Generated script has variable
available_tags= and then inside a number of sections.
audacity consists from many projects. Each project has own
configuration and some of them use libtool.
(1) If you audacity version is vary old try to update all audacity
{sub}projects and check that "autotool"-files are regenerated. Then
remove LIBTOOL variable from environment - project will use own
script.
(2) About /opt/gnu/bin/libtool
It must be generated for this installation environment.
My own build version of libtool 2.4.6 supports:
available_tags='CXX F77 FC GO GCJ RC '
I guest that you lack CXX and result is missing 'tagged configuration'
If you prefer this approach you should rebuild libtool against
compilers installed in /opt/gnu/..., install and check content of
"tagged" sections.
For instance search for 'TAG CONFIG: CXX'. Paths should correspond to
/opt/gnu/... installation.
With other words libtool script is compiler dependent. If installed it
must be refreshed (regenerated) after each update of compilers.
Problem is now resolved.
I was trying to hard - setting environmental variables to let configure
know what was what. Seems *all* I needed to do was set /opt/gnu/bin
first in the $PATH and the existing configure script worked.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem
I think the problem must be with audacity.
I tried building several other packages with the new gcc, including orc
from the GStreamer project that requires libtool to build and I made
sure (in mock buildroot) that only the /opt/gnu/bin/libtool I built was
available - and they compiled, passed test suites, etc.
It's audacity that has a problem - even the older version that builds
with system gcc has same tag error when building against the newer gcc
in /opt/gnu. So something about the macros does not seem to like gcc
installed outside of /usr
autoreconf -fvi results in an error about undefined macros.
aclocal --force -I /opt/gnu/share/aclocal -I m4
autoconf
That results in a configure script but it produces the same tag error.
So I'm going to see if anyone on their list knows what the issue is
because the gcc definitely works, even when autoconf and libtoolize are
needed, in other software.
I'll figure it out, the errors from autoreconf at least give me some
hints as to what in their build scripts may need patching.
Thank you for that tip.
On 2018-06-26 14:51, Robert Boehne wrote:
You are somehow mixing parts of libtool from different versions.
--tag has been required since version 1.5, so some part of what you've
built uses something even older, circa 2002. First, try re-generating
the configury for this project using newish tools. 'autoreconf" might
do it. You may also contact the project for the package you are
trying to build, you might have missed some documentation that may
tell you how to build it.
On Tue, Jun 26, 2018 at 4:09 PM, Alice Wonder
wrote:
Hello,
Very low bandwidth user, my only connection is using my phone as a
hotspot which limits me to ~60 Kbits once I use the very low monthly
allotment (that broadband users usually have used in two days)
I have tried to search web for answers but it is very difficult as
many sites pull in heavy third party resources.
Okay -
Platform: CentOS 7.5 x86_64 building inside of mock (necessary
repositories locally mirrored while borrowing bandwidth from
library, I can keep they rsynced at my slow speed at night so they
are current)
Software (audacity) - older version require insecure dependency EPEL
removed due to its insecurity, building against newer results in GUI
that doesn't work.
Latest version of audacity requires GCC 4.9 or newer.
So I built a GCC 5.5.0 w/ prefix of /opt/gnu - it's built w/o
multilib and with just c,c++,objc,objc++ support (I probably only
need the first two)
With that gcc specified I get this error:
-- terminal output --
gtk/FileDialogPrivate.cpp: In function 'void
gtk_filedialog_ok_callback(GtkWidget*, FileDialog*)':
gtk/FileDialogPrivate.cpp:103:22: warning: ignoring return value of
'int chdir(const char*)', declared with attribute warn_unused_result
[-Wunused-result]
chdir(folder);
^
/bin/sh ./libtool--mode=link g++-L/opt/gnu/lib64 -L/lib64
-L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
libFileDialog_la-FileDialog.lo
gtk/libFileDialog_la-FileDialogPrivate.lo-lgtk-3 -lgdk-3
-latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0
-lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0
-lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0
-lglib-2.0
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
make[2]: *** [libFileDialog.la] Error 1
-- /terminal output --
Looking at http://metastatic.org/text/libtool.html [1] from search
results, I built libtool 2.4.2 (same version CentOS 7 has) rpm from
pristine source but with a prefix of /opt/gnu and I built it using
the gcc 5.5.0 in /opt/gnu
Still get same error when specifying that libtool to audacity
configure.
Looking at audacity, seems they make their own libtool script. I
read it trying to find where the error might be.
Found the line
-- code --
sys_lib_dlsearch_path_spec="/lib /usr/lib /opt/gnu/lib64 "
-- /code --
Now after configure I try this but still get same error:
-- code --
sed -i -e 's?^sys_lib_dlsearch_path_spec="/lib
/usr/lib?sys_lib_dlsearch_path_spec="/lib64 /usr/lib64?g' libtool
-- /code --
I know the gcc 5.5.0 build works, I tested that with simple
echo 'int main(){}' > dummy.c
I do however suspect the error is somewhere on my end. Any
suggestions?
Full environmental variables I'm passing to audacity configure
script:
-- code --
LIBTOOL=/opt/gnu/bin/libtool CC=/opt/gnu/bin/gcc
CXX=/opt/gnu/bin/g++ CPP=/opt/gnu/bin/cpp LDFLAGS="-L/opt/gnu/lib64"
CPPFLAGS="-I/opt/gnu/include"
-- /code --
--
You have to be a deviant or exist in dreary boredom. Make no
mistake; all intellectuals are deviants -- William S. Burroughs
___
https://lists.gnu.org/mailman/listinfo/libtool [2]
Links:
--
[1] http://metastatic.org/text/libtool.html
[2] https://lists.gnu.org/mailman/listinfo/libtool
--
You have to be a deviant or exist in dreary boredom. Make no
Re: libtool problem
You are somehow mixing parts of libtool from different versions. --tag has
been required since version 1.5, so some part of what you've built uses
something even older, circa 2002. First, try re-generating the configury
for this project using newish tools. 'autoreconf" might do it. You may
also contact the project for the package you are trying to build, you might
have missed some documentation that may tell you how to build it.
On Tue, Jun 26, 2018 at 4:09 PM, Alice Wonder wrote:
> Hello,
>
> Very low bandwidth user, my only connection is using my phone as a hotspot
> which limits me to ~60 Kbits once I use the very low monthly allotment
> (that broadband users usually have used in two days)
>
> I have tried to search web for answers but it is very difficult as many
> sites pull in heavy third party resources.
>
> Okay -
>
> Platform: CentOS 7.5 x86_64 building inside of mock (necessary
> repositories locally mirrored while borrowing bandwidth from library, I can
> keep they rsynced at my slow speed at night so they are current)
>
> Software (audacity) - older version require insecure dependency EPEL
> removed due to its insecurity, building against newer results in GUI that
> doesn't work.
>
> Latest version of audacity requires GCC 4.9 or newer.
>
> So I built a GCC 5.5.0 w/ prefix of /opt/gnu - it's built w/o multilib and
> with just c,c++,objc,objc++ support (I probably only need the first two)
>
> With that gcc specified I get this error:
>
>
> -- terminal output --
> gtk/FileDialogPrivate.cpp: In function 'void
> gtk_filedialog_ok_callback(GtkWidget*,
> FileDialog*)':
> gtk/FileDialogPrivate.cpp:103:22: warning: ignoring return value of 'int
> chdir(const char*)', declared with attribute warn_unused_result
> [-Wunused-result]
> chdir(folder);
> ^
> /bin/sh ./libtool--mode=link g++-L/opt/gnu/lib64 -L/lib64
> -L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
> libFileDialog_la-FileDialog.lo gtk/libFileDialog_la-FileDialogPrivate.lo
> -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lgtk-3
> -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0
> libtool: link: unable to infer tagged configuration
> libtool: link: specify a tag with `--tag'
> make[2]: *** [libFileDialog.la] Error 1
> -- /terminal output --
>
> Looking at http://metastatic.org/text/libtool.html from search results, I
> built libtool 2.4.2 (same version CentOS 7 has) rpm from pristine source
> but with a prefix of /opt/gnu and I built it using the gcc 5.5.0 in /opt/gnu
>
> Still get same error when specifying that libtool to audacity configure.
>
> Looking at audacity, seems they make their own libtool script. I read it
> trying to find where the error might be.
>
> Found the line
>
> -- code --
> sys_lib_dlsearch_path_spec="/lib /usr/lib /opt/gnu/lib64 "
> -- /code --
>
> Now after configure I try this but still get same error:
>
> -- code --
> sed -i -e 's?^sys_lib_dlsearch_path_spec="/lib
> /usr/lib?sys_lib_dlsearch_path_spec="/lib64 /usr/lib64?g' libtool
>
> -- /code --
>
> I know the gcc 5.5.0 build works, I tested that with simple
>
> echo 'int main(){}' > dummy.c
>
> I do however suspect the error is somewhere on my end. Any suggestions?
>
> Full environmental variables I'm passing to audacity configure script:
>
> -- code --
> LIBTOOL=/opt/gnu/bin/libtool CC=/opt/gnu/bin/gcc CXX=/opt/gnu/bin/g++
> CPP=/opt/gnu/bin/cpp LDFLAGS="-L/opt/gnu/lib64"
> CPPFLAGS="-I/opt/gnu/include"
> -- /code --
>
>
> --
> You have to be a deviant or exist in dreary boredom. Make no mistake; all
> intellectuals are deviants -- William S. Burroughs
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool
libtool problem
Hello,
Very low bandwidth user, my only connection is using my phone as a
hotspot which limits me to ~60 Kbits once I use the very low monthly
allotment (that broadband users usually have used in two days)
I have tried to search web for answers but it is very difficult as many
sites pull in heavy third party resources.
Okay -
Platform: CentOS 7.5 x86_64 building inside of mock (necessary
repositories locally mirrored while borrowing bandwidth from library, I
can keep they rsynced at my slow speed at night so they are current)
Software (audacity) - older version require insecure dependency EPEL
removed due to its insecurity, building against newer results in GUI
that doesn't work.
Latest version of audacity requires GCC 4.9 or newer.
So I built a GCC 5.5.0 w/ prefix of /opt/gnu - it's built w/o multilib
and with just c,c++,objc,objc++ support (I probably only need the first
two)
With that gcc specified I get this error:
-- terminal output --
gtk/FileDialogPrivate.cpp: In function 'void
gtk_filedialog_ok_callback(GtkWidget*, FileDialog*)':
gtk/FileDialogPrivate.cpp:103:22: warning: ignoring return value of 'int
chdir(const char*)', declared with attribute warn_unused_result
[-Wunused-result]
chdir(folder);
^
/bin/sh ./libtool--mode=link g++-L/opt/gnu/lib64 -L/lib64
-L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
libFileDialog_la-FileDialog.lo gtk/libFileDialog_la-FileDialogPrivate.lo
-lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lgtk-3
-lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
make[2]: *** [libFileDialog.la] Error 1
-- /terminal output --
Looking at http://metastatic.org/text/libtool.html from search results,
I built libtool 2.4.2 (same version CentOS 7 has) rpm from pristine
source but with a prefix of /opt/gnu and I built it using the gcc 5.5.0
in /opt/gnu
Still get same error when specifying that libtool to audacity configure.
Looking at audacity, seems they make their own libtool script. I read it
trying to find where the error might be.
Found the line
-- code --
sys_lib_dlsearch_path_spec="/lib /usr/lib /opt/gnu/lib64 "
-- /code --
Now after configure I try this but still get same error:
-- code --
sed -i -e 's?^sys_lib_dlsearch_path_spec="/lib
/usr/lib?sys_lib_dlsearch_path_spec="/lib64 /usr/lib64?g' libtool
-- /code --
I know the gcc 5.5.0 build works, I tested that with simple
echo 'int main(){}' > dummy.c
I do however suspect the error is somewhere on my end. Any suggestions?
Full environmental variables I'm passing to audacity configure script:
-- code --
LIBTOOL=/opt/gnu/bin/libtool CC=/opt/gnu/bin/gcc CXX=/opt/gnu/bin/g++
CPP=/opt/gnu/bin/cpp LDFLAGS="-L/opt/gnu/lib64"
CPPFLAGS="-I/opt/gnu/include"
-- /code --
--
You have to be a deviant or exist in dreary boredom. Make no mistake;
all intellectuals are deviants -- William S. Burroughs
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem with --whole-archive/--no-whole-archive
On 16 February 2015 at 14:38, Mike Frysinger vap...@gentoo.org wrote: On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote: Problem is, platform linker command doesn't have --whole-archive/--no-whole-archive around the lib. Instead it comes later in the command line. iirc, libtool likes to sort things for you How to propogate the --whole-archive/--no-whole-archive all the way down to example app linking?. Importantly, it should be around the -lmyextlib. I can make changes only at platform/targetA/Makefile.am as example/* is common across all other platforms. Note: Tried libtool's suggestion of -Wl,'-whole-archive -lfoo -no-whole-archive' as mentioned in lists.gnu.org/archive/html/libtool/2002-05/msg00043.html but that didn't work. what do you mean by didn't work ? I meant linker command line didn't come out as I expected. Expectation: -Wl,--whole-archive -lmyextlib -ldl -Wl,--no-whole-archive Output: -lmyextlib -ldl As explained, atleast platform linking has --whole-archive and --no-whole-archive, but examples didn't even had them platform libtool link: -lrt -lcrypto -lmyextlib -ldl -pthread -O2 -pthread -Wl,--whole-archive -Wl,--no-whole-archive example libtool link: -lrt -lcrypto -lmyextlib -ldl -pthread -O2 -pthread maybe quoting is messing you up ? you could try: -Wl,--whole-archive,-lfoo,--no-whole-archive I tried this and didn't get the expected result. -mike ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem with --whole-archive/--no-whole-archive
On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote: Problem is, platform linker command doesn't have --whole-archive/--no-whole-archive around the lib. Instead it comes later in the command line. iirc, libtool likes to sort things for you How to propogate the --whole-archive/--no-whole-archive all the way down to example app linking?. Importantly, it should be around the -lmyextlib. I can make changes only at platform/targetA/Makefile.am as example/* is common across all other platforms. Note: Tried libtool's suggestion of -Wl,'-whole-archive -lfoo -no-whole-archive' as mentioned in lists.gnu.org/archive/html/libtool/2002-05/msg00043.html but that didn't work. what do you mean by didn't work ? maybe quoting is messing you up ? you could try: -Wl,--whole-archive,-lfoo,--no-whole-archive -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool problem with --whole-archive/--no-whole-archive
Hi All, For our project we use automake/libtool automake (GNU automake) 1.14.1 libtool (GNU libtool) 2.4.2 autoconf (GNU Autoconf) 2.69 We have, platform/targetA/Makefile.am platform/targetB/Makefile.am example/*/Makefile.am We wanted to link an external lib wrapped around --whole-archive/--no-whole-archive with the example application as given below, platform/targetA/Makefile.am LIBS += -Wl,--whole-archive LIBS += -lmyextlib LIBS += -Wl,--no-whole-archive Problem is, platform linker command doesn't have --whole-archive/--no-whole-archive around the lib. Instead it comes later in the command line. gcc: -Wl,--whole-archive -lmyextlib -ldl -Wl,--no-whole-archive libtool link: -lrt -lcrypto -lmyextlib -ldl -pthread -O2 -pthread -Wl,--whole-archive -Wl,--no-whole-archive example/*/Makefile.am When compiling the example app, linker command line just has -lmyextlib and doesn't have --whole-archive/--no-whole-archive at all. How to propogate the --whole-archive/--no-whole-archive all the way down to example app linking?. Importantly, it should be around the -lmyextlib. I can make changes only at platform/targetA/Makefile.am as example/* is common across all other platforms. Note: Tried libtool's suggestion of -Wl,'-whole-archive -lfoo -no-whole-archive' as mentioned in lists.gnu.org/archive/html/libtool/2002-05/msg00043.html but that didn't work. Am I missing something here? What I am trying to achieve is completely wrong? Thanks, Venkatesh. ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool problem when cross compiling net-snmp
Hi, I'm trying to cross compile net-snmp here and have same problems as I had 2 years ago(Net-Snmp 5.4.1 and libtool 1.5.24) when I tried this last time. Now i'm trying to cross compile Net-Snmp 5.5 and uses libtool 2.2.6. The mail I sent here and the responseI got last time can be seen here: http://www.mail-archive.com/libtool@gnu.org/msg10002.html This works for the first library libnetsnmp located in the snmplib folder. But for the second library libnetsnmpagent located in another folder(agent) that depends on the first I get this problem. I've tried Ralfs suggestion but it didn't help me. Anyone has any other suggestion for me? When I try Ralfs suggestion it doesn't help. The problem is that the LDFLAGS are added at the end. Before: ++ gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -shared .libs/snmp_agent.o .libs/snmp_vars.o .libs/agent_read_config.o .libs/agent_registry.o .libs/agent_index.o .libs/agent_sysORTable.o .libs/agent_trap.o .libs/kernel.o .libs/agent_handler.o mibgroup/mibII/.libs/vacm_conf.o mibgroup/snmpv3/.libs/usmConf.o mibgroup/agentx/.libs/master.o mibgroup/agentx/.libs/subagent.o mibgroup/utilities/.libs/execute.o mibgroup/utilities/.libs/iquery.o mibgroup/agentx/.libs/protocol.o mibgroup/agentx/.libs/client.o mibgroup/agentx/.libs/master_admin.o mibgroup/agentx/.libs/agentx_config.o -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/usr/lib -lnetsnmp -lcrypto -mlinux -march=v32 -Wl,-soname -Wl,libnetsnmpagent.so.20 -o .libs/libnetsnmpagent.so.20.0.0 /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so: file format not recognized; treating as linker script /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so:5: parse error collect2: ld returned 1 exit status After: ++ gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -shared .libs/snmp_agent.o .libs/snmp_vars.o .libs/agent_read_config.o .libs/agent_registry.o .libs/agent_index.o .libs/agent_sysORTable.o .libs/agent_trap.o .libs/kernel.o .libs/agent_handler.o mibgroup/mibII/.libs/vacm_conf.o mibgroup/snmpv3/.libs/usmConf.o mibgroup/agentx/.libs/master.o mibgroup/agentx/.libs/subagent.o mibgroup/utilities/.libs/execute.o mibgroup/utilities/.libs/iquery.o mibgroup/agentx/.libs/protocol.o mibgroup/agentx/.libs/client.o mibgroup/agentx/.libs/master_admin.o mibgroup/agentx/.libs/agentx_config.o -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/usr/lib -lnetsnmp -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib/ -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib/ -lcrypto -mlinux -march=v32 -Wl,-soname -Wl,libnetsnmpagent.so.20 -o .libs/libnetsnmpagent.so.20.0.0 /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so: file format not recognized; treating as linker script /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so:5: parse error collect2: ld returned 1 exit status Regards, Goran ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
On 12/01/2009 06:04 PM, Jonas Thiem wrote: This topic is rather old, and I'm referring to a particular post which can be found here: http://www.mail-archive.com/libtool@gnu.org/msg03642.html Obviously it isn't possible to link a static lib from a shared lib compiled in libtool as libtool blocks it (technically it would be possible on many, but not all platforms). This affects all platforms including Windows, not just Mac OS X. Robert Boehne suggested some solutions to this: Suggestion 1, you could link to shared libraries rather than archives. Suggestion 2, if you're building it yourself, make the static libs convenience libraries, this will have the same effect as linking to static libs, but is portable. This should work, we changed the dep libs check method to pass_all, if you are using libtool-1.5 (April 2003) or later, you shouldn't see a problem on Mac OS X. Peter -- Peter O'Gorman http://pogma.com For windows targets it doesn't work at all (compiling on a linux machine with i486-mignw32. I'm also pretty sure my libtool version is newer, but I need to recheck when I'm at home and having access to the machine. The only way to link a static lib for a windows target seems to be not to use libtool (given you cannot move to a convenience lib or a shared lib which is the case for a plugin that references back to the main app's symbol file). ___ Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
This topic is rather old, and I'm referring to a particular post which can be found here: http://www.mail-archive.com/libtool@gnu.org/msg03642.html Obviously it isn't possible to link a static lib from a shared lib compiled in libtool as libtool blocks it (technically it would be possible on many, but not all platforms). This affects all platforms including Windows, not just Mac OS X. Robert Boehne suggested some solutions to this: Suggestion 1, you could link to shared libraries rather than archives. Suggestion 2, if you're building it yourself, make the static libs convenience libraries, this will have the same effect as linking to static libs, but is portable. This doesn't cover a special case though which I heard isn't *that* uncommon and which wasn't mentioned in the discussion at all: Sometimes you create plugins/modules which refer back to functions in the main program. On Unix, you can simply do this by unresolved symbols that get resolved to the main program itself at the point when it loads the shared libs. On Windows, where unresolved symbols aren't allowed, I am myself commonly generating a .a symbol file from the main program's symbols and linking it statically from my dlls, which works fine with mingw and also generates perfectly usable dlls. Now with libtool this isn't possible. In my project, that led me to an ugly hack where I'm simply not using libtool for my modules at all when compiling for a windows target. That's a rather unsatisfying solution. It works, but the condition in every Makefile.am of every module that contains both libtool code and manual code just for the windows platform to get it compiled seems rather ugly compared to a much simplier solution: It could much easier be solved by libtool providing a switch to override the blocking of static linking out of shared libs. In my case, that also wouldn't impose a problem to Unix systems not supporting it, as I'd simply use it solely for the Windows platform where the .a link is needed to avoid unresolved symbols. As the problem seems, after 6 years, still unresolved (if I'm wrong please correct me, I'm by no way an expert or even an advanced libtool user), it would be really great if such a flag got introduced: people may use or not use it depending on the target platforms they want to support, or they may even use it only through an optional condition for individual target platforms of which they know that they support static linking out of shared libs to achieve specific things - in my case avoidance of unresolved symbols. This wouldn't cause a loss of compatibility for the average libtool user and provide a considerable amount of less pain in this specific special case. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
On 12/01/2009 06:04 PM, Jonas Thiem wrote: This topic is rather old, and I'm referring to a particular post which can be found here: http://www.mail-archive.com/libtool@gnu.org/msg03642.html Obviously it isn't possible to link a static lib from a shared lib compiled in libtool as libtool blocks it (technically it would be possible on many, but not all platforms). This affects all platforms including Windows, not just Mac OS X. Robert Boehne suggested some solutions to this: Suggestion 1, you could link to shared libraries rather than archives. Suggestion 2, if you're building it yourself, make the static libs convenience libraries, this will have the same effect as linking to static libs, but is portable. This should work, we changed the dep libs check method to pass_all, if you are using libtool-1.5 (April 2003) or later, you shouldn't see a problem on Mac OS X. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
My idea is to put this in one config file at a standard location which can include site specific information. This could include information such as special compile/link flags required for a particular architecture format and expected subdirectory or library file naming. It would list architecture formats which apply for that system. I am also interested to convert the wording from the specification into something where specific default settings can be processed automatically. http://pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL Will it be worth to invite more software developers to proposals and participation in the required modelling of data structures and programming interfaces? Regards, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Tue, 12 May 2009, Markus Elfring wrote: I am also interested to convert the wording from the specification into something where specific default settings can be processed automatically. http://pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL Will it be worth to invite more software developers to proposals and participation in the required modelling of data structures and programming interfaces? It does not seem likely that anything as exotic as data structures and programming interfaces would be required. What is necessary is to get the right people interested. Once the specification is written, and the various popular operating systems start to come with the file, then libtool could start to pay attention to it. Things like this typically take years to accomplish. The FHS was relatively easy to work out since it was based on long-standing conventions established by SunOS in the late '80s and early '90s. A multi-lib architecture description format would be entirely new so someone would need to invent it and propose it to the right group of people to propel it to standard status. An alternative is to follow the approach used by pkg-config and simply show up with the right tool for the job. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
It does not seem likely that anything as exotic as data structures and programming interfaces would be required. What is necessary is to get the right people interested. Would you like to introduce more software developers and designers into the topic for useful discussion of the details? Who will be the right one? Regards, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Tue, 12 May 2009, Markus Elfring wrote: It does not seem likely that anything as exotic as data structures and programming interfaces would be required. What is necessary is to get the right people interested. Would you like to introduce more software developers and designers into the topic for useful discussion of the details? Who will be the right one? There are surely hundreds of such people on this libtool list but the libtool list is not the right place to discuss it. Libtool (and autotools in general) has a long history of dealing with the world as it already exists rather than trying to improve it. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard The same sort of folks who were involved in developing this standard could help with an architecture rules specification format. Did you discuss this idea with any software developers before? Up to now, I have not heard of any efforts to normalize architecture-specific installation or to come up with a specification format to describe it. There are a huge number of options available. For example, some base architectures support may variants and it is useful to support sets of variants which provide broader portability or better performance on particular CPUs. There are also various debug and profiling library formats. How and where should the knowledge about default destination directories be stored? Which tools can be safely used to query the desired informations? Regards, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Mon, 11 May 2009, Markus Elfring wrote: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard The same sort of folks who were involved in developing this standard could help with an architecture rules specification format. Did you discuss this idea with any software developers before? Nope. It just popped into my head. :-) How and where should the knowledge about default destination directories be stored? My idea is to put this in one config file at a standard location which can include site specific information. This could include information such as special compile/link flags required for a particular architecture format and expected subdirectory or library file naming. It would list architecture formats which apply for that system. Which tools can be safely used to query the desired informations? I am not aware of any such tools. Certainly test compiles can be done with various flags to see what the compilation tools are capable of, but the result might not be suitable for the current system. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Sun, 10 May 2009, Markus Elfring wrote: Can the file system hierarchy standard help here? http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard The same sort of folks who were involved in developing this standard could help with an architecture rules specification format. GNU does not strictly follow the FHS although it allows it to be supported. What will the least common denominator look like? Probably some release of Debian Linux. :-) The specification file would need to address OS installed files and be able to specify the rules to use for any particular directory heirarchy. Up to now, I have not heard of any efforts to normalize architecture-specific installation or to come up with a specification format to describe it. There are a huge number of options available. For example, some base architectures support may variants and it is useful to support sets of variants which provide broader portability or better performance on particular CPUs. There are also various debug and profiling library formats. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
Hello Markus, * Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST: I am curious if the libtool software will ever be able to determine the appropriate directory automatically on systems with multiple processor architectures. If you know of a fully automatic way that works, and that not only for your system your distribution your current version, but for strictly more systems, distributions, versions, compilers and compiler versions for which the current method works then we're all ears. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Sat, 9 May 2009, Ralf Wildenhues wrote: * Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST: I am curious if the libtool software will ever be able to determine the appropriate directory automatically on systems with multiple processor architectures. If you know of a fully automatic way that works, and that not only for your system your distribution your current version, but for strictly more systems, distributions, versions, compilers and compiler versions for which the current method works then we're all ears. I think that what is needed is for the community to develop a specification for a simple and easily parsed format and location for a file which defines the architectures that a system supports, and the associated conventions. Systems pre-dating this new convention can be updated by adding the file. A future version of libtool could use this information when searching for files, or when building and installing libraries. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Sat, 9 May 2009, Markus Elfring wrote: Are there any chances to improve the situation on a limited combination of these software components? Yes, of course. Things become much easier if you only plan to solve a subset of the problem. But we should solve the whole problem. Can any default values be added for linker directories because of standard file naming conventions? It would be nice if there were standard file naming conventions. On my Solaris 10 system, the operating system uses one convention and GCC uses another. Packages may use another. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
It would be nice if there were standard file naming conventions. On my Solaris 10 system, the operating system uses one convention and GCC uses another. Packages may use another. Do you see chances for a mapping between the available approaches? Can the file system hierarchy standard help here? http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard What will the least common denominator look like? Regards, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
After some more experimentation, I seem to have found the solution: I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the program to be built. Then, I get the expected behavior (libraries in /usr/lib do not interfere with those in /usr/lib64). Thanks for helping. Regards Bernd ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Mon, 6 Apr 2009, Bernd Speiser wrote: After some more experimentation, I seem to have found the solution: I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the program to be built. Then, I get the expected behavior (libraries in /usr/lib do not interfere with those in /usr/lib64). Thanks for helping. Sorry that I was not of more help. It does seem necessary to specify the linker path to 64-bit libraries on the system. The fixes in libtool 2.2 seem to primarily be to assure that the correct compiler support and system libraries are used. Libtool queries GCC for the built-in linker search path but unfortunately GCC does not adjust its reported path based on the -m64 option so libtool needs to do that. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
Bob Friesenhahn wrote: On Fri, 3 Apr 2009, Bernd Speiser wrote: I am using autotools on openSUSE 11.0 x86_64 where I have a couple of libraries (notably the X libraries) installed as both 32 and 64 bit versions. I seem to have a problem which has been discussed several times on this list (libtool tries to link the 32 bit libraries instead of the 64 bit ones, resulting in a `could not read symbols: File in wrong format' error), however, all the ideas suggested there do not seem to work here. This are the versions of the autotools autoconf: 2.61 automake: 1.10.1 libtool: 1.5.26 It seems that your libtool is out of date. The current release is 2.2.6. It is likely to work better. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Bob, thanks for this info. 1.5.26 is the default for openSUSE 11.0. However, I have installed libtool version 2.2.6 on my system now. With this, after regeneration of of the aclocal.m4 files, I still get an error message, although a different one: libtool: link: cannot find the library `/usr/lib/libXfixes.la' or unhandled argument `/usr/lib/libXfixes.la' Here is the result of a call to `locate libXfixes': /usr/lib/libXfixes.so.3 /usr/lib/libXfixes.so.3.1.0 /usr/lib64/libXfixes.a /usr/lib64/libXfixes.la /usr/lib64/libXfixes.so /usr/lib64/libXfixes.so.3 /usr/lib64/libXfixes.so.3.1.0 So, there still for this library the incorrect path is used. Or am I doing something wrong? Best regards Bernd -- === Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 temporary address: Auf der Morgenstelle 15 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) +49-7071-2972098 (secretary) fax: +49-7071-295518 e-mail: bernd.spei...@uni-tuebingen.de Internet: http://www.uni-tuebingen.de/speiser === ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
On Sun, 5 Apr 2009, Bernd Speiser wrote: thanks for this info. 1.5.26 is the default for openSUSE 11.0. However, I have installed libtool version 2.2.6 on my system now. With this, after regeneration of of the aclocal.m4 files, I still get an error message, although a different one: libtool: link: cannot find the library `/usr/lib/libXfixes.la' or unhandled argument `/usr/lib/libXfixes.la' Here is the result of a call to `locate libXfixes': /usr/lib/libXfixes.so.3 /usr/lib/libXfixes.so.3.1.0 /usr/lib64/libXfixes.a /usr/lib64/libXfixes.la /usr/lib64/libXfixes.so /usr/lib64/libXfixes.so.3 /usr/lib64/libXfixes.so.3.1.0 So, there still for this library the incorrect path is used. Or am I doing something wrong? I expect that the problem is that a .la file loaded via the linking search path refers to this /usr/lib/libXfixes.la file which does not exist (because it was deleted or never was installed). The .la files are just ASCII text files that you can open in a text editor. Check your linking search path (set via LDFLAGS) and see what requested libraries do have a .la file which is refering to the missing /usr/lib/libXfixes.la file. Changing the linker search path might resolve the problem, or the wrong .la file could be manually edited, or even deleting the wrong .la file might help solve the problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem on system with 32 and 64 bit libraries
Bernd Speiser wrote: Bob Friesenhahn wrote: I expect that the problem is that a .la file loaded via the linking search path refers to this /usr/lib/libXfixes.la file which does not exist (because it was deleted or never was installed). The .la files are just ASCII text files that you can open in a text editor. Check your linking search path (set via LDFLAGS) and see what requested libraries do have a .la file which is refering to the missing /usr/lib/libXfixes.la file. Changing the linker search path might resolve the problem, or the wrong .la file could be manually edited, or even deleting the wrong .la file might help solve the problem. Since I couldn't find the wrong .la file (no direct request for libXfixes.la), I used another route: I installed the missing /usr/lib/libXfixes.la from the openSUSE distribution (and also a couple of other X related .la files which were requested). Having done this, I come back to the error message I already had with libtool 1.5.26: /usr/lib/libXi.so: could not read symbols: File in wrong format There are libXi.so in both /usr/lib and /usr/lib64. Would that error message mean that in some of the .la files there is an incorrect reference to the /usr/lib path which needs to be changed into /usr/lib64? Best Regards Bernd -- === Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 temporary address: Auf der Morgenstelle 15 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) +49-7071-2972098 (secretary) fax: +49-7071-295518 e-mail: bernd.spei...@uni-tuebingen.de Internet: http://www.uni-tuebingen.de/speiser === ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool problem on system with 32 and 64 bit libraries
Hi, I am using autotools on openSUSE 11.0 x86_64 where I have a couple of libraries (notably the X libraries) installed as both 32 and 64 bit versions. I seem to have a problem which has been discussed several times on this list (libtool tries to link the 32 bit libraries instead of the 64 bit ones, resulting in a `could not read symbols: File in wrong format' error), however, all the ideas suggested there do not seem to work here. This are the versions of the autotools autoconf: 2.61 automake: 1.10.1 libtool: 1.5.26 acinclude.m4 contains the line # serial 52 AC_PROG_LIBTOOL Here is the output of the link command: /bin/sh ../../../../libtool --tag=CXX --mode=link g++ -O2 -Wuninitialized -funroll-loops -funroll-all-loops -fstrict-aliasing -DBOOST_NO_INTRINSIC_INT64_T -I/usr/lib/qt3/include -D_REENTRANT -DQT_THREAD_SUPPORT -Wall -pedantic-errors -Wno-non-virtual-dtor -Wno-deprecated -Wno-long-long -Wno-strict-aliasing -Wno-parentheses -O2 -Wuninitialized -funroll-loops -funroll-all-loops -fstrict-aliasing -DBOOST_NO_INTRINSIC_INT64_T-o ModSim ModSim-helpWindow.o ModSim-plotWindow.o ModSim-modelMainWindow.o ModSim-equilibriumDialog.o ModSim-mediatorAction.o ModSim-experimentDialogAction.o ModSim-mechanismDialogAction.o ModSim-modelParametersAction.o ModSim-simulationParametersAction.o ModSim-scalingDialogAction.o ModSim-dataDialogAction.o ModSim-solverDialogAction.o ModSim-experimentDialog.o ModSim-helpAboutDialog.o ModSim-textProperties.o ModSim-graphDialog.o ModSim-exportDialog.o ModSim-mechanismDialog.o ModSim-modelParametersDialog.o ModSim-modelPlotWidget.o ModSim-dataDialog.o ModSim-plotMainWindow.o ModSim-simulationParametersDialog.o ModSim-solverDialog.o ModSim-scalingDialog.o ModSim-svmParametersDialog.o ModSim-svmDataDialog.o ModSim-batchExperimentDialog.o ModSim-logger.o ModSim-mediator.o ModSim-main.o ModSim-excitationFunctionDialog.o ModSim-optionsDialog.o ModSim-cvExcitationFunctionDialog.o ModSim-caExcitationFunctionDialog.o ModSim-userDefinedEtExcitationFunctionDialog.o ModSim-userDefinedItExcitationFunctionDialog.o ModSim-helpWindowBase.o ModSim-experimentDialogBase.o ModSim-helpAboutDialogBase.o ModSim-textPropertiesBase.o ModSim-equilibriumDialogBase.o ModSim-graphDialogBase.o ModSim-exportDialogBase.o ModSim-mechanismDialogBase.o ModSim-modelMainWindowBase.o ModSim-modelParametersDialogBase.o ModSim-dataDialogBase.o ModSim-plotMainWindowBase.o ModSim-simulationParametersDialogBase.o ModSim-solverDialogBase.o ModSim-scalingDialogBase.o ModSim-optionsDialogBase.o ModSim-cvExcitationFunctionDialogBase.o ModSim-caExcitationFunctionDialogBase.o ModSim-userDefinedEtExcitationFunctionDialogBase.o ModSim-userDefinedItExcitationFunctionDialogBase.o ModSim-svmParametersDialogBase.o ModSim-svmDataDialogBase.o ModSim-batchExperimentDialogBase.o ModSim-moc_helpWindowBase.o ModSim-moc_helpWindow.o ModSim-moc_graphDialogBase.o ModSim-moc_graphDialog.o ModSim-moc_equilibriumDialogBase.o ModSim-moc_equilibriumDialog.o ModSim-moc_experimentDialogBase.o ModSim-moc_experimentDialog.o ModSim-moc_helpAboutDialogBase.o ModSim-moc_helpAboutDialog.o ModSim-moc_textPropertiesBase.o ModSim-moc_textProperties.o ModSim-moc_exportDialogBase.o ModSim-moc_exportDialog.o ModSim-moc_mechanismDialogBase.o ModSim-moc_mechanismDialog.o ModSim-moc_modelMainWindowBase.o ModSim-moc_modelMainWindow.o ModSim-moc_modelParametersDialogBase.o ModSim-moc_modelParametersDialog.o ModSim-moc_modelPlotWidget.o ModSim-moc_dataDialogBase.o ModSim-moc_dataDialog.o ModSim-moc_plotMainWindowBase.o ModSim-moc_plotMainWindow.o ModSim-moc_simulationParametersDialogBase.o ModSim-moc_simulationParametersDialog.o ModSim-moc_solverDialogBase.o ModSim-moc_solverDialog.o ModSim-moc_scalingDialogBase.o ModSim-moc_scalingDialog.o ModSim-moc_optionsDialogBase.o ModSim-moc_optionsDialog.o ModSim-moc_cvExcitationFunctionDialogBase.o ModSim-moc_cvExcitationFunctionDialog.o ModSim-moc_caExcitationFunctionDialogBase.o ModSim-moc_caExcitationFunctionDialog.o ModSim-moc_userDefinedEtExcitationFunctionDialogBase.o ModSim-moc_userDefinedEtExcitationFunctionDialog.o ModSim-moc_userDefinedItExcitationFunctionDialogBase.o ModSim-moc_userDefinedItExcitationFunctionDialog.o ModSim-moc_svmParametersDialogBase.o ModSim-moc_svmParametersDialog.o ModSim-moc_svmDataDialogBase.o ModSim-moc_svmDataDialog.o ModSim-moc_batchExperimentDialogBase.o ModSim-moc_batchExperimentDialog.o ../../../../../Analysis/Classification/libeppClassification.la ../../../../../Analysis/Data/libeppDataold.la ../../../../../Model/Problem/libeppProblem.la ../../../../../Model/Adapters/libeppAdapters.la ../../../../../Model/Ecco/libeppEcco.la ../../../../../Model/Solvers/libeppSolvers.la ../../../../../Model/Numerics/libeppNumerics.la ../../../../../Experiment/ExcitationFunction/libeppExcitationFunction.la ../../../../../Experiment/Data/libeppData.la ../../../../../Experiment/InputFilters/libeppInputFilters.la
Re: libtool problem on system with 32 and 64 bit libraries
On Fri, 3 Apr 2009, Bernd Speiser wrote: I am using autotools on openSUSE 11.0 x86_64 where I have a couple of libraries (notably the X libraries) installed as both 32 and 64 bit versions. I seem to have a problem which has been discussed several times on this list (libtool tries to link the 32 bit libraries instead of the 64 bit ones, resulting in a `could not read symbols: File in wrong format' error), however, all the ideas suggested there do not seem to work here. This are the versions of the autotools autoconf: 2.61 automake: 1.10.1 libtool: 1.5.26 It seems that your libtool is out of date. The current release is 2.2.6. It is likely to work better. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FreeWRL plugin, libtool problem
Ralf Wildenhues ralf.wildenh...@gmx.de - Mon, 16 Feb 2009 19:39:16
+0100
Hello Michel,
* Michel Briand wrote on Fri, Feb 13, 2009 at 12:34:41PM CET:
I've a grave problem : when I build my Debian package the libtool
install mode was not called. In the resulting package
the /usr/bin/freewrl is not the real binary :
/usr/bin/freewrl: error: `/usr/bin/.libs/freewrl' does not exist
This script is just a wrapper for freewrl.
See the libtool documentation for more information.
I note that libtool complains, and say warning: remember to run
`libtool --finish /usr/lib'. I note that I never hear about this step ;).
It is needed only when using DESTDIR installs. And if omitted, on most
systems there is not a grave problem. For example, Debian typically
takes care to run ldconfig each time it is booted, so that it will then
fix things if you've forgotten about them.
But in general, yes, you need to use finish mode once things have moved
to their final destination.
When I build the .deb in my dev directory (as normal user), all is fine
(libtool install mode is called).
But when I build the .deb with pbuilder (as Debian policy recommends
it), it's not the case.
dh_installdirs
# Install through Make target
/usr/bin/make install DESTDIR=/tmp/buildd/freewrl-1.22.0/debian/freewrl
make[1]: Entering directory `/tmp/buildd/freewrl-1.22.0'
Making install in src
[...]
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'libFreeWRL.la'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la'
libtool: install: /usr/bin/install -c .libs/libFreeWRL.so.1.22.0
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.so.1.22.0
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib {
ln -s -f libFreeWRL.so.1.22.0 libFreeWRL.so.1 || { rm -f libFreeWRL.so.1
ln -s libFreeWRL.so.1.22.0 libFreeWRL.so.1; }; })
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib {
ln -s -f libFreeWRL.so.1.22.0 libFreeWRL.so || { rm -f libFreeWRL.so ln
-s libFreeWRL.so.1.22.0 libFreeWRL.so; }; })
libtool: install: /usr/bin/install -c .libs/libFreeWRL.lai
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la
libtool: install: warning: remember to run `libtool --finish /usr/lib'
[...]
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/bin'
test -z /usr/bin || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'freewrl'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl'
libtool: install: warning: `../../src/lib/libFreeWRL.la' has not been
installed in `/usr/lib'
libtool: install: warning: cannot relink `freewrl'
libtool: install: /usr/bin/install -c freewrl
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl
[...]
Ah, this is a problem. Can you try configuring with
--enable-fast-install? Also, can you post the output of
/bin/sh ../../libtool --config
so we can see what hardcoding properties your system has?
Also I assume that src/bin/freewrl is a shell script? If so, then that
looks like a bug.
Thanks,
Ralf
Hello,
I identified the problem. Or I think I've do ;).
If I remove --disable-fast-install from default configure options
then the DESTDIR will be correctly supported by libtool and the final
binary will be finished in my chrooted environment (pbuilder).
There is still a problem with make distcheck but I'll post about this
later.
Regards,
Michel
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FreeWRL plugin, libtool problem
Hello Michel,
* Michel Briand wrote on Fri, Feb 13, 2009 at 12:34:41PM CET:
I've a grave problem : when I build my Debian package the libtool
install mode was not called. In the resulting package
the /usr/bin/freewrl is not the real binary :
/usr/bin/freewrl: error: `/usr/bin/.libs/freewrl' does not exist
This script is just a wrapper for freewrl.
See the libtool documentation for more information.
I note that libtool complains, and say warning: remember to run
`libtool --finish /usr/lib'. I note that I never hear about this step ;).
It is needed only when using DESTDIR installs. And if omitted, on most
systems there is not a grave problem. For example, Debian typically
takes care to run ldconfig each time it is booted, so that it will then
fix things if you've forgotten about them.
But in general, yes, you need to use finish mode once things have moved
to their final destination.
When I build the .deb in my dev directory (as normal user), all is fine
(libtool install mode is called).
But when I build the .deb with pbuilder (as Debian policy recommends
it), it's not the case.
dh_installdirs
# Install through Make target
/usr/bin/make install DESTDIR=/tmp/buildd/freewrl-1.22.0/debian/freewrl
make[1]: Entering directory `/tmp/buildd/freewrl-1.22.0'
Making install in src
[...]
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'libFreeWRL.la'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la'
libtool: install: /usr/bin/install -c .libs/libFreeWRL.so.1.22.0
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.so.1.22.0
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib {
ln -s -f libFreeWRL.so.1.22.0 libFreeWRL.so.1 || { rm -f libFreeWRL.so.1
ln -s libFreeWRL.so.1.22.0 libFreeWRL.so.1; }; })
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib {
ln -s -f libFreeWRL.so.1.22.0 libFreeWRL.so || { rm -f libFreeWRL.so ln -s
libFreeWRL.so.1.22.0 libFreeWRL.so; }; })
libtool: install: /usr/bin/install -c .libs/libFreeWRL.lai
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la
libtool: install: warning: remember to run `libtool --finish /usr/lib'
[...]
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/bin'
test -z /usr/bin || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'freewrl'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl'
libtool: install: warning: `../../src/lib/libFreeWRL.la' has not been
installed in `/usr/lib'
libtool: install: warning: cannot relink `freewrl'
libtool: install: /usr/bin/install -c freewrl
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl
[...]
Ah, this is a problem. Can you try configuring with
--enable-fast-install? Also, can you post the output of
/bin/sh ../../libtool --config
so we can see what hardcoding properties your system has?
Also I assume that src/bin/freewrl is a shell script? If so, then that
looks like a bug.
Thanks,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FreeWRL plugin, libtool problem
Hi all, I've a grave problem : when I build my Debian package the libtool install mode was not called. In the resulting package the /usr/bin/freewrl is not the real binary : /usr/bin/freewrl: error: `/usr/bin/.libs/freewrl' does not exist This script is just a wrapper for freewrl. See the libtool documentation for more information. Any idea ? Michel Ralf Wildenhues ralf.wildenh...@gmx.de - Thu, 12 Feb 2009 19:28:17 +0100 Hello Michel, * Michel Briand wrote on Thu, Feb 12, 2009 at 03:41:42PM CET: plugin_LTLIBRARIES = libFreeWRLplugin.la plugindir=$(PLUGIN_DIR) # configure puts in it /usr/lib/mozilla/plugins libFreeWRLplugin_la_LDFLAGS = -avoid-version $(AM_LDFLAGS) This produces the following command line: /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o libFreeWRLplugin.la -rpath /usr/lib/mozilla/plugins plugin_main.lo npunix.lo internal_version.lo libtool: link: gcc -shared .libs/plugin_main.o .libs/npunix.o .libs/internal_version.o -Wl,-soname -Wl,libFreeWRLplugin.so -o .libs/libFreeWRLplugin.so Why -rpath /usr/lib/mozilla/plugins ??? Quoting '(libtool.info.gz)Link mode': | `-rpath LIBDIR' | If OUTPUT-FILE is a library, it will eventually be installed in | LIBDIR. If OUTPUT-FILE is a program, add LIBDIR to the run-time | path of the program. It seems weird, and it is, but somebody chose '-rpath' to have this rather unusual meaning for libtool. The rpath troubles me. I think that rpath would be use to specify library path needed by the shared object. Not the path where it is supposed to be installed. Am I right ? Not in this case; you are thinking about the ld option -rpath, typically passed to compilers as -Wl,-rpath,... But that's not what the above means to libtool, at least not in the case of creating a library. It does not cause /usr/lib/mozilla/plugins to be added to the run path of the library. Hope that helps. I haven't read the rest, so if there were more questions hidden there, please ping. Cheers, Ralf -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FreeWRL plugin, libtool problem
Build log, this may help ;).
I note that libtool complains, and say warning: remember to run
`libtool --finish /usr/lib'. I note that I never hear about this step ;).
When I build the .deb in my dev directory (as normal user), all is fine
(libtool install mode is called).
But when I build the .deb with pbuilder (as Debian policy recommends
it), it's not the case.
Any clue ?
Cheers,
Michel
dh_installdirs
# Install through Make target
/usr/bin/make install DESTDIR=/tmp/buildd/freewrl-1.22.0/debian/freewrl
make[1]: Entering directory `/tmp/buildd/freewrl-1.22.0'
Making install in src
make[2]: Entering directory `/tmp/buildd/freewrl-1.22.0/src'
Making install in lib
make[3]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/lib'
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/lib'
test -z /usr/lib || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'libFreeWRL.la'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la'
libtool: install: /usr/bin/install -c .libs/libFreeWRL.so.1.22.0
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.so.1.22.0
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib { ln
-s -f libFreeWRL.so.1.22.0 libFreeWRL.so.1 || { rm -f libFreeWRL.so.1 ln -s
libFreeWRL.so.1.22.0 libFreeWRL.so.1; }; })
libtool: install: (cd /tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib { ln
-s -f libFreeWRL.so.1.22.0 libFreeWRL.so || { rm -f libFreeWRL.so ln -s
libFreeWRL.so.1.22.0 libFreeWRL.so; }; })
libtool: install: /usr/bin/install -c .libs/libFreeWRL.lai
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/libFreeWRL.la
libtool: install: warning: remember to run `libtool --finish /usr/lib'
test -z /usr/include || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/include
/usr/bin/install -c -m 644 'libFreeWRL.h'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/include/libFreeWRL.h'
test -z /usr/lib/pkgconfig || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/pkgconfig
/usr/bin/install -c -m 644 'libFreeWRL.pc'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/pkgconfig/libFreeWRL.pc'
make[4]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/lib'
make[3]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/lib'
Making install in bin
make[3]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/bin'
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/bin'
test -z /usr/bin || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'freewrl'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl'
libtool: install: warning: `../../src/lib/libFreeWRL.la' has not been installed
in `/usr/lib'
libtool: install: warning: cannot relink `freewrl'
libtool: install: /usr/bin/install -c freewrl
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/bin/freewrl
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/bin'
make[3]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/bin'
Making install in plugin
make[3]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/plugin'
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src/plugin'
make[4]: Nothing to be done for `install-exec-am'.
test -z /usr/lib/mozilla/plugins || /bin/mkdir -p
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/mozilla/plugins
/bin/sh ../../libtool --mode=install /usr/bin/install -c
'libFreeWRLplugin.la'
'/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/mozilla/plugins/libFreeWRLplugin.la'
libtool: install: /usr/bin/install -c .libs/libFreeWRLplugin.so
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/mozilla/plugins/libFreeWRLplugin.so
libtool: install: /usr/bin/install -c .libs/libFreeWRLplugin.lai
/tmp/buildd/freewrl-1.22.0/debian/freewrl/usr/lib/mozilla/plugins/libFreeWRLplugin.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/mozilla/plugins'
make[4]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/plugin'
make[3]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src/plugin'
make[3]: Entering directory `/tmp/buildd/freewrl-1.22.0/src'
make[4]: Entering directory `/tmp/buildd/freewrl-1.22.0/src'
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src'
make[3]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src'
make[2]: Leaving directory `/tmp/buildd/freewrl-1.22.0/src'
make[2]: Entering directory `/tmp/buildd/freewrl-1.22.0'
make[3]: Entering directory `/tmp/buildd/freewrl-1.22.0'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/tmp/buildd/freewrl-1.22.0'
make[2]: Leaving directory `/tmp/buildd/freewrl-1.22.0'
make[1]: Leaving directory `/tmp/buildd/freewrl-1.22.0'
Michel Briand michelbri...@free.fr - Fri, 13 Feb 2009
Fw: FreeWRL plugin, libtool problem
Hello Ralf, we are discussing rpath and libtool with the FreeWRL plugin for Firefox. Basically the plugin will use some symbols from Firefox (X) and will fork to load the FreeWRL binary. I'd have compiled it naturally with gcc -shared. But using libtool in the project top configure.ac make it's use project wide... I dont know to use/don't use libtool in subdirectories. On Debian package mailing list and on DejaVu Libre mailing list similar discussion occurred. How to design build a browser plugin ?. Anyway with the proper definitions in Makefile.am I'm compiling the plugin. --- plugin_LTLIBRARIES = libFreeWRLplugin.la plugindir=$(PLUGIN_DIR) # configure puts in it /usr/lib/mozilla/plugins libFreeWRLplugin_la_LDFLAGS = -avoid-version $(AM_LDFLAGS) #include sources... --- This produces the following command line: /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -avoid-version-o libFreeWRLplugin.la -rpath /usr/lib/mozilla/plugins plugin_main.lo npunix.lo internal_version.lo libtool: link: gcc -shared .libs/plugin_main.o .libs/npunix.o .libs/internal_version.o -Wl,-soname -Wl,libFreeWRLplugin.so -o .libs/libFreeWRLplugin.so Why -rpath /usr/lib/mozilla/plugins ??? The rpath troubles me. I think that rpath would be use to specify library path needed by the shared object. Not the path where it is supposed to be installed. Am I right ? Cheers, Michel - Message Transféré - Date: Tue, 10 Feb 2009 11:14:40 -0500 De: Ian Stakenvicius, Aerobiology Research i...@aerobiology.ca À: Michel Briand michelbri...@free.fr Cc: John A. Stewart alex.stew...@crc.ca Sujet: Re: FreeWRL plugin, libtool problem To elaborate further: From my research, rpath is absolutely required to use libtool, and rpath is supposed to be set to the final (installed) destination path of the library file. So because of that, I believe that libtool is doing exactly the right thing by using the value of @plugindir@ for -rpath. Secondly, my goal for --with-plugindir is to provide the exact same functionality that --bindir / --libdir / --datadir / etc.. flags provide within configure and the build system as a whole. Those variables are defined directly as 'libdir','bindir',etc. and are assigned via AC_SUBST (see /usr/share/autoconf/acgeneral.m4 for more info). By default, these values contain variables substitutable by MAKE to handle changes in prefix or exec-prefix on the command line during installation. Further to this, by specifying '[something]_LTLIBRARIES' in a Makefile.am, autotools automatically uses @[something]dir@ as the installation directory as well as -rpath. So, because of these things, the easiest and most autotools-complete way of setting the plugin directory seems to be: plugindir=\$(libdir)/mozilla/plugins AC_SUBST([plugindir]) ...and use plugin_LTLIBRARIES (and not plugindir all over again) in /src/plugin/Makefile.am Although it's not necessarily dependent on prefix, I believe the plugin path _is_ dependent on LIBDIR. Some systems use /usr/lib, and I've seen some use /usr/lib32 or /usr/lib64. And mozilla/firefox/etc. would be installed in these as well. Since mozilla's plugins directory is going to be built in LIBDIR too, I think it would be a more general approach to provide a substitutable default path than to assign it directly to what 32-bit Debian/Ubuntu uses. I hope the above makes sense and covers all of the issues Michel touched on. Ian Ian Stakenvicius, Aerobiology Research wrote: I specifically wanted to use \$(libdir)/mozilla/plugins so that the plugindir, like libdir/bindir/datadir/etc., would be modifyable according to a $prefix change during make install. This is why I had to use AC_SUBST instead of AC_DEFINE_DIR, so that the literal $(libdir) would be transferred to the eventual Makefile instead of a substitution. Also, if in configure.ac we define plugindir directly, we do not have to define it again in Makefile.am (it'll be picked up properly automatically), which is how it's working now. Ian Michel Briand wrote: Ian Stakenvicius, Aerobiology Research i...@aerobiology.ca - Fri, 06 Feb 2009 12:34:32 -0500 REALLY sorry about this -- the issue was that I used the wrong name in the AC_ARG_WITH code for --with-plugindir. I've fixed it in CVS. Note -- in order for $prefix to be substituted properly, I had to use AC_SUBST instead of AC_DEFINE_DIR. Ian Hello Ian, your first solution was the good one :). In fact autotools are complex and specially libtool ;) and we often mess up with them ;). But don't discourage, we'll more and more knowledgeable about them in the times to come. The solution is to get user specified directory or detect it automatically for the place where the plugin should be installed. Defining the PLUGIN_DIR variable with configure enable us to use that variable in the Makefile.am. Just one mistake: don't forget that configure.ac use the Shell syntax, not the Make syntax
Re: Fw: FreeWRL plugin, libtool problem
Hello Michel, * Michel Briand wrote on Thu, Feb 12, 2009 at 03:41:42PM CET: plugin_LTLIBRARIES = libFreeWRLplugin.la plugindir=$(PLUGIN_DIR) # configure puts in it /usr/lib/mozilla/plugins libFreeWRLplugin_la_LDFLAGS = -avoid-version $(AM_LDFLAGS) This produces the following command line: /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o libFreeWRLplugin.la -rpath /usr/lib/mozilla/plugins plugin_main.lo npunix.lo internal_version.lo libtool: link: gcc -shared .libs/plugin_main.o .libs/npunix.o .libs/internal_version.o -Wl,-soname -Wl,libFreeWRLplugin.so -o .libs/libFreeWRLplugin.so Why -rpath /usr/lib/mozilla/plugins ??? Quoting '(libtool.info.gz)Link mode': | `-rpath LIBDIR' | If OUTPUT-FILE is a library, it will eventually be installed in | LIBDIR. If OUTPUT-FILE is a program, add LIBDIR to the run-time | path of the program. It seems weird, and it is, but somebody chose '-rpath' to have this rather unusual meaning for libtool. The rpath troubles me. I think that rpath would be use to specify library path needed by the shared object. Not the path where it is supposed to be installed. Am I right ? Not in this case; you are thinking about the ld option -rpath, typically passed to compilers as -Wl,-rpath,... But that's not what the above means to libtool, at least not in the case of creating a library. It does not cause /usr/lib/mozilla/plugins to be added to the run path of the library. Hope that helps. I haven't read the rest, so if there were more questions hidden there, please ping. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem with library dependencies on ppc64
On 7-Nov-08, at 12:47 PM, Maynard Johnson wrote: Peter, I installed the same distro on a 32-bit Intel machine today and got the same problem. So my hunch that this was a 64bit-only problem was wrong. To restate the question . . . When only a libbfd.a is available for linking (i.e., no libbfd.so), should libtool be smart enough to figure out that it should look for libz.a? As I mentioned below, when I experimented with passing in a binutils install directory to oprofile's configure (resulting in -Lbinutils-install- dirlib added to LDFLAGS), then libtool was able to figure that it should the -lz to its link command. So the problem only happens when the libraries in question are in their default install locations. Sorry I did not get back to you. Unless there is a .la file for the .a archive, libtool will have no idea what libraries the .a archive requires. Since there does not seem to be a libfd.la, you will have to add -lz. Peter Thanks. -Maynard Maynard Johnson wrote: Hello, Peter, I've run into another problem with building the oprofile project that seems like it might be an issue with libtool. Recent versions of binutils have made libbfd dependent on libz (biniutilis 2.18.91 for sure . . . maybe earlier). I added a configure check in oprofile to handle this. Initially, the only way I had to verify this change was by installing the newer version of binutils in /usr/ local and configuring oprofile with --with-binutils to point to that. The new check for libz seemed to work fine in that situation. Recently, I've been working on a POWER6 system that has a new distro beta installed on it, and it came with the updated binutils. (By the way, this new distro defaults to 64-bit, and I currently have only the 64-bit development environment installed. I think this fact is key.) Unfortunately, the oprofile project does not build on this platform. With both binutils and binutils-devel rpms installed, what I see in /usr/lib64 is the following: libbfd-2.18.91.20080917.so libbfd.a So our oprofile build needs to statically link with libbfd.a. When I try to build oprofile, the failure I get is as follows: +++ [EMAIL PROTECTED]:~/temp/oprof-cvs-2008.10.15/opjitconv make /bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common - Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after- statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/ libutil.a -lbfd -liberty -ldl /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/ libbfd.a(compress.o):(.text+0x128): undefined reference to `inflateInit_' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/ libbfd.a(compress.o):(.text+0x150): undefined reference to `inflateReset' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/ libbfd.a(compress.o):(.text+0x184): undefined reference to `inflate' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/ libbfd.a(compress.o):(.text+0x1b4): undefined reference to `inflateEnd' collect2: ld returned 1 exit status make: *** [opjitconv] Error 1 The undefined references are all from libz (as libbfd now has a dependency on it). If I simply manually add the '-lz' to the end of the libtool command, then libtool generates the following link command, and it runs successfully: libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after- statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/ libutil.a -lbfd -liberty -ldl -lz As an experiment, I removed the installed BFD libraries and built a binutils 2.18 (cvs snapshot from September) and installed it in my home directory. I then tried an oprofile build from scratch, specifying the --with-binutils option. The build ran successfully. here is the libtool command (and the link command it generates) that corresponds to the above: [EMAIL PROTECTED]:~/oprof-cvs-2008.10.15/opjitconv make /bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common - Wdeclaration-after-statement -Werror -g -O2 -I/home/mpj/binutils- install-2-18//include -L/home/mpj/binutils-install-2-18//lib64 - Xlinker -R -Xlinker /home/mpj/binutils-install-2-18//lib64 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: warning: library `/home/mpj/binutils-install-2-18// lib64/libbfd.la' was moved. libtool: link: warning: library `/home/mpj/binutils-install-2-18// lib64/libbfd.la' was moved. libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after- statement -Werror -g -O2
Re: libtool problem with library dependencies on ppc64
Maynard Johnson wrote: Hello, Peter, I've run into another problem with building the oprofile project that seems like it might be an issue with libtool. Recent versions of binutils have made libbfd I forgot to mention that the libtool version being used in my situation is 2.2.6. Thanks. -Maynard dependent on libz (biniutilis 2.18.91 for sure . . . maybe earlier). I added a configure check in oprofile to handle this. Initially, the only way I had to verify this change was by installing the newer version of binutils in /usr/local and configuring oprofile with --with-binutils to point to that. The new check for libz seemed to work fine in that situation. Recently, I've been working on a POWER6 system that has a new distro beta installed on it, and it came with the updated binutils. (By the way, this new distro defaults to 64-bit, and I currently have only the 64-bit development environment installed. I think this fact is key.) Unfortunately, the oprofile project does not build on this platform. With both binutils and binutils-devel rpms installed, what I see in /usr/lib64 is the following: libbfd-2.18.91.20080917.so libbfd.a So our oprofile build needs to statically link with libbfd.a. When I try to build oprofile, the failure I get is as follows: +++ [EMAIL PROTECTED]:~/temp/oprof-cvs-2008.10.15/opjitconv make /bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x128): undefined reference to `inflateInit_' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x150): undefined reference to `inflateReset' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x184): undefined reference to `inflate' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x1b4): undefined reference to `inflateEnd' collect2: ld returned 1 exit status make: *** [opjitconv] Error 1 The undefined references are all from libz (as libbfd now has a dependency on it). If I simply manually add the '-lz' to the end of the libtool command, then libtool generates the following link command, and it runs successfully: libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl -lz As an experiment, I removed the installed BFD libraries and built a binutils 2.18 (cvs snapshot from September) and installed it in my home directory. I then tried an oprofile build from scratch, specifying the --with-binutils option. The build ran successfully. here is the libtool command (and the link command it generates) that corresponds to the above: [EMAIL PROTECTED]:~/oprof-cvs-2008.10.15/opjitconv make /bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -I/home/mpj/binutils-install-2-18//include -L/home/mpj/binutils-install-2-18//lib64 -Xlinker -R -Xlinker /home/mpj/binutils-install-2-18//lib64 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: warning: library `/home/mpj/binutils-install-2-18//lib64/libbfd.la' was moved. libtool: link: warning: library `/home/mpj/binutils-install-2-18//lib64/libbfd.la' was moved. libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -I/home/mpj/binutils-install-2-18//include -Wl,-R -Wl,/home/mpj/binutils-install-2-18//lib64 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o -L/home/mpj/binutils-install-2-18//lib64 ../libutil/libutil.a /home/mpj/binutils-install-2-18//lib64/libbfd.a -lz -liberty -ldl +++ Notice that libtool added the -lz to the link command in this case. So, it seems to me that passing in a -L to indicate an alternative binutils dir provides libtool with enough info to figure out it needed to add the -lz. Is it a bug that it can't figure this out when it should link with the default /usr/lib64/libbfd.a? Sorry for the length of this message. Thanks in advance for any help. Regards, -Maynard Johnson ___
Another libtool problem with 64-bit build on a bi-arch system
Hi, Peter, I posted to this list last winter regarding some problems I was having integrating libtool into a project (the oprofile project) -- in particular, building 64-bit on a bi-arch system (IBM POWER5). You helped with some usage problems and also provided a fix in libtool 1.5.26. Now I'm trying to use libtool in another project and having what looks like the exact symptom I started out with in the oprofile project last winter. Here are the details: - libtool 1.5.26 installed in /usr/local - removed existing aclocal.m4 in project root directory - ran 'libtoolize --automake' and 'aclocal -I /usr/local/share/aclocal' from project root directory (now see # serial 52 AC_PROG_LIBTOOL in aclocal.m4) - run configure and make. The make fails as shown below: + [EMAIL PROTECTED]:~/SLES11_new/BUILD/Dpiperf/src/a2n /bin/sh ../../libtool --tag=CC --mode=link gcc -I../../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DDEBUG -DAUTOMAKE -fPIC -shared -g -O2 -m64 -o liba2n.la -rpath /usr/lib64 -version-info 11:0:0 liba2n_la-a2n.lo liba2n_la-a2nint.lo liba2n_la-initterm.lo liba2n_la-linuxsyms.lo liba2n_la-linuxelf.lo liba2n_la-linuxelf64.lo liba2n_la-linuxmap.lo liba2n_la-linuxval.lo liba2n_la-saveres.lo liba2n_la-util.lo -lbfd -liberty -ldl gcc -shared .libs/liba2n_la-a2n.o .libs/liba2n_la-a2nint.o .libs/liba2n_la-initterm.o .libs/liba2n_la-linuxsyms.o .libs/liba2n_la-linuxelf.o .libs/liba2n_la-linuxelf64.o .libs/liba2n_la-linuxmap.o .libs/liba2n_la-linuxval.o .libs/liba2n_la-saveres.o .libs/liba2n_la-util.o /usr/lib/libbfd.so -liberty -ldl -m64 -Wl,-soname -Wl,liba2n.so.11 -o .libs/liba2n.so.11.0.0 /usr/lib/libbfd.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status + On this ppc64 system I'm developing on, the 64-bit BFD library is located in /usr/lib64, but as you can see from above, the gcc command is specifying /usr/lib/libbfd.so, which is the 32-bit library. Any idea what could be the problem? Thanks much for the help. -Maynard Johnson ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Another libtool problem with 64-bit build on a bi-arch system
Maynard Johnson wrote: Hi, Peter, I posted to this list last winter regarding some problems I was having integrating libtool into a project (the oprofile project) -- in particular, building 64-bit on a bi-arch system (IBM POWER5). You helped with some usage problems and also provided a fix in libtool 1.5.26. Now I'm trying to use libtool in another project and having what looks like the exact symptom I started out with in the oprofile project last winter. Here are the details: - libtool 1.5.26 installed in /usr/local - removed existing aclocal.m4 in project root directory - ran 'libtoolize --automake' and 'aclocal -I /usr/local/share/aclocal' from project root directory (now see # serial 52 AC_PROG_LIBTOOL in aclocal.m4) - run configure and make. The make fails as shown below: + [EMAIL PROTECTED]:~/SLES11_new/BUILD/Dpiperf/src/a2n /bin/sh ../../libtool --tag=CC --mode=link gcc -I../../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DDEBUG -DAUTOMAKE -fPIC -shared -g -O2 -m64 -o liba2n.la -rpath /usr/lib64 -version-info 11:0:0 liba2n_la-a2n.lo liba2n_la-a2nint.lo liba2n_la-initterm.lo liba2n_la-linuxsyms.lo liba2n_la-linuxelf.lo liba2n_la-linuxelf64.lo liba2n_la-linuxmap.lo liba2n_la-linuxval.lo liba2n_la-saveres.lo liba2n_la-util.lo -lbfd -liberty -ldl gcc -shared .libs/liba2n_la-a2n.o .libs/liba2n_la-a2nint.o .libs/liba2n_la-initterm.o .libs/liba2n_la-linuxsyms.o .libs/liba2n_la-linuxelf.o .libs/liba2n_la-linuxelf64.o .libs/liba2n_la-linuxmap.o .libs/liba2n_la-linuxval.o .libs/liba2n_la-saveres.o .libs/liba2n_la-util.o /usr/lib/libbfd.so -liberty -ldl -m64 -Wl,-soname -Wl,liba2n.so.11 -o .libs/liba2n.so.11.0.0 /usr/lib/libbfd.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status + By passing in LDFLAGS=-L/usr/lib64 to ./configure, I was able to get the project to build. This technique works with either libtool 1.5.22 or 1.5.26. Seems like a hack, though. I don't have to do this for the oprofile project, so I suspect I'm missing something here. Thanks. -Maynard On this ppc64 system I'm developing on, the 64-bit BFD library is located in /usr/lib64, but as you can see from above, the gcc command is specifying /usr/lib/libbfd.so, which is the 32-bit library. Any idea what could be the problem? Thanks much for the help. -Maynard Johnson ___ http://lists.gnu.org/mailman/listinfo/libtool
Mingw libtool problem
Hi, I've been trying to build guile (v. 1.8.4) scheme interpreter under mingw-win32. I'm using libtool-1.5.8. During compilation, I get the following error message: make[3]: Entering directory `/home/maciek/guile-1.8.4/libguile' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I..-g -O2 -Wall -Wmissing-prototypes -Werror -MT guile-guile.o -MD -MP -MF .deps/guile-guile.Tpo -c -o guile-guile.o `test -f 'guile.c' || echo './'`guile.c mv -f .deps/guile-guile.Tpo .deps/guile-guile.Po /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Werror -dlpreopen force -o guile.exe guile-guile.o libguile.la -lgmp -lws2_32 -lm -lltdl libtool: link: not configured to extract global symbols from dlpreopened files gcc -g -O2 -Wall -Wmissing-prototypes -Werror @SYMFILE@ -o guile.exe guile-guile.o -Wl,--export-dynamic ./.libs/libguile.a -lgmp -lws2_32 -lltdl gcc.exe: @SYMFILE@: No such file or directory Do you know how any workaround for that? (ie. how to configure libtool to extract global symbols from dlpreopened files) Please help! Best regards, Maciek Godek ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Mingw libtool problem
Hi Maciek, * Maciek Godek wrote on Tue, Apr 22, 2008 at 03:22:46PM CEST: I've been trying to build guile (v. 1.8.4) scheme interpreter under mingw-win32. I'm using libtool-1.5.8. During compilation, I get the following error message: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Werror -dlpreopen force -o guile.exe guile-guile.o libguile.la -lgmp -lws2_32 -lm -lltdl libtool: link: not configured to extract global symbols from dlpreopened files gcc -g -O2 -Wall -Wmissing-prototypes -Werror @SYMFILE@ -o guile.exe guile-guile.o -Wl,--export-dynamic ./.libs/libguile.a -lgmp -lws2_32 -lltdl gcc.exe: @SYMFILE@: No such file or directory Interesting. I suppose it didn't set NM properly (or global_symbol_pipe is empty for some reason). Please look at ../libtool --config for these two variables (or just post the whole thing). Also check ./configure output and config.log for things that look unusual. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: libtool problem when cross compiling net-snmp
Thank you for your response. Attached are the logs you asked for. libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib. /Goran -Original Message- From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] Sent: Wed 1/9/2008 8:51 PM To: Göran Hillebrink Cc: libtool@gnu.org Subject:Re: libtool problem when cross compiling net-snmp Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: I'm trying to cross compile net-snmp but have run into a libtool problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. I've tracked down the problem to archive_cmds in libtool. The $deplibs parameter indicates -L/usr/lib instead of -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib. Not sure whether I can help you, but could you please run this command manually with --debug added right after `../libtool': (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh ../libtool --mode=relink gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -Wall -Os -g -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo agent_index.lo agent_trap.lo kernel.lo agent_handler.lo mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu) and this added at the end log-snmp-cross-relink 21 gzip log-snmp-cross-relink and post log-snmp-cross-relink.gz as well as the output of ../libtool --config ? Further, where is the cris libc located on your system? Thanks, Ralf log-snmp-cross-relink.gz Description: log-snmp-cross-relink.gz log-snmp-cross-relink-config.gz Description: log-snmp-cross-relink-config.gz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem when cross compiling net-snmp
* Göran Hillebrink wrote on Thu, Jan 10, 2008 at 10:17:31AM CET: Attached are the logs you asked for. libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib. Thanks. So this is indeed the same issue as Mike Frysinger described in http://lists.gnu.org/archive/html/libtool/2007-12/msg00084.html. So far I can only suggest a workaround that may work for you. You could try building with make LDFLAGS=-L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool problem when cross compiling net-snmp
Hi, I'm trying to cross compile net-snmp but have run into a libtool problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. I've tracked down the problem to archive_cmds in libtool. The $deplibs parameter indicates -L/usr/lib instead of -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib. Has anyone experinced this problem or can point me where to find a solution to this problem? Regards, Goran libtool: install: warning: relinking `libnetsnmpagent.la' (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh ../libtool --mode=relink gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -Wall -Os -g -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo agent_index.lo agent_trap.lo kernel.lo agent_handler.lo mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu) gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -shared .libs/snmp_agent.o .libs/snmp_vars.o .libs/agent_read_config.o .libs/agent_registry.o .libs/agent_index.o .libs/agent_trap.o .libs/kernel.o .libs/agent_handler.o mibgroup/utilities/.libs/execute.o mibgroup/mibII/.libs/vacm_conf.o mibgroup/snmpv3/.libs/usmConf.o -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/usr/lib -lnetsnmp -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -mlinux -march=v32 -Wl,-soname -Wl,libnetsnmpagent.so.15 -o .libs/libnetsnmpagent.so.15.1.0 /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so: file format not recognized; treating as linker script /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so:5: parse error collect2: ld returned 1 exit status libtool: install: error: relink `libnetsnmpagent.la' with the above command before installing it installing libnetsnmpagent.la in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib PATH=$PATH:/sbin ldconfig -n /usr/lib The wrapper file for net-snmp i'm using looks like this: AXIS_USABLE_LIBS = UCLIBC GLIBC include $(AXIS_TOP_DIR)/tools/build/Rules.axis SRCDIR= src LDFLAGS += -L$(prefix)/usr/lib CPPFLAGS += -I$(prefix)/usr/include CFLAGS := `echo $(CFLAGS)|sed 's/-Wshadow//'` CFLAGS += -I$(prefix)/usr/include INSTMODE = 0755 INSTOWNER = root INSTGROUP = root INST_PROG = $(AXIS_TOP_DIR)/tools/build/bin/$(shell echo $(INSTALL)|sed 's/^ *//') test: @echo CC: $(CC) @echo CFLAGS: $(CFLAGS) @echo LD: $(LD) @echo LDFLAGS: $(LDFLAGS) @echo INSTALL: $(INSTALL) @echo INST_PROG: $(INST_PROG) @echo RANLIB: $(RANLIB) $(SRCDIR)/Makefile: cd $(SRCDIR) \ ./configure \ --target=$(AXIS_BUILDTYPE) \ --host=$(AXIS_BUILDTYPE) \ --prefix=/usr \ --with-ar=$(AR) \ --with-cc=$(CC) \ --with-cflags=$(CFLAGS) \ --with-ld=$(LD) \ --with-ldflags=$(LDFLAGS) \ --with-install-prefix=$(prefix) \ --disable-applications \ --disable-debugging \ --disable-embedded-perl \ --disable-manuals \ --disable-mibs \ --disable-mib-loading \ --disable-scripts \ --disable-snmpv1 \ --enable-mini-agent \ --enable-reentrant \ --enable-shared \ --with-default-snmp-version=3 \ --with-endianness=little \ --with-logfile=/var/log/snmpd.log \ --with-openssl=$(prefix) \ --with-mib-modules=mibII ip-mib tcp-mib \ --with-persistent-directory=/var/net-snmp \ --without-perl-modules \ --without-root-access \ --without-rpm \ STRIP=$(STRIP) \ INSTALL=$(INST_PROG) RM=$(RM) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem when cross compiling net-snmp
Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: I'm trying to cross compile net-snmp but have run into a libtool problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. I've tracked down the problem to archive_cmds in libtool. The $deplibs parameter indicates -L/usr/lib instead of -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib. Not sure whether I can help you, but could you please run this command manually with --debug added right after `../libtool': (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh ../libtool --mode=relink gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -Wall -Os -g -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo agent_index.lo agent_trap.lo kernel.lo agent_handler.lo mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu) and this added at the end log-snmp-cross-relink 21 gzip log-snmp-cross-relink and post log-snmp-cross-relink.gz as well as the output of ../libtool --config ? Further, where is the cris libc located on your system? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: A minor libtool problem
Hi Peter, Sorry for the long delay. * Peter Breitenlohner wrote on Tue, Mar 28, 2006 at 05:05:43PM CEST: When building packages using libtool there frequently are (lots of) warnings such as (edited to avoid overlong lines): libtool: link: warning: \ `/usr/lib/gcc/ix86-linux-gnu/3.4.5/../../..//libgmodule-2.0.la' \ seems to be moved whereas in fact /usr/lib/gcc/ix86-linux-gnu/3.4.5/../../.. is the same as /usr/lib where libgmodule-2.0.la was installed. Would it be possible to avoid this noise by checking that the two paths are actually the same Hmm. (or maybe that's already in the CVS)? No, that is not fixed. The problem with fixing this is that the warning is trivial albeit a bit runtime-expensive to fix, for example with the patch below[1], but the underlying problems these non-normalized paths cause are much more difficult to fix. Consider what should happen with an rpath entry, if that path happens not to be not one of the default-searched ones? What if then that path does not exist yet (which may very well be the case)? How do you go about cross compilation, or a DESTDIR install? If the path does not exist, then path normalization is very difficult or impossible to do. So, even if in the case you are seeing this was easy to fix, we are actually just hiding the fact that there is more trouble we are just not thinking of at the moment. So no, I don't think it is a good idea to apply this patch. Cheers, Ralf Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.125 diff -u -r1.334.2.125 ltmain.in --- ltmain.in 20 Mar 2006 20:41:11 - 1.334.2.125 +++ ltmain.in 28 Mar 2006 16:07:33 - @@ -2930,7 +2930,10 @@ $echo $modename: \`$deplib' is not a valid libtool archive 12 exit $EXIT_FAILURE fi - if test $absdir != $libdir; then + if test $absdir != $libdir ( + wd_abs=`(cd $absdir pwd) 2/dev/null || echo /nowhere1` + wd_lib=`(cd $libdir pwd) 2/dev/null || echo /nowhere2` + test $wd_abs != $wd_lib ); then $echo $modename: warning: \`$deplib' seems to be moved 12 fi path=$absdir ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
A minor libtool problem
There is a longstanding minor libtool problem: When building packages using libtool there frequently are (lots of) warnings such as (edited to avoid overlong lines): libtool: link: warning: \ `/usr/lib/gcc/ix86-linux-gnu/3.4.5/../../..//libgmodule-2.0.la' \ seems to be moved whereas in fact /usr/lib/gcc/ix86-linux-gnu/3.4.5/../../.. is the same as /usr/lib where libgmodule-2.0.la was installed. Would it be possible to avoid this noise by checking that the two paths are actually the same (or maybe that's already in the CVS)? regards Peter Breitenlohner [EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Libtool problem with shared lib in non-standard directory
Hi, I orginally posted this http://lists.gnu.org/archive/html/bug-libtool/2006-01/msg1.html mail to the [EMAIL PROTECTED] It seems to be a bug in libtool. Hence, I will try to provide some extra information. I have a package Common that (optionally) uses the 3rd party package Boost.Threads (and log4cplus). Another package Blob depends on Common. Whenever I try to run the test (using make check) on the Blob test programs I get an error while loading shared libraries For some reason libtool does not add a -Wl,-rpath on the link line $ automake --version automake (GNU automake) 1.9.5 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ libtool --version ltmain.sh (GNU libtool) 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ --version g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. After succesfully building and installing the Common package the libtool library contains the following ... $ cat /home/loose/LOFAR/installed/gnu_debug/lib/libcommon.la # libcommon.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libcommon.a' # Libraries that this one depends upon. dependency_libs=' -R/usr/local/log4cplus/gnu/lib -R/usr/local/boost/gnu/lib -L/usr/local/log4cplus/gnu/lib -L/usr/local/boost/gnu/lib /home/loose/LOFAR/installed/gnu_debug/lib/libshmem.la /usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.la -lpthread -lrt -lboost_thread-gcc-mt' # Version information for libcommon. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/loose/LOFAR/installed/gnu_debug/lib' Note that -R /usr/local/boost/gnu/lib is clearly present in the dependency_libs. Continuing to build the Blob package ... . After a successful build of this package, the libtool library contains the following ... $ cat /home/loose/LOFAR/LCS/Blob/build/gnu_debug/src/libblob.la # libblob.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libblob.a' # Libraries that this one depends upon. dependency_libs=' -R/usr/local/log4cplus/gnu/lib -R/home/loose/LOFAR/installed/gnu_debug/lib -R/usr/local/boost/gnu/lib -L/usr/local/log4cplus/gnu/lib -L/home/loose/LOFAR/installed/gnu_debug/lib /usr/local/log4cplus/gnu/lib/liblog4cplus.la /home/loose/LOFAR/installed/gnu_debug/lib/libcommon.la -L/usr/local/boost/gnu/lib /home/loose/LOFAR/installed/gnu_debug/lib/libshmem.la /usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.la -lpthread -lrt -lboost_thread-gcc-mt' # Version information for libblob. current=0 age=0 revision=0 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/loose/LOFAR/installed/gnu_debug/lib' Again, -R/usr/local/boost/gnu/lib is present in the dependency libs. However, when trying to run any of the test programs (using make check) I get errors like: ./tKeyValueMap: error while loading shared libraries: libboost_thread-gcc-mt-1_32.so.1.32.0: cannot open shared object file: No such file or directory So, what does the link line look like. For this, I deleted tKeyValueMap and rebuild (i.e. relinked it) it by running make in the test directory. $ cd /home/loose/LOFAR/LCS/Blob/build/gnu_debug/test make tKeyValueMap /bin/sh ../libtool --tag=CXX --mode=link /usr/bin/g++ -g -W -Wall -Woverloaded-virtual -Wno-unknown-pragmas -pthread -L/usr/local/log4cplus/gnu/lib -R/usr/local/log4cplus/gnu/lib -L/home/loose/LOFAR/installed/gnu_debug/lib -R/home/loose/LOFAR/installed/gnu_debug/lib -o tKeyValueMap tKeyValueMap.o
Re: Libtool problem with shared lib in non-standard directory
Hi Marcel,
* Marcel Loose wrote on Thu, Jan 26, 2006 at 11:07:02AM CET:
I have a package Common that (optionally) uses the 3rd party package
Boost.Threads (and log4cplus). Another package Blob depends on
Common. Whenever I try to run the test (using make check) on the
Blob test programs I get an error while loading shared libraries
For some reason libtool does not add a -Wl,-rpath on the link
line
*snip*
Note that -R /usr/local/boost/gnu/lib is clearly present in the
dependency_libs.
Continuing to build the Blob package ... . After a successful build
of this package, the libtool library contains the following ...
$ cat /home/loose/LOFAR/LCS/Blob/build/gnu_debug/src/libblob.la
*snip*
Again, -R/usr/local/boost/gnu/lib is present in the dependency libs.
However, when trying to run any of the test programs (using make
check) I get errors like:
./tKeyValueMap: error while loading shared libraries:
libboost_thread-gcc-mt-1_32.so.1.32.0: cannot open shared object file: No
such file or directory
So, what does the link line look like. For this, I deleted
tKeyValueMap and rebuild (i.e. relinked it) it by running make in the
test directory.
Could you also show the link line for creating libblob.la plus libtool
output, and if it is relinked upon installation, also the same from the
relink step (that happens upon `make install' of libblob.la)? I think I
should be able to create a test to reproduce this, with that information.
As can be seen, libtool uses ../src/libblob.la on the link line. So,
if my understanding of how libtool should work is correct, then
libtool should add the -R /usr/local/boost/gnu/lib, translating this
into something -Wl, --rpath,/usr/local/boost/gnu/lib. This, however,
does not happen, as can be clearly seen from the expanded command line
above., and ldd proves that something is wrong.
This analysis seems correct to me.
Note to self: `-R' handling needs to be revisited for the indirect
deplibs issue, and your setup may be one good test case.
$ ldd tKeyValueMap
liblog4cplus.so.2 =
/usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.so.2 (0x40017000)
libpthread.so.0 = /lib/tls/libpthread.so.0 (0x4007f000)
librt.so.1 = /lib/librt.so.1 (0x4008c000)
libboost_thread-gcc-mt-1_32.so.1.32.0 = not found
libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x4009f000)
libm.so.6 = /lib/tls/libm.so.6 (0x40152000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40174000)
libc.so.6 = /lib/tls/libc.so.6 (0x4200)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
Usually, to prevent LD_LIBRARY_PATH or similar from cloaking the
picture, it is better to look at the output of all of
objdump -p tKeyValueMap
ldd tKeyValueMap
eval echo $`libtool --config | sed -n /^shlibpath_var=/{
s,,,
p
}`
(the last is portable speak for
echo $LD_LIBRARY_PATH
).
For your problem, above information is sufficient, but for my note
above, it is not.
Am I missing something here, or is this a bug???
Probable bug. I found this
http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00110.html
which may be related (but probably it's not the right place to fix
this).
Cheers,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool problem with shared lib in non-standard directory
* Marcel Loose wrote on Thu, Jan 26, 2006 at 11:07:02AM CET:
I have a package Common that (optionally) uses the 3rd party package
Boost.Threads (and log4cplus). Another package Blob depends on
Common. Whenever I try to run the test (using make check) on the
Blob test programs I get an error while loading shared libraries
For some reason libtool does not add a -Wl,-rpath on the link
line
Confirmed, testcase below.
Note also behavior and documentation differ in another way: for the second
library, the run-time path is actually added, cf. libtool.info:
| `-R LIBDIR'
| If OUTPUT-FILE is a program, add LIBDIR to its run-time path. If
| OUTPUT-FILE is a library, add `-RLIBDIR' to its DEPENDENCY_LIBS,
| so that, whenever the library is linked into a program, LIBDIR
| will be added to its run-time path.
Cheers,
Ralf
# 1. install a non-libtool library liba in some directory
# 2. create libtool library libb (to be installed somewhere else),
#depending on liba, with -R added suitably
# 3. create program depending on libb
: ${LIBTOOL=libtool}
: ${CC=gcc}
LDFLAGS=$LDFLAGS -no-undefined
libdir_a=`pwd`/inst_a
libdir_b=`pwd`/inst_b
rm -rf src $libdir_a $libdir_b
mkdir src $libdir_a $libdir_b
cd src
echo 'int a() { return 0; }' a.c
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la -rpath $libdir_a a.lo
$LIBTOOL --mode=install cp liba.la $libdir_a/liba.la
$LIBTOOL --mode=clean rm -f liba.la
rm -f $libdir_a/liba.la
echo 'extern int a(); int b() { return a(); }' b.c
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c b.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libb.la -rpath $libdir_b \
b.lo -L$libdir_a -la -R$libdir_a
echo 'extern int b(); int main() { return b(); }' m.c
$CC $CPPFLAGS $CFLAGS -c m.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m m.o libb.la
./m
cd ..
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool problem
I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. Pango first generates libpango.so, Then it generates another library libpangox.so that links to libpango.so. shared library list: ./.libs/libpango.so libX11.so.1 libc.so.1 as you see from the above it links to ./.libs/libpango.so. This has caused lot of problem. Is this the result when libpangox.so is created or *after* it is installed? What matters is the result after installation. No, this is the result before libpangox.so installed. Then it is correct. I take your point, But some packages ( such as pango , gtk+2, ... ) are building library first, and then they use that library to build an executable. In a cases such as above programs, the program will fail to build the executables in compile time. Even before they get to install phase. Run 'make install' and you'll see that libtool relinks the binaries/libraries so the end result is ok. I've built GTK+ 2.2.x fine on HP-UX 11.00 and 11i. Sorry my fault. I 've got a patch that I used to use it with the old version of libtool, to take the version number of the libraries. It seem the patch breaks the new version of configure and libtool. It is very annoying to have the version number with the shared libraries. Thanks __Mehdi Thanks ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool problem
Hi This is a general question, although I am going to refer to a specific paltform and specific program. I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. Pango first generates libpango.so, Then it generates another library libpangox.so that links to libpango.so. shared library list: ./.libs/libpango.so libX11.so.1 libc.so.1 as you see from the above it links to ./.libs/libpango.so. This has caused lot of problem. Which part of libtool controls ./ in linking time?? If it is possible I want to replace ./ with absolute path, or change ./.libs/libpango.so to libpango.so. Any help is appreciated. Thanks __Mehdi ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool problem
On Fri, Jul 25, 2003 at 10:27:58AM +0100, M. Lavasani wrote: This is a general question, although I am going to refer to a specific paltform and specific program. I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. Pango first generates libpango.so, Then it generates another library libpangox.so that links to libpango.so. shared library list: ./.libs/libpango.so libX11.so.1 libc.so.1 as you see from the above it links to ./.libs/libpango.so. This has caused lot of problem. Is this the result when libpangox.so is created or *after* it is installed? What matters is the result after installation. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
Does a convenience library have to be part of your own package? I've looked through the libtool manual and cannot find anything about convenience libraries, a pointer to a reference would be greatly appreciated. If it must be part of your own build, it would be nearly impossible to convert all of OpenSSL over to use autoconf/automake/libtool, just so I could statically link it into another shared object (Especially on OS X as there's no telling when Apple is going to release a fix for the latest openssl vulnerability, or go to the openssl 0.9.7a series so that we can take advantage of AES or eliptic curve algoths) Anyhow, the way we currently do it (linking against static libraries to create a module/shared lib), works on: Linux (ppc, x86) [need to test alpha sparc, but I have the hw to do so] FreeBSD (x86) SCO (OpenServer5 Unixware7) AIX (4.3.3) [have not tested on 5.x yet] Solaris (sparc x86) OpenBSD (x86) The only remaining major platforms that I have not tested on are Tru64 (which is Alpha, and you said PIC doesn't matter there), Irix, and HP-UX (PA-RISC ia64) What happens if these platforms prove to be immune to this as well. Why would it not be a good thing to do? Perhaps I'm naive, but seems like maybe this is a deprecated concern? Anyhow, the real point is that IT DOES WORK if you link by hand, but LibTool doesn't support it. And those other platforms that it does work on (which is all in my exp), LibTool also works on, therefore it is a divergence from behavior of the other platforms. Though it might not be the good thing to do, I'm more concerned with what works in practice, as in theory isn't always the best thing to implement. -Brad Robert Boehne wrote: Brad, You are correct that all PPC code is pic, so is Alpha. Still, that doesn't mean that this behavior is portable, nor does it mean that building a shared lib from a static archive is a good thing to do. Your software will be better off if it does not depend on archive libraries being PIC, and from your end this is easy to work around by using convenience libraries. If Libtool allowed this then you would have never learned why you shouldn't do it. That is precisely why it operates this way. If I recall correctly, you build a convenience library by not specifying -static nor -rpath on Libtool's link line. Automake also has support for convenience libraries built in. HTH, Robert Brad House wrote: Ok, I've put some thought into this over the weekend, and I think it should be classified as a BUG. The argument you put up about library compiled as PIC is irrelevant on PPC. Here's a snippet from the libtool manual: (http://www.gnu.org/software/libtool/manual.html#FOOT11) All code compiled for the PowerPC and RS/6000 chips (powerpc-*-*, powerpcle-*-*, and rs6000-*-*) is position-independent, regardless of the operating system or compiler suite. So, regular objects can be used to build shared libraries on these systems and no special PIC compiler flags are required. And MACOSX is PPC! We have this same package compiling on Linux, FreeBSD, OpenBSD, AIX, SCO OpenServer/Unixware and this behavior diverges from ALL of those, therefore it should be classified as a bug. -Brad Bob Friesenhahn wrote: Many/most operating systems require that anything linked into a shared library be compiled as PIC. The only way that libtool can be sure that the code in a library is compiled as PIC is if it is also a shared library. Some system linkers will reject linking against static libraries when building a shared library. Modules are usually shared libraries themselves so they observe the rules for building shared libraries. This is a libtool feature rather than a bug. There are system-dependent ways that libtool could work around this problem for many systems, but it would be a lot of work to implement. Bob On Sun, 23 Feb 2003, Brad House wrote: Seems to be a bug in libtool 1.4.3 when linking a module if you want to use symbols out of an archive. For example, inside of a package that uses autoconf/automake/libtool, a command executes: /bin/sh ../libtool --mode=link gcc -g -O2 -o module_ssl.la -rpath \ /usr/local/lib -module -avoid-version module_ssl_la-module_ssl.lo \ /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a This message appears: *** Warning: Trying to link with static lib archive /usr/local/ssl/lib/libcrypto.a. *** 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 the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not used here. And does NOT link against libssl.a or libcrypto.a But when I: gcc -O2 -fno-common -flat_namespace -bundle -undefined suppress \ -o module_ssl.so module_ssl.c /usr/local/ssl/lib/libcrypto.a \ /usr/local/ssl/lib/libssl.a This module links perfectly, and is fully
Re: MacOSX module linking with static archive libtool problem
Brad, A convenience library is usually part of your own package, it turns into a list of object files when you link to it. It could be in a subdirectory, much like libltdl is for many packages that use it. Here is a section of the manual that mentions them: http://www.gnu.org/software/libtool/manual.html#SEC14 Even when the archive contains only PIC, there are sometimes extra flags that have to be passed, like -full_archive (IIRC) to get all of the object files into the target. That means if you depend on using some part of an archive you're linking against that isn't used by the object files you're linking into the shared lib, those symbols won't appear in your shared library. Some linkers will link all the archive's objects, some won't, and you won't find out until your software is in the field. That's bad. In the list of platforms you give below, I think that HPUX is probably the most picky about PIC objects. I had a hell of a time once when Autoconf would find a static version of a system library (and therefore add it in) but it wasn't PIC, and my shared library builds died when it tried to link it. If your archive is built by someone else, you won't know if it is PIC or not, unless you happen to be on a platform where that's all there is. If OpenSSL is designed to be static only, then it probably should be linked only to executables. There may be some security advantages to NOT having OpenSSL code in a shared lib, and by making one you may open up a vulnerabiltiy. In the end, we can't support linking archives into shared libs because it isn't portable. This has been discussed before on this list, so perhaps my predecessors were a bit more elegant in presenting their arguments. You may want to search the archives for past discussions on this topic. Thanks, Robert Boehne Brad House wrote: Does a convenience library have to be part of your own package? I've looked through the libtool manual and cannot find anything about convenience libraries, a pointer to a reference would be greatly appreciated. If it must be part of your own build, it would be nearly impossible to convert all of OpenSSL over to use autoconf/automake/libtool, just so I could statically link it into another shared object (Especially on OS X as there's no telling when Apple is going to release a fix for the latest openssl vulnerability, or go to the openssl 0.9.7a series so that we can take advantage of AES or eliptic curve algoths) Anyhow, the way we currently do it (linking against static libraries to create a module/shared lib), works on: Linux (ppc, x86) [need to test alpha sparc, but I have the hw to do so] FreeBSD (x86) SCO (OpenServer5 Unixware7) AIX (4.3.3) [have not tested on 5.x yet] Solaris (sparc x86) OpenBSD (x86) The only remaining major platforms that I have not tested on are Tru64 (which is Alpha, and you said PIC doesn't matter there), Irix, and HP-UX (PA-RISC ia64) What happens if these platforms prove to be immune to this as well. Why would it not be a good thing to do? Perhaps I'm naive, but seems like maybe this is a deprecated concern? Anyhow, the real point is that IT DOES WORK if you link by hand, but LibTool doesn't support it. And those other platforms that it does work on (which is all in my exp), LibTool also works on, therefore it is a divergence from behavior of the other platforms. Though it might not be the good thing to do, I'm more concerned with what works in practice, as in theory isn't always the best thing to implement. -Brad Robert Boehne wrote: Brad, You are correct that all PPC code is pic, so is Alpha. Still, that doesn't mean that this behavior is portable, nor does it mean that building a shared lib from a static archive is a good thing to do. Your software will be better off if it does not depend on archive libraries being PIC, and from your end this is easy to work around by using convenience libraries. If Libtool allowed this then you would have never learned why you shouldn't do it. That is precisely why it operates this way. If I recall correctly, you build a convenience library by not specifying -static nor -rpath on Libtool's link line. Automake also has support for convenience libraries built in. HTH, Robert Brad House wrote: Ok, I've put some thought into this over the weekend, and I think it should be classified as a BUG. The argument you put up about library compiled as PIC is irrelevant on PPC. Here's a snippet from the libtool manual: (http://www.gnu.org/software/libtool/manual.html#FOOT11) All code compiled for the PowerPC and RS/6000 chips (powerpc-*-*, powerpcle-*-*, and rs6000-*-*) is position-independent, regardless of the operating system or compiler suite. So, regular objects can be used to build shared libraries on these systems and no special PIC compiler flags are required. And MACOSX is PPC! We have this same
Re: MacOSX module linking with static archive libtool problem
Thanks for your reply. Do you happen to know a flag or something I can send to libtool to force it to go ahead and link against the library? Basically, we compile on Linux, FreeBSD, SCO OpenServer/Unixware, Solaris 89, AIX and all of those work fine. Any suggestions other than totally ripping libtool out? Thanks. -Brad Bob Friesenhahn wrote: Many/most operating systems require that anything linked into a shared library be compiled as PIC. The only way that libtool can be sure that the code in a library is compiled as PIC is if it is also a shared library. Some system linkers will reject linking against static libraries when building a shared library. Modules are usually shared libraries themselves so they observe the rules for building shared libraries. This is a libtool feature rather than a bug. There are system-dependent ways that libtool could work around this problem for many systems, but it would be a lot of work to implement. Bob On Sun, 23 Feb 2003, Brad House wrote: Seems to be a bug in libtool 1.4.3 when linking a module if you want to use symbols out of an archive. For example, inside of a package that uses autoconf/automake/libtool, a command executes: /bin/sh ../libtool --mode=link gcc -g -O2 -o module_ssl.la -rpath \ /usr/local/lib -module -avoid-version module_ssl_la-module_ssl.lo \ /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a This message appears: *** Warning: Trying to link with static lib archive /usr/local/ssl/lib/libcrypto.a. *** 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 the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not used here. And does NOT link against libssl.a or libcrypto.a But when I: gcc -O2 -fno-common -flat_namespace -bundle -undefined suppress \ -o module_ssl.so module_ssl.c /usr/local/ssl/lib/libcrypto.a \ /usr/local/ssl/lib/libssl.a This module links perfectly, and is fully loadable within my main program. Any assistance here would be greatly appreciated. I'd really rather not link against .dylib's as especially for SSL, I use 0.9.7a, and don't want to overwrite the dylibs Apple provides in /usr/lib, and the linker NEVER wants to link against the right dyamic version. -Brad ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
MacOS X libtool problem with non-standard libobjc
It appears that libtool 1.4.3 implicitly assumes that any App containing Objective-C code must be linked against the system (Apple) libobjc. This stuffs up projects like Swarm or GNUstep which use non-Apple runtimes which include a libobjc. The problem is that regardless of where the object file containing the main() function appears on the libtool command line, libtool will create a link instruction placing it ahead of any -Lsomepaths. When the linker(ld) encounters the object file containing main(), if that object file includes Objective-C code, it will be linked against the system libobjc. Any '-Lpathtomylibobjc -lobjc' type flags further down the command line are just ignored even though there were undefined symbols in the first link. In order to work -Lpathtomylibobjc must precede any object files containing Objective-C on the ld command line. Libtool 'as is' prevents this! Even LD_LIBRARY_PATH variables don't seem to help. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take 3]
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) libtool --mode=clean does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already
took care of.
3) lt-foo.c actually passes its own arguments to the shell wrapper -- it
didn't, before. (Oops)
libtool regression tests: no new failures (on cygwin)
briefly tested on another project; worked fine.
Binary packages for cygwin (libtool-devel-20030103-4,
libltdl3-20030103-4) available by pointing setup.exe at
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
--Chuck
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.318
diff -u -r1.318 ltmain.in
--- ltmain.in 1 Jan 2003 01:57:47 - 1.318
+++ ltmain.in 13 Jan 2003 04:48:39 -
@@ -4284,6 +4284,207 @@
outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
*) exeext= ;;
esac
+ case $host in
+ *cygwin* | *mingw* )
+ cwrappersource=`echo ${objdir}/lt-${output}.c`
+ cwrapper=`echo ${output}.exe`
+ $rm $cwrappersource $cwrapper
+ trap $rm $cwrappersource $cwrapper; exit 1 1 2 15
+
+ cat $cwrappersource EOF
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+ Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+ The $output program cannot be directly executed until all the libtool
+ libraries that it depends on are installed.
+
+ This wrapper executable should never be moved out of the build directory.
+ If it is, it will not operate correctly.
+
+ Currently, it simply execs the wrapper *script* /bin/sh $output,
+ but could eventually absorb all of the scripts functionality and
+ exec $objdir/$outputname directly.
+*/
+EOF
+ cat $cwrappersourceEOF
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include malloc.h
+#include stdarg.h
+#include assert.h
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+ defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+(((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+ if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+ char **newargz;
+ int i;
+
+ program_name = (char *) xstrdup ((char *) basename (argv[0]));
+ newargz = XMALLOC(char *, argc+2);
+ newargz[0] = xstrdup(/bin/sh);
+ newargz[1] = fnqualify(argv[0]);
+ /* we know the script has the same name, without the .exe */
+ /* so make sure newargz[1] doesn't end in .exe */
+ strendzap(newargz[1],.exe);
+ for (i = 1; i argc; i++)
+newargz[i+1] = xstrdup(argv[i]);
+ newargz[argc+1] = NULL;
+ execv(/bin/sh,newargz);
+}
+
+void *
+xmalloc (size_t num)
+{
+ void * p = (void *) malloc (num);
+ if (!p)
+lt_fatal (Memory exhausted);
+
+ return p;
+}
+
+char *
+xstrdup (const char *string)
+{
+ return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+ const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ /* Skip over the disk name in MSDOS pathnames. */
+ if (isalpha (name[0]) name[1] == ':')
+name += 2;
+#endif
+
+ for (base = name; *name; name++)
+if (IS_DIR_SEPARATOR (*name))
+ base = name + 1;
+ return (char *) base;
+}
+
+char *
+fnqualify(const char *path)
+{
+ size_t size;
+ char *p;
+ char tmp[LT_PATHMAX + 1];
+
+ assert(path != NULL);
+
+ /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ if (isalpha (path[0]) path[1] == ':')
+return xstrdup (path);
+#endif
+ if (IS_DIR_SEPARATOR (path[0]))
+return xstrdup (path);
+
+ /* prepend the current directory */
+ /* doesn't handle '~' */
+ if (getcwd (tmp, LT_PATHMAX) == NULL)
+lt_fatal (getcwd failed);
+ size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+ p = XMALLOC(char, size);
+ sprintf(p, %s%c%s, tmp,
Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take3]
Earnie Boyd wrote: This patch passes my test. What do we need to do to get this accepted into libtool cvs HEAD? + newargz[0] = xstrdup(/bin/sh); This may not be the shell and there is no point allocating it. It is fine to use it from static memory. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take3]
Bruce Korb wrote: Earnie Boyd wrote: This patch passes my test. What do we need to do to get this accepted into libtool cvs HEAD? + newargz[0] = xstrdup(/bin/sh); This may not be the shell and there is no point allocating it. It is fine to use it from static memory. Okay, the second comment (use static string, not allocated memory) is easy enough. But what's the best way to use the shell? Do a unquoted replacement (EOF, not EOF) e.g. ... newargz = XMALLOC(char *, argc+2); EOF $echo $cwrappersource EOF newargz[0] = \$SHELL\; EOF $echo $cwrappersource EOF newargz[1] = fnqualify(argv[0]); ... ? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[Fwd: libtool problem with linking .a's]
"Tim" == Tim Heath [EMAIL PROTECTED] writes: TimI am getting the message: Tim libtool: link: cannot build libtool library `liboracle.la' from Tim non-libtool objects: /opt/oracle/X/product/8.1.6/lib/libcore8.a Tim Does anyone know how to fix this? I recommend asking on the libtool list, `[EMAIL PROTECTED]'. My guess is that libtool prevents this because on some architectures you cannot put random .o files into a shared library -- on such architectures the .o files must be specially built (eg with PIC). Tom
