Re: libtool versioning
Hi Ralf Bob, On 03/05/2010 19:58, Ralf Wildenhues wrote: Hello, * Matěj Týč wrote on Mon, May 03, 2010 at 05:45:26PM CEST: If I have understood correctly, the whole LTversion stuff has only one purpose - to inform users what have they installed. Wrong. It provides a fairly portable abstraction of different versioning schemes implemented in different operating systems/libc's. By definition, libtool cannot do better than what the native system provides. In cases where the native system provides even less than what the libtool versioning is able to express, such as w32, it has to resort to library renaming to get even a chance of a kind of versioning. I have a similar problem as the author in developing libraries that can be compiled on Unix as well as Windows/Cygwin. I've implemented a solution to my problem, where I have a resource that specifies a version as well as a filename. See, there are the following details that are typical for a Windows Resource (rsrc.rc.in): VALUE OriginalFilename, @MYLIBFILENAME@ VALUE FileVersion, @MYLIBVERSION@ VALUE ProductVersion, @MYPROGVERSION@ where MYLIBFILENAME is the guessed filename that libtool will generate (I can't get this directly from libtool, or a script, or conf files - instead I get the .la filename and this is not correct). MYLIBVERSION is the version of the file. I don't use the MS version scheme, but use one similar to unix that works just as well: Major.Minor.Revision.Build. This can be different for each library in my package. - Major is the major version as used in Unix - Minor is the minor version as used in Unix - Revision is the revision as used in Unix - Build is my own value, usually obtained from SVN, or incremented and stored somewhere on each configure invocation And it works for installers too. They can update my library when they need to (assuming I haven't inserted bugs and I've reviewed my code thoroughly enough for ABI breakages). MYPROGVERSION is then the version given in AC_INIT. Unfortunately, to get MYLIBFILENAME and MYLIBVERSION (a.b.c) I needed to implement a new macro that effectively copies the content of what's in libtool, duplicating it. I would have /loved/ to somehow pull this information instead from libtool. And I only need this information for cygwin/windows. I'm even happy to let libtool add a version to the end, like libmyprog-1.dll and libmyprog-2.dll if I change the ABI. I consider this a very useful feature. I know a lot of talk has been going on about automatic versioning, this could be used to cover the case for the build setting used in Windows Resources. If anyone would like, I can post a template I've set up that works for both CVS and SVN (sorry, no GIT, ClearCase, etc.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
On 04/05/2010 20:41, Peter Rosin wrote: Den 2010-05-04 20:00 skrev Ralf Wildenhues: Errrm, is that really so? I tend to agree with Jef here... I take it that your response is to my ... it will work sentence, not the paragraph below that. Ah, indeed. The algorithm *could* be interpreted such that e.g. the interface change int foo(void) - int foo(int) is an interface addition of int foo(int) and an interface remove of int foo(void), thus triggering both #5 and #6. But in that case changed need not be mentioned in #4 either. So, because changed is mentioned in #4, it also needs to be explicitly mentioned in #6. Ah, ok. Yes, you're right. Feel free to commit a patch to s/removed/ or changed/ in 6. Sorry I came in late for the discussion. Is it correct to interpret removed as an interface has been removed, or an interface has been changed so as to cause a binary incompatibility, so that bumping the major version is the result to indicate it is not 100% binary compatible with the previous version, and therefore may break a program that is already compiled against this library? I've pushed the attached patch... Cheers, Peter 2010-05-05 Peter Rosin p...@lysator.liu.se Clarify versioning algorithm documentation. * doc/libtool.texi (Updating version info): Be explicit about setting age to zero on interface change. Reported by Jef Driesen jefdrie...@hotmail.com ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Detecting Static/Shared builds
Hello, I've set up a library that can be built on Windows (mingw32 or cygwin) or on a Unix type OS (e.g. Linux or Solaris). I've defined a header that checks if the WINDOWS_H file exists and if it does, I then define things like LIBAPI, WINAPI, DLLEXPORT. That all works when I build a shared library. But when I build a static library that will link with the executables (primarily to make debugging easier), on Windows platforms I have problems because LIBAPI is still defined decl(dllexport) and it doesn't need to be. Is there anyway from the libtool system to know if the current file being compiled is for static or shared, maybe through a #define? I've skimmed through the libtool manual but not found anything terribly relevant except for section 5.6 (Static-only libraries). But I believe this problem can occur even if I build both, then I need to figure out which invocation (shared or static) and so a variable in configure.ac won't work either, probably something passed on the command line. Of course, it's only a problem on Windows (my main platform). It might be I use a compiler other than GNU (e.g. Intel, or MSVC) so I'd like to avoid compiler specific features, but I'll always be using autoconf and friends. Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: printing library version
Tor Lillqvist wrote:
What exactly do you mean with library version ? Note that neither
the libtool triple current:revision:age nor the Linux-style suffix it
causes to be appended after the .so correspond to the actual version
number for most libraries.
Isn't it simplest to just pass a -DMYLIB_VERSION=a.b.c.d when
compiling and then have a function
Well I've always needed to get the filename (somewhat related to the
library version) when building Windows DLLs that I can prepare a
resource.in file, that will be substituted with the filename and the api
version with a self generated build number (e.g. from SVN). I end up
having to repeat what actually exists in the macros in my own macro
because there's no function I can call to get this information,
probably because this is entirely handled within libtool. Then a
non-autoconf tool can use Windows Resources to get the (lib api) version
also and determine if it's compatible alongside the libtool rules for R:C:A.
const char *
mylib_get_version(void)
{
return MYLIB_VERSION;
}
or something like that?
--tml
But I agree with Tor here, the Library Version doesn't necessarily
have to be the Library API version which is how I understand libtool.
___
http://lists.gnu.org/mailman/listinfo/libtool
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: Hello Jason, * Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET: Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. config.lt generates the file libtool and thats where things start to get stuck. 'get stuck' is pretty vague. Please make it more specific by posting the command you issued, and cut-and-pasting its output. Since you seem to have a macro that interferes with Libtool macros, please post it, too (or a link if it's large or you've already posted it). Showing contents of configure.ac can help, too, but I'd be able to tell better with more information. OK - a libtoolize works around the problem. And ./libtool --version now shows 2.2.6. I would bet that you ran bare autoreconf. libtoolize is only run when you pass --install to autoreconf. As Ralf points out, passing --verbose to autoreconf can be very helpful while producing little extra output. You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. Also what irks at the moment, is where does the libtool-1.5.x libtool that is generated by configure come from, if I don't have the m4/lt*.m4 macros in my project? Do I still have an installation problem? I was hoping these libtool macros don't need to be part of my project and would be pulled from the installation. That way it's always guaranteed to be using the right macros when I run autoreconf. In that regard, I miss having libtool-1.5. It was simpler. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Roumen Petrov wrote: Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. I guess this would only be a problem when using undocumented features of the autotools. I still don't know why autoreconf couldn't find the libtool.m4, lt*.m4 packages directly from it's own /usr/share/libtool (or similar) repository that is guaranteed to match the libtool that is installed, instead of having to have a symbolic link to that installation location in anycase. As I posted in an earlier post, if I don't have these m4 macros, configure generates a libtool in the current directory that says its version 1.5.26, so it appears I must do it the way libtoolize wants. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html Similar, but between libtool-2.2.4 (Ubuntu 8.10) and libtool-2.2.6 (Cygwin 1.5.x) Thanks for your tips Roumen. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Ralf Wildenhues wrote: Hello Jason, * Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET: Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. config.lt generates the file libtool and thats where things start to get stuck. 'get stuck' is pretty vague. Please make it more specific by posting the command you issued, and cut-and-pasting its output. Since you seem to have a macro that interferes with Libtool macros, please post it, too (or a link if it's large or you've already posted it). Showing contents of configure.ac can help, too, but I'd be able to tell better with more information. OK - a libtoolize works around the problem. And ./libtool --version now shows 2.2.6. I for the life of me have no idea how to debug where the macro is coming from that caused libtool 1.5.26 to be generated. And without that I can't even begin to explain why I had this problem in the first place. Cheers, Ralf PS: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html has a section that covers it doesn't work. ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 2.2.x and getting library filename
Hello, I've not heard an answer from my previous post and plunged into libtool 2.2.6a. To my surprise, except for one hitch, it works pretty well with only some small changes to my macros. I've still got the same problem with libtool 2.2.x, in that I still can't determine a way to figure out what the name of my library will be. I've read through the libtool manual, I can use the variables to get filenames and I've got something working, but the output of libtool --config is missing some important info that the libtool script uses to generate filenames, such as the version numbers. One has to rummage through the m4 macros and the libtool script and borrow code from there. I'm still missing how to get the versions that will be used. In particular on irix I can't easily determine what $major is going to be before I use library_names_spec (it could be $current-$age or $current-$age+1). Help is appreciated. Cheers Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Hi Ralf Ralf Wildenhues wrote: Hello Jason, * Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET: Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. config.lt generates the file libtool and thats where things start to get stuck. 'get stuck' is pretty vague. Please make it more specific by posting the command you issued, and cut-and-pasting its output. Since you seem to have a macro that interferes with Libtool macros, please post it, too (or a link if it's large or you've already posted it). Showing contents of configure.ac can help, too, but I'd be able to tell better with more information. Get stuck was on the next line. After configure ./libtool --version 1.5.27a There's nothing special in the configure.ac. And with this inconsistency I didn't move forward. Everything was set up with Cygwin's setup . /usr/bin/libtool --version ltmain.sh (GNU libtool) 2.2.6 So it must be a macro somewhere. I deleted completely /usr/share/libtool and reinstalled. I'm not sure where else I can find libtool. Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
LT_PREREQ breaks autoreconf
I have a macro and in the first lines are: AC_PREREQ(2.61) LT_PREREQ([2.2.6]) When I run autoreconf I get: $ autoreconf configure.ac:33: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:33: the top level autom4te-2.63: /usr/bin/m4 failed with exit status: 1 aclocal-1.10: autom4te failed with exit status: 1 autoreconf-2.63: aclocal failed with exit status: 1 If I remove LT_PREREQ then the configure script compiles and I can move forward. But now that I've updated my CVS tree for libtool 2.2.6 I want an error if I run autoreconf with a system that still has 1.5.x installed (to say I can't support that anymore). And according to the libtool manual this should work, but it doesn't for me. Help much appreciated. Jason. Details about my system: $ autoconf --version autoconf (GNU Autoconf) 2.63 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/old-licenses/gpl-2.0.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. $ uname -a CYGWIN_NT-5.1 europa 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ libtool --version ltmain.sh (GNU libtool) 2.2.6 Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996 Copyright (C) 2008 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. $ automake --version automake (GNU automake) 1.10.1 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey tro...@redhat.com and Alexandre Duret-Lutz a...@gnu.org. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_PREREQ breaks autoreconf
Ralf Wildenhues wrote: [ adding bug-autoconf ] Hello Jason, thanks for the bug report. I always assume first a user error. I'm happy to be of assistance. * Jason Curl wrote on Sat, Dec 13, 2008 at 10:01:22AM CET: I have a macro and in the first lines are: AC_PREREQ(2.61) LT_PREREQ([2.2.6]) When I run autoreconf I get: $ autoreconf configure.ac:33: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:33: the top level autom4te-2.63: /usr/bin/m4 failed with exit status: 1 aclocal-1.10: autom4te failed with exit status: 1 autoreconf-2.63: aclocal failed with exit status: 1 If I remove LT_PREREQ then the configure script compiles and I can move forward. Hmm; I can reproduce this with Autoconf 2.63 but not with current git, with a test case of: LT_PREREQ([2.2.6]) AC_INIT LT_INIT It works in any case when I move LT_PREREQ after AC_INIT, or in a macro definition such as: AC_DEFUN([FOO], [LT_PREREQ([2.2.6])]) AC_INIT FOO LT_INIT Autoconf questions: Is the failure due to a bug in Autoconf 2.63 diversion handling, and if yes, where is it fixed (NEWS and ChangeLog don't seem to indicate)? Question for Jason: you state you had the LT_PREREQ in a macro. Do you expand (call) the macro before AC_INIT? If yes, can you show a small example that reproduces that failure? Asking because I can only reproduce it when LT_PREREQ is actually expanded earlier. I'd like to correct my first statement. I'm getting my words mixed up and I meant project. Macros are on my mind from other libtool topics. Should read again more carefully before I send. So thanks Ralf, you did recreate and confirm my issue. Cheers Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
windres on mingw32 and cygwin
Hello, My next woe when porting over to libtool-2.x. It looks like the compilation phase of libtool has changed for resources. The shared library works, but the static library build on mingw32/cygwin no longer works. Not sure what I did to completely break it. Hope somebody can help, the libtool manual contains very little about windows dlls. The relevant output of the build is: /bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo libtool: compile: windres rsrc.rc -o .libs/rsrc.o libtool: compile: windres rsrc.rc /dev/null 21 /bin/sh ../../libtool --tag=CC --mode=link gcc -mno-cygwin -g -O2 -no-undefined -version-info 1:0:0 -Wl,--add-stdcall-alias -o libwin.la -rpath /usr/local/lib version.lo libmain.lo rsrc.lo libtool: link: rm -fr .libs/libwin.dll.a libtool: link: gcc -mno-cygwin -shared .libs/version.o .libs/libmain.o .libs/rsrc.o-mno-cygwin -Wl,--add-stdcall-alias -o .libs/libwin-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libwin.dll.a Creating library file: .libs/libwin.dll.a libtool: link: ar cru .libs/libwin.a version.o libmain.o rsrc.o ar: rsrc.o: No such file or directory make[3]: *** [libwin.la] Error 1 make[3]: Leaving directory `/home/jcurl/winlib/code/libwin/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jcurl/winlib/code/libwin/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jcurl/winlib/code/libwin' It seems like it's put in .libs and not in the same directory as the source, and this is why it can't link. I currently do: configure.ac LT_INIT([win32-dll]) LT_LANG([Windows Resource]) AM_CONDITIONAL([HAVE_WINDRES], [test x$ac_cv_prog_ac_ct_RC != x]) if test x$ac_cv_c_compiler_gnu = xyes; then case $host_os in mingw* | cygwin*) SHLIB_VERSION_ARG=-Wl,--add-stdcall-alias ;; *) ;; esac fi AC_SUBST(SHLIB_VERSION_ARG) WINLIB_VERSION_INFO=1:0:0 AC_SUBST(WINLIB_VERSION_INFO) Makefile.am FILES = main.c if HAVE_WINDRES FILES += rsrc.rc endif .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile $(RC) $(RCFLAGS) $ -o $@ libwin_la_LDFLAGS = -no-undefined -version-info @WINLIB_VERSION_INFO@ @SHLIB_VERSION_ARG@ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windres on mingw32 and cygwin
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 04:57:02PM CET:
/bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo
libtool: compile: windres rsrc.rc -o .libs/rsrc.o
libtool: compile: windres rsrc.rc /dev/null 21
The second is missing '-o rsrc.o'. Seems windres output to stdout by
default, which of course makes the above break.
Please post the output of
../../libtool --tag=RC --config
Thanks,
Ralf
# Which release of libtool.m4 was used?
macro_version=2.2.6
macro_revision=1.3012
# Assembler program.
AS=as
# DLL creation program.
DLLTOOL=dlltool
# Object dumper program.
OBJDUMP=objdump
# Whether or not to build shared libraries.
build_libtool_libs=yes
# Whether or not to build static libraries.
build_old_libs=yes
# What type of objects to build.
pic_mode=default
# Whether or not to optimize for fast installation.
fast_install=needless
# The host system.
host_alias=i686-pc-mingw32
host=i686-pc-mingw32
host_os=mingw32
# The build system.
build_alias=
build=i686-pc-cygwin
build_os=cygwin
# A sed program that does not truncate output.
SED=/usr/bin/sed
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed=$SED -e 1s/^X//
# A grep program that handles long lines.
GREP=/usr/bin/grep
# An ERE matcher.
EGREP=/usr/bin/grep -E
# A literal string matcher.
FGREP=/usr/bin/grep -F
# A BSD- or MS-compatible name lister.
NM=link -dump -symbols
# Whether we need soft or hard links.
LN_S=ln -s
# What is the maximum length of a command?
max_cmd_len=8192
# Object file suffix (normally o).
objext=o
# Executable file suffix (normally ).
exeext=
# whether the shell understands unset.
lt_unset=unset
# turn spaces into newlines.
SP2NL=tr \\040 \\012
# turn newlines into spaces.
NL2SP=tr \\015\\012 \\040\\040
# How to create reloadable object files.
reload_flag= -r
reload_cmds=\$LD\$reload_flag -o \$output\$reload_objs
# Method to check whether dependent libraries are shared objects.
deplibs_check_method=file_magic ^x86 archive import|^x86 DLL
# Command to use when deplibs_check_method == file_magic.
file_magic_cmd=func_win32_libid
# The archiver.
AR=ar
AR_FLAGS=cru
# A symbol stripping program.
STRIP=strip
# Commands used to install an old-style archive.
RANLIB=ranlib
old_postinstall_cmds=chmod 644 \$oldlib~\$RANLIB \$oldlib
old_postuninstall_cmds=
# A C compiler.
LTCC=gcc -mno-cygwin
# LTCC compiler flags.
LTCFLAGS=-g -O2
# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe=
# Transform the output of nm in a proper C declaration.
global_symbol_to_cdecl=
# Transform the output of nm in a C name address pair.
global_symbol_to_c_name_address=sed -n -e 's/^: \\([^ ]*\\) \$/ {\1\\\,
(void *) 0},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\([^ ]*\\)\$/ {\\\2\, (void
*) 2},/p'
# Transform the output of nm in a C name address pair when lib prefix is needed.
global_symbol_to_c_name_address_lib_prefix=sed -n -e 's/^: \\([^ ]*\\) \$/
{\1\\\, (void *) 0},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\(lib[^ ]*\\)\$/
{\\\2\, (void *) 2},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\([^ ]*\\)\$/
{\lib\\2\, (void *) 2},/p'
# The name of the directory that contains temporary libtool files.
objdir=.libs
# Shell to use when invoking shell scripts.
SHELL=/bin/sh
# An echo program that does not interpret backslashes.
ECHO=echo
# Used to examine libraries when file_magic_cmd begins with file.
MAGIC_CMD=file
# Must we lock files when doing compilation?
need_locks=no
# Tool to manipulate archived DWARF debug symbol files on Mac OS X.
DSYMUTIL=
# Tool to change global to local symbols on Mac OS X.
NMEDIT=
# Tool to manipulate fat objects and archives on Mac OS X.
LIPO=
# ldd/readelf like tool for Mach-O binaries on Mac OS X.
OTOOL=
# ldd/readelf like tool for 64 bit Mach-O binaries on Mac OS X 10.4.
OTOOL64=
# Old archive suffix (normally a).
libext=a
# Shared library suffix (normally .so).
shrext_cmds=.dll
# The commands to extract the exported symbol list from a shared archive.
extract_expsyms_cmds=
# Variables whose values should be saved in libtool wrapper scripts and
# restored at link time.
variables_saved_for_relink=PATH PATH LD_RUN_PATH GCC_EXEC_PREFIX COMPILER_PATH
LIBRARY_PATH
# Do we need the lib prefix for modules?
need_lib_prefix=no
# Do we need a version for libraries?
need_version=no
# Library versioning type.
version_type=windows
# Shared library runtime path variable.
runpath_var=LD_RUN_PATH
# Shared library path variable.
shlibpath_var=PATH
# Is shlibpath searched before the hard-coded library search path?
shlibpath_overrides_runpath=yes
# Format of library name prefix.
libname_spec=lib\$name
# List of archive names. First name is the real one, the rest are links.
# The last name is the one that the linker finds with -lNAME
library_names_spec=\$libname.dll.a
# The coded name of the library, if different from the real name.
soname_spec
Error when compiling with libtool for shared libraries
I'm using libtool-2.2.6 on Cygwin and having some difficulties at the end. I thought I had it working, but can't figure out what changed to make it break. In particular, my libtool library is compiling as shared, but when I compile a test program to link to the shared library I get a failure with the program lt-version.c /.libs/lt-version.c: In function `main': ./.libs/lt-version.c:485: error: `_P_WAIT' undeclared (first use in this function) ./.libs/lt-version.c:485: error: (Each undeclared identifier is reported only once ./.libs/lt-version.c:485: error: for each function it appears in.) strip: './version.exe': No such file ../../libtool: line 8488: $func_ltwrapper_scriptname_result: ambiguous redirect I've removed m4/libtool.m4, m4/lt*.m4, config/ltmain.sh, aclocal.m4 and did libtoolize, autoreconf. But the problem still remains. Here's the complete output. jc...@europa ~/winlib/code $ ./configure --disable-static --host=i686-pc-mingw32 $ make Making all in libtestfw make[1]: Entering directory `/home/jcurl/winlib/code/libtestfw' gcc -DHAVE_CONFIG_H -I. -I../libwin/src -I../libwin/src-g -O2 -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o test.c mv -f .deps/test.Tpo .deps/test.Po rm -f libtestfw.a ar cru libtestfw.a test.o ranlib libtestfw.a make[1]: Leaving directory `/home/jcurl/winlib/code/libtestfw' Making all in libwin make[1]: Entering directory `/home/jcurl/winlib/code/libwin' Making all in src make[2]: Entering directory `/home/jcurl/winlib/code/libwin/src' make all-am make[3]: Entering directory `/home/jcurl/winlib/code/libwin/src' /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.-DBUILD_DLL -g -O2 -MT version.lo -MD -MP -MF .deps/version.Tpo -c -o version.lo version.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -DBUILD_DLL -g -O2 -MT version.lo -MD -MP -MF .deps/version.Tpo -c version.c -DDLL_EXPORT -DPIC -o .libs/version.o mv -f .deps/version.Tpo .deps/version.Plo /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.-DBUILD_DLL -g -O2 -MT libmain.lo -MD -MP -MF .deps/libmain.Tpo -c -o libmain.lo libmain.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -DBUILD_DLL -g -O2 -MT libmain.lo -MD -MP -MF .deps/libmain.Tpo -c libmain.c -DDLL_EXPORT -DPIC -o .libs/libmain.o mv -f .deps/libmain.Tpo .deps/libmain.Plo /bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo libtool: compile: windres rsrc.rc -o .libs/rsrc.o cp .libs/rsrc.o rsrc.o /bin/sh ../../libtool --tag=CC --mode=link gcc -DBUILD_DLL -g -O2 -no-undefined -version-info 1:0:0 -Wl,--add-stdcall-alias -o libwin.la -rpath /usr/local/lib version.lo libmain.lo rsrc.lo libtool: link: rm -fr .libs/libwin.a .libs/libwin.dll.a .libs/libwin.la .libs/libwin.lai libtool: link: gcc -shared .libs/version.o .libs/libmain.o .libs/rsrc.o-Wl,--add-stdcall-alias -o .libs/libwin-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libwin.dll.a Creating library file: .libs/libwin.dll.a libtool: link: ( cd .libs rm -f libwin.la ln -s ../libwin.la libwin.la ) make[3]: Leaving directory `/home/jcurl/winlib/code/libwin/src' make[2]: Leaving directory `/home/jcurl/winlib/code/libwin/src' Making all in test make[2]: Entering directory `/home/jcurl/winlib/code/libwin/test' gcc -DHAVE_CONFIG_H -I. -I../../libwin/src -I../../libwin/src -I../../libtestfw-g -O2 -MT version.o -MD -MP -MF .deps/version.Tp o -c -o version.o version.c mv -f .deps/version.Tpo .deps/version.Po /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -o version.exe version.o ../src/libwin.la ../../libtestfw/libtestfw.a libtool: link: gcc -g -O2 -o .libs/version.exe version.o ../src/.libs/libwin.dll.a ../../libtestfw/libtestfw.a -L/usr/local/lib ./.libs/lt-version.c: In function `main': ./.libs/lt-version.c:485: error: `_P_WAIT' undeclared (first use in this function) ./.libs/lt-version.c:485: error: (Each undeclared identifier is reported only once ./.libs/lt-version.c:485: error: for each function it appears in.) strip: './version.exe': No such file ../../libtool: line 8488: $func_ltwrapper_scriptname_result: ambiguous redirect make[2]: Leaving directory `/home/jcurl/winlib/code/libwin/test' make[2]: Entering directory `/home/jcurl/winlib/code/libwin' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/jcurl/winlib/code/libwin' make[1]: Leaving directory `/home/jcurl/winlib/code/libwin' make[1]: Entering directory `/home/jcurl/winlib/code' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/jcurl/winlib/code' ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windres on mingw32 and cygwin
Alon Bar-Lev wrote: On 12/13/08, Jason Curl jcurln...@arcor.de wrote: .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile $(RC) $(RCFLAGS) $ -o $@ libwin_la_LDFLAGS = -no-undefined -version-info @WINLIB_VERSION_INFO@ @SHLIB_VERSION_ARG@ You can look at OpenSC implementation it works both for libtool-1.5 and libtool-2. Maybe I am doing something wrong... But at least it works... :) I will be happy to know if there is a better way. I have the followings: RCCOMPILE = $(RC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE) .rc.lo: $(LTRCCOMPILE) -i $ -o $@ .rc.o: $(RCCOMPILE) -i $ -o $@ Look at: http://www.opensc-project.org/svn/opensc/trunk/configure.ac http://www.opensc-project.org/svn/opensc/trunk/win32/ltrc.inc http://www.opensc-project.org/svn/opensc/trunk/src/libopensc/Makefile.am Alon. Thanks for the tip Alon. It looks like in my project the .rc.o rule isn't being executed. I can see my changes are being pulled in as the output has changed slightly. I'm still getting the following error. /bin/sh ../../libtool --mode=compile --tag=RC windres -DHAVE_CONFIG_H -I.-i rsrc.rc -o rsrc.lo libtool: compile: windres -DHAVE_CONFIG_H -I. -i rsrc.rc -o .libs/rsrc.o libtool: compile: windres -DHAVE_CONFIG_H -I. -i rsrc.rc /dev/null 21 /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -no-undefined -version-info 1:0:0 -Wl,--add-stdcall-alias -o libwin.la -rpath /usr/local/lib version.lo libmain.lo rsrc.lo libtool: link: gcc -shared .libs/version.o .libs/libmain.o .libs/rsrc.o-Wl,--add-stdcall-alias -o .libs/libwin-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libwin.dll.a Creating library file: .libs/libwin.dll.a libtool: link: ar cru .libs/libwin.a version.o libmain.o rsrc.o ar: rsrc.o: No such file or directory make[3]: *** [libwin.la] Error 1 make[3]: Leaving directory `/home/jcurl/winlib/code/libwin/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jcurl/winlib/code/libwin/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jcurl/winlib/code/libwin' make: *** [all-recursive] Error 1 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windres on mingw32 and cygwin
Ralf Wildenhues wrote: * Jason Curl wrote on Sat, Dec 13, 2008 at 06:00:31PM CET: Ralf Wildenhues wrote: * Jason Curl wrote on Sat, Dec 13, 2008 at 04:57:02PM CET: /bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo libtool: compile: windres rsrc.rc -o .libs/rsrc.o libtool: compile: windres rsrc.rc /dev/null 21 # A language specific compiler. CC= # How to pass a linker flag through the compiler. wl= # Additional compiler flags for building library objects. pic_flag= # Does compiler simultaneously support -c and -o options? compiler_c_o= This is your problem. I guess you're missing an LT_LANG([Windows Resource]) I have a macro that calls this for me. AC_DEFUN([LX_PROG_RC], [AS_IF([test x$ac_cv_prog_ac_ct_RC = x], [LT_LANG([Windows Resource])], []) AM_CONDITIONAL([HAVE_WINDRES], [test x$ac_cv_prog_ac_ct_RC != x]) ]) Looks like that isn't working properly, because the AM_CONDITIONAL was setting HAVE_WINDRES else I wouldn't be compiling the rsrc.rc file at all. in configure.ac (after LT_INIT), which I guess makes the '-c -o' test for windres fail. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Error when compiling with libtool for shared libraries
Ralf Wildenhues wrote: * Jason Curl wrote on Sat, Dec 13, 2008 at 07:47:43PM CET: I'm using libtool-2.2.6 on Cygwin and having some difficulties at the end. I thought I had it working, but can't figure out what changed to make it break. /.libs/lt-version.c: In function `main': ./.libs/lt-version.c:485: error: `_P_WAIT' undeclared (first use in this function) [...] $ ./configure --disable-static --host=i686-pc-mingw32 That doesn't match: MinGW is not Cygwin. If you don't cross-compile, there is no need to specify --host. If you cross-compile, and in this case producing MinGW executables is more-or-less like cross compilation, then you need to use a compiler (option) to produce non-Cygwin output (-mno-cygwin IIRC). Ralf - many many thanks. A 'CC=gcc -mno-cygwin' needs to be prepended. I can't say how much I appreciate you spotting the obvious. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windres on mingw32 and cygwin
Ralf Wildenhues wrote: * Jason Curl wrote on Sat, Dec 13, 2008 at 09:05:52PM CET: Ralf Wildenhues wrote: I guess you're missing an LT_LANG([Windows Resource]) I have a macro that calls this for me. AC_DEFUN([LX_PROG_RC], [AS_IF([test x$ac_cv_prog_ac_ct_RC = x], [LT_LANG([Windows Resource])], []) AM_CONDITIONAL([HAVE_WINDRES], [test x$ac_cv_prog_ac_ct_RC != x]) ]) Looks like that isn't working properly, because the AM_CONDITIONAL was setting HAVE_WINDRES else I wouldn't be compiling the rsrc.rc file at all. Does it work if you move the LT_LANG out of the conditional? It works in the macro when I move the LT_LANG outside of the AS_IF conditional. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Migrating from 1.5.x to 2.2.x
Hello, I got some help with my previous question about library filenames but no real answer, so I'm looking into what kind of effort it is to move over to libtool 2.2.6a. Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. config.lt generates the file libtool and thats where things start to get stuck. I've removed /usr/share/libtool and reinstalled, but libtool --version always shows 1.5.27a. What am I doing wrong? Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting filenames for libraries
Ralf Wildenhues wrote:
Hello Jason,
* Jason Curl wrote on Mon, Dec 08, 2008 at 08:43:35PM CET:
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
FWIW, most distros have a way to use upstream packages without
re-libtoolizing and re-autoreconfing them.
I'm using Ubuntu 8.04, SuSE 11.0, Cygwin 1.5.x. I'm a little afraid of
having both libtool 1.5.x and 2.x installed simultaneously and don't
want to uninstall 1.5.x in fear of breaking things. This newsgroup has
enough reports about mixing releases, especially libtool.
I'll look forward to playing around with Ubuntu 8.10 when I get time to
testdrive libtool-2.x. Until then I've had to write a bunch of libtool
macros that are specific to 1.5.x (code copy, paste and hack) to achieve
some results.
Is there any way, given an la file, to get the file name of the library
that will be generated at make time?
What do you need it for?
I should rephrase the question. Is there anyway, given the name of the
la file I want to generate (it's not yet built at configure time) and
given the options that I want to use to build the library, can I get the
filename that libtool will generate?
Windows DLL rsrc for version has some fields (such as InternalName) that
should be the name of the library DLL. For Non-Windows targets I plan to
have a function that I call that gets the name and the version of the
library that I can use for some version checking so I'll be embedding
the name directly into C files with @LIBRARY_NAME@ or something similar
and converting the myfile.h.in to myfile.h and then distributing
this tarball.
All this is going in a general template for shared libraries that can be
compiled on Windows and Posix like targets so I'm looking for it to be
as automatic as possible.
Then it'll be extended to plugins which will have an API for version
information and the filename will be embedded. A bit contrived, but the
Windows resource filename is the big issue. I'm looking for a generic
answer as somebody has already done most of the hard work.
libtool --config gives me partial information (such as the
library_names_spec and soname_spec) but some of the variables are
missing, such as ${shared_ext}, etc. I was kind of hoping there might be
also someway to call script libtool and get the information directly
from the source, is this even possible?
For shared_ext, you currently need to
eval shared_ext=\$shrext_cmds\
Got that part from reading through aclocal.m4 and libtool after
autoreconf/configure (couldn't be bothered finding the source all the
time for libtool.m4 as it was copied in anycase to my development tree
via autoconf).
Basically, I've got something pretty much implemented. Found out that on
Cygwin/MinGW32 the soname_spec is what I want and on
Linux/Solaris/FreeBSD library_names_spec is what I want.
But there's a lot of duplicate stuff between my m4 macro that gets this
information and libtool itself. And my macros won't work on all systems
(probably not irix, osf and what appeared to be another weird library
naming system).
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting filenames for libraries
Brian Dessent wrote:
Jason Curl wrote:
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
FWIW, most distros have a way to use upstream packages without
re-libtoolizing and re-autoreconfing them.
I'm using Ubuntu 8.04, SuSE 11.0, Cygwin 1.5.x. I'm a little afraid of
having both libtool 1.5.x and 2.x installed simultaneously and don't
want to uninstall 1.5.x in fear of breaking things. This newsgroup has
enough reports about mixing releases, especially libtool.
I think what Ralf meant was that you said most distros I support as if
to imply that shipping a tarball generated with 2.2 would also require
end-users to have 2.2 installed to build it. But the whole point of the
make dist tarball is that it's standalone and the user shouldn't need
any special developer tools to build it, other than a shell, compiler,
and make.
Brian
Thanks Brian, I wasn't 100% sure of what Ralf meant. I'm not as clear as
I'd like to be, these are the platforms I develop with in various
environments and testing (but I hope that's understood now :)
I've attached a sample of the macros if there are comments.
e.g.
configure.ac (only the interesting bits)
AC_CANONICAL_BUILD
AC_CANONICAL_HOST
AC_CANONICAL_TARGET
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
LX_PACKAGE_LIBVERSION([WINLIB], [1], [0], [0], [libmywindll.la])
LX_PROG_RC
AC_CONFIG_FILES([src/rsrc.rc])
Makefile.am
lib_LTLIBRARIES = libmywindll.la
FILES = libmain.c version.c
if HAVE_WINRC
FILES+=rsrc.rc
endif
libmywindll_la_SOURCES=$(FILES)
.rc.lo:
$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC
--mode=compile $(RC) $(RCFLAGS) $ -o $@
libwin_la_LDFLAGS = -no-undefined -version-info @WINLIB_VERSION_INFO@
@SHLIB_VERSION_ARG@
# LX_PACKAGE_LIBVERSION([LIBNAME], [CURRENT], [REVISION], [AGE], [LA FILE])
# -
# For a particular library, define 5 variables:
# LIBNAME_VERSION_INFO
# LIBNAME_MAJOR
# LIBNAME_MINOR
# LIBNAME_REVISION
# LIBNAME_BUILD
# LIBNAME_FILENAME
#
# We will probably break on the following:
# irix, nonstopux, osf (versioning schemes)
# beos, pw32*
#
# We don't support -release or other versioning schemes. We assume
# -version-info c:r:a
#
# Tested on:
# - sparc-sun-solaris2.10
# - i686-pc-linux-gnu
# - i686-pc-cygwin
# - i686-pc-mingw32
AC_DEFUN([LX_PACKAGE_LIBVERSION],
[AC_MSG_CHECKING([Library version $1])
$1_VERSION_INFO=$2:$3:$4
outputname=$5
case $outputname in
lib*)
name=`$echo X$outputname | $Xsed -e 's/\.la$//' -e 's/^lib//'`
eval shared_ext=\$shrext_cmds\
eval libname=\$libname_spec\
;;
*)
AC_MSG_ERROR([
***
*** There's a problem in your configure script. Library names must
*** start with 'lib'
***])
;;
esac
release=
current=$2
revision=$3
age=$4
case $version_type in
darwin)
major=.`expr $current - $age`
versuffix=$major.$age.$revision
;;
freebsd-aout)
major=.$current
versuffix=.$current.$revision;
;;
freebsd-elf)
major=.$current
versuffix=.$current;
;;
linux)
major=.`expr $current - $age`
versuffix=$major.$age.$revision
;;
sunos)
major=.$current
versuffix=.$current.$revision
;;
windows)
major=`expr $current - $age`
versuffix=-$major
;;
*)
AC_MSG_WARN([Your library versioning scheme isn't supported])
major=
versuffix=
;;
esac
# Generate the filename $1_FILENAME
case $target_os in
*cygwin* | mingw*)
eval $1_FILENAME=\$soname_spec\
;;
*)
eval library_names=\$library_names_spec\
set dummy $library_names
$1_FILENAME=${2}
;;
esac
$1_MAJOR=`expr $current - $age`
$1_MINOR=$age
$1_REVISION=$revision
if test -e ${srcdir}/version.txt; then
. ${srcdir}/version.txt
else
PACKAGE_BUILD=0
fi
$1_BUILD=$PACKAGE_BUILD
version=`echo ${$1_MAJOR}.${$1_MINOR}.${$1_REVISION}.${$1_BUILD}`
AC_SUBST([$1_VERSION_INFO])
AC_SUBST([$1_MAJOR])
AC_SUBST([$1_MINOR])
AC_SUBST([$1_REVISION])
AC_SUBST([$1_BUILD])
AC_SUBST([$1_FILENAME])
AC_MSG_RESULT([${$1_FILENAME} ($version)])
])
# LX_PROG_RC
# --
# Looks for the program 'windres'. Checks that it physically resides in the
# place provided by $RC if before
#
# If found,
# - ac_cv_prog_rc=yes
# - RC=/path/to/id/program
# - RCFLAGS=
# If not found,
# - ac_cv_prog_rc=no
#
# To compile with Libtool, you'll have to add the following to your
Makefile.am
#
# .rc.lo:
# $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC
--mode=compile $(RC) $(RCFLAGS) $ -o $@
#
# TODO:
# - To do, we should check more instances, in particular based on the
triplets
# for GNU compiler tools
# - Should we disable shared libraries? Probably not, leave that to the
user.
AC_DEFUN([LX_TEST_RC],
[if test x$ac_cv_prog_rc != xyes; then
type $1 /dev/null 2/dev/null
if test $? -eq 0
Getting filenames for libraries
Hello,
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
Is there any way, given an la file, to get the file name of the library
that will be generated at make time?
libtool --config gives me partial information (such as the
library_names_spec and soname_spec) but some of the variables are
missing, such as ${shared_ext}, etc. I was kind of hoping there might be
also someway to call script libtool and get the information directly
from the source, is this even possible?
If libtool 2.2.x supports this, I guess it might be one reason to move
up, however most of our development environments (SuSE 11.0, cygwin,
solaris) still have libtool 1.5.26.
I'm writing a macro to get this, but it seems much a copy of libtool and
what's in the m4 files from libtool.
Thanks,
Jason.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: How to disable building the shared version of one library (but not all)
Roberto Bagnara wrote: Hi there, I have a project that builds several libraries. For most of them, both the shared and static versions make sense, so I don't want to use AC_DISABLE_STATIC. However, for some of them the static version does not make any sense. How can I avoid the overhead of building the static version of those? Not a direct answer, but have you considered using convenience libraries for those which should be static, and have default shared? All the best, Roberto ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool-1.5.26 and cross compiling
Hello, I was cross compiling libxml2, provided --prefix=/usr and make DESTDIR=/opt/gcc-cross for a cross compiler (a different c-lib). When testing, I noticed that I had to modify the libxml2.la file to change the libdir=/usr/lib to libdir=/opt/gcc-cross/usr/lib. My question, is this correct? How should I cross compile a library that in the target file system it lives in /usr/lib but for cross compilation, lives somewhere else? Thanks, Jason. Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MinGW DLLs and autoconf parsing
Thanks Roumen, I've taken the same route as you've mentioned although it's hackish. I'm hoping someone from the libtool developer community can comment. Roumen Petrov wrote: Jason Curl wrote: Hello, Recently some info was posted about using resource files with Windows compilers. I'm trying to generate a reasonably simple Version resource and there's some information I'm not sure how I can extract from the build process. I'm using libtool-1.5.27a on MSYS-1.0.10 with MinGW-5.1.4. Question 1: One of the fields is OriginalFilename. When the shared DLL is built, it is installed libfoo-1.dll. I've created a rsrc.rc.in file that autoconf generates for me, substituting information from the build process directly into this resource file. However, how might I get the name of the library before it is built? You may create library with name libfoo.dll if you call make with LDFLAGS=--avoid-version. Also you may set this flag in configure script for mingw host. libtool don't preserve LIBRARY statement specified by def-file. The string -1 is suffix appended by libtool for cygwin/mingw host. The number is equal to $current - $age from version info. Avoiding the version isn't a problem. I see that there's an advantage of using the version. But libtool generates a name, and is there an API to get this name? For different architectures, the naming scheme changes. Or do I need to install and parse the .la file to reliably get the name? Then I can't do this within 'configure.ac' where I do need the name (to generate a resource file from x.rsrc.in). And right now, I've just had to read the libtool source and figure it out. I expect breakages the next time I upgrade.. Question 2: The second task is the versioning. There are two fields, both of the format: FILEVERSION major,minor,revision,build I need to substitute them based on the version information given to libtool during the linking phase. WINSERLOG_VERSION_INFO=1:0:0 AC_SUBST(WINSERLOG_VERSION_INFO) How can I convert the string 1:0:0 to a major.minor.revision field? How does this work? awk, sed , shell ? - born shell sample: IFS=:; set -- `echo a:b:c`; echo $1.$2.$3 Again, reading libtool it defines $major, $minor, $revision, but depending on the platform it changes. The string above is $current, $revision, $age, which is not the same thing. And I remember that it some versions of libtool for some particular platform it's really not obvious. Such a feature is not Windows specific. I have an API in most of my libraries to get the version information Right now, I've just had to do: $major = $current - $age (c-a) $minor = $age (a) $rev = $revision (r) Question 3: As the libtool --tag=RC doesn't work for 1.5.27a (it complained about an unknown tag), I wrote the rule: I guess that configure script is without macro AC_LIBTOOL_RC Tried that already. I think this is probably a new feature for Libtool-2.x I ended up using the tag CC. I don't really know if using tag CC is really intended, or if there could be a breakage later with a different compiler toolset (other than gcc, or with a cross compiler) .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(RC) $(RCFLAGS) $ -o $@ where RC=windres and RCFLAGS is empty. It works, but is it safe? I don't know when MinGW will upgrade the autotools. May be you need two rules : one to create %.lo file and one for object file (%.o): --- RCFLAGS = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) RCCOMPILE = $(RC) $(RCFLAGS) LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE) .rc.lo: $(LTRCCOMPILE) -i $ -o $@ .rc.o: $(RCCOMPILE) -i $ -o $@ --- .o files don't make sense for static libraries in this case, so I'm happy to see that for the static case it isn't even used and everything seems to work. Thanks Best Regards, Jason. Roumen Thanks Roumen. ___ http://lists.gnu.org/mailman/listinfo/libtool
Checking versions and defining macros
Hello, To achieve my goals, I've borrowed some of the internals of the auto* tools (and libtool). I'd like to somehow check the version of the autotools during autoreconf time and include macros specific to a particular version. If I see a version that I haven't tested with, then I'd like to print a warning that something needs to be looked at (i.e. update my macros). This will allow me especially to upgrade to libtool-2.2 and play with it, while knowing it will always work with 1.5.24. A summary of what I've had to hack: AC_CHECK_LIB: borrowed from here for the Solaris networking features AC_CHECK_DECL: Disable printing, to encapsulate in my own scripts AC_PROG_LD: Would die if it couldn't find LD, rather than allow my configure.ac to provide an alternate Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.1b released (alpha release)
Gary V. Vaughan wrote: On 1 Feb 2008, at 01:06, Gary V. Vaughan wrote: The Libtool Team is pleased to announce alpha release 2.1b of GNU Libtool. With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... Either way, if there are no more bugs found before Feb 10th, I plan to roll up 2.2 final. If you have any projects that you're thinking of moving to libtool-2, please test them now so that we can fix any problems you encounter before the final release!! Hi Gary, Are there instructions somewhere how I can have this build sit side-by-side of Libtool 1.5.24 on Linux (Suse 10.3) or Cygwin? So that if I encounter problems I can easily switch between the two as a developer? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
libtest.exe -- Doesn't seem to work? No idea what this is... libtest .libs/ libtest.exe-- Will work when libmofo-1.dll is in the path, e.g. copied to this dir. Can anybody explain what libtool is doing?? It appears to do a lot of nifty stuff, but I don't see any dependencies on libmofo from libtest.exe in either case. I'll attach a minimal example when I'm back at work tomorrow. It is a wrapper to allow running the uninstalled binary in the build tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. On a POSIX system this would be a shell script. I think that in libtool HEAD, it won't have such a confusing name. And the directory it runs from (.libs) indicates it is actually the source lt-libtest.c that relies on a shell, so as soon as I move the executable to a virgin computer without Cygwin, the program libtest.exe won't work. You shouldn't be manually mucking about like that, you use make install to get an installed copy and that will not be a wrapper. If you configured with CC=gcc -mno-cygwin (i.e. used this fake mingw setup) then the Cygwin dependence should only be for the wrapper which isn't supposed to be installed or even moved out of the build directory for that matter. For Posix systems I agree (and I haven't had to care until now). It's an unnecessary burden for w32api however, especially for users that don't have any kind of sane build environment. I guess I'm saying I don't know how to package the result so that someone on w32 can use it on a standard cmd.exe console without having Cygwin, etc. installed. This environment is only necessary for the build. Or should I revert to a different build environment? This is my first attempt at using Autoconf to build something for native Windows (mostly because I want to use it on Linux, but other colleagues of mine benefit from it's use on Windows). I'd also like to generate .lib files (what is the .a file that is generated anyway? Is that the .lib import library?) An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they are all the exact same thing just named differently. Don't confuse the libfoo.a name with a static library which has the same style name but is a totally different thing (and that's why it's considered deprecated to name an import library libfoo.a, but some are still done that way, e.g. all of w32api.) Brian Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE NEUEINSTEIGER Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 29,95 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Roumen Petrov wrote: Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: ./configure CC=gcc -mno-cygwin LDFLAGS=-Wl,--kill-at --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a Fake mingw then you probably also should use --build=mingw as well. Thanks - all of my initial problems. My test code now compiles and links with the DLL. However, when I move the test program out into another folder and copy the DLL into the Windows System path, it doesn't execute. I haven't figured out how to run it without the libtool wrapper. When I observe the dependencies using Microsoft tools, I see there are none other than my library and MS libraries (e.g. Cygwin is not there). The library works correctly when I use say, Visual Basic 6. Please, could you prepare sample test case. I cannot reproduce described issue. Well, I think I've figured it out today (albeit I'm testing on a different machine, similar software though) and there are two executables. One in the build directory and one in .libs. e.g. src/ .libs/ libmofo-1.dll test/ libtest.exe -- Doesn't seem to work? No idea what this is... libtest .libs/ libtest.exe-- Will work when libmofo-1.dll is in the path, e.g. copied to this dir. Can anybody explain what libtool is doing?? It appears to do a lot of nifty stuff, but I don't see any dependencies on libmofo from libtest.exe in either case. I'll attach a minimal example when I'm back at work tomorrow. And the directory it runs from (.libs) indicates it is actually the source lt-libtest.c that relies on a shell, so as soon as I move the executable to a virgin computer without Cygwin, the program libtest.exe won't work. I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. Ooh sounds horrible. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. I can probably live with that solution, I might look how to use export/import library definitions as it would also mean defining precisely the ordinals in the Windows DLLs. I'll take a deeper look at Erik's suggestion, it looks simple enough except I'm not entirely happy with the DEF file generation he uses. You could pass def file to the linker as example: http://svn.gnome.org/viewvc/xmlsec/trunk/configure.in?r1=982r2=983 Roumen Cool, sounds like something that Erik mentioned earlier in libsndfile.dll that I'll look into. I'd also like to generate .lib files (what is the .a file that is generated anyway? Is that the .lib import library?) Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Brian Dessent wrote: Jason Curl wrote: ./configure CC=gcc -mno-cygwin LDFLAGS=-Wl,--kill-at --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a Fake mingw then you probably also should use --build=mingw as well. Thanks - all of my initial problems. My test code now compiles and links with the DLL. However, when I move the test program out into another folder and copy the DLL into the Windows System path, it doesn't execute. I haven't figured out how to run it without the libtool wrapper. When I observe the dependencies using Microsoft tools, I see there are none other than my library and MS libraries (e.g. Cygwin is not there). The library works correctly when I use say, Visual Basic 6. I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. Ooh sounds horrible. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. I can probably live with that solution, I might look how to use export/import library definitions as it would also mean defining precisely the ordinals in the Windows DLLs. I'll take a deeper look at Erik's suggestion, it looks simple enough except I'm not entirely happy with the DEF file generation he uses. ___ http://lists.gnu.org/mailman/listinfo/libtool
Windows DLLs from Unix with minimum effort
Hello, Normally I write software for Posix like operating systems, but to assist somebody I'm writing a Windows DLL that I'd like to later use the source for in my Posix application without having to maintain two code bases. I'm using ./configure CC=gcc -mno-cygwin LDFLAGS=-Wl,--kill-at --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL For each function I want to export I'm using: #define LIBAPI __stdcall __declspec(dllexport) LIBAPI type_t my_func(int param1, int param2); I'd like to use uncomplicated names so it can be used in VB6.0 for example, which is why I use LDFLAGS. I can probably use a DEF file, but I'm not clear how to implement libtool/automake/autoconf so that the DEF file is used only for Windows, or better yet, automatically generated. The library compiles under Windows (I haven't tested the binary yet against any module). I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). When I remove the LDFLAGS option, I instead get a different error: /bin/sh ../../libtool --tag=CC --mode=link gcc -mno-cygwin -O0 -Wall -o chartest.exe chartest.o test.o ../src/libmofo.la mkdir .libs gcc -mno-cygwin -O0 -Wall -o .libs/chartest.exe chartest.o test.o ../src/.libs/libmofo.dll.a -L/usr/local/lib creating chartest.exe ./.libs/lt-chartest.c: In function `main': ./.libs/lt-chartest.c:113: warning: passing arg 2 of `execv' from incompatible pointer type Needless to say that everything works when I compile under Linux when I use ./configure without specifying anything more. I would say at least the second instance might be something wrong with how I manage includes (although there doesn't appear to be anything wrong), or a bug in libtool, but I'm really not sure as this is the first time I've attempted such a project. Thanks, Jason. Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE NEUEINSTEIGER Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 29,95 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
Ralf Wildenhues wrote: * Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST: I've just switched over to using libtool instead of using static libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24. The library builds fine under Linux, but won't link under Solaris Sparc 2.10. [...] /opt/sfw/bin/gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lcurses -lc -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.0: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.0.0.0 collect2: ld returned 1 exit status So I've been able to recreate the issue on Solaris 9. Compilation works when I define (in a config.site file): CC=gcc LD=ld (/usr/ccs/bin/ld) AR=ar (/usr/ccs/bin/ar) RANLIB=ranlib (/usr/ccs/bin/ranlib) It sees GCC, but it sees the Solaris linker (and knows it's not GNU). But if I define LD=gld (/opt/sfw/bin) the GNU linker with GCC, then it falls over with the error given above. [...] So I play around a little with the options. 1. Remove -wl,-soname That won't do good unless you also remove the argument to -soname, i.e., remove -Wl,liblogger.so.0. Could you please try merging this, i.e., instead of -Wl,-soname -Wl,liblogger.so.0 use -Wl,-soname,liblogger.so.0 Produces the same warning as before: ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.1.0.0 collect2: ld returned 1 exit status and also add -v to see whether gcc happens to reorder arguments for ld? Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.0 /usr/local/libexec/gcc/sparc-sun-solaris2.9/3.4.0/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/liblogger.so.1 .0.0 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crt begin.o -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4. 0/../../.. .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .l ibs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/getopt_long.o .libs/ether_ntoa.o .libs/getli ne.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lc -soname liblogger.so.1 -lgcc_s -lgcc_s /usr/local/lib/gcc/ sparc-sun-solaris2.9/3.4.0/crtend.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.380 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.1.0.0 collect2: ld returned 1 exit status So it seems to me that the linker being configured is gld (/opt/sfw/bin/gld) but GCC is using the system linker (/usr/ccs/bin/ld) in anycase causing the error. Does this suggest a problem in the way that AC_PROG_LIBTOOL checks for the linker? I had a quick look how to query the linker from GCC, but it wasn't obvious. Cheers, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
Jason Curl wrote: Ralf Wildenhues wrote: * Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST: I've just switched over to using libtool instead of using static libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24. The library builds fine under Linux, but won't link under Solaris Sparc 2.10. [...] /opt/sfw/bin/gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lcurses -lc -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.0: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.0.0.0 collect2: ld returned 1 exit status So I've been able to recreate the issue on Solaris 9. Compilation works when I define (in a config.site file): CC=gcc LD=ld (/usr/ccs/bin/ld) AR=ar (/usr/ccs/bin/ar) RANLIB=ranlib (/usr/ccs/bin/ranlib) It sees GCC, but it sees the Solaris linker (and knows it's not GNU). But if I define LD=gld (/opt/sfw/bin) the GNU linker with GCC, then it falls over with the error given above. [...] So I play around a little with the options. 1. Remove -wl,-soname That won't do good unless you also remove the argument to -soname, i.e., remove -Wl,liblogger.so.0. Could you please try merging this, i.e., instead of -Wl,-soname -Wl,liblogger.so.0 use -Wl,-soname,liblogger.so.0 Produces the same warning as before: ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.1.0.0 collect2: ld returned 1 exit status and also add -v to see whether gcc happens to reorder arguments for ld? Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.0 /usr/local/libexec/gcc/sparc-sun-solaris2.9/3.4.0/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/liblogger.so.1 .0.0 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crt begin.o -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4. 0/../../.. .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .l ibs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/getopt_long.o .libs/ether_ntoa.o .libs/getli ne.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lc -soname liblogger.so.1 -lgcc_s -lgcc_s /usr/local/lib/gcc/ sparc-sun-solaris2.9/3.4.0/crtend.o /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.380 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.1.0.0 collect2: ld returned 1 exit status So it seems to me that the linker being configured is gld (/opt/sfw/bin/gld) but GCC is using the system linker (/usr/ccs/bin/ld) in anycase causing the error. Does this suggest a problem in the way that AC_PROG_LIBTOOL checks for the linker? I had a quick look how to query the linker from GCC, but it wasn't obvious. There's no bug, except what I introduced. On Solaris when there is no GCC installed (or not in the path) and AC_PROG_LIBTOOL can't find LD from the compiler being used, it doesn't find LD. So I wrote a macro to find LD for me automatically on Solaris. Problem was, this macro was being run before AC_PROG_LIBTOOL and causing screwy things to happen. AC_PROG_LIBTOOL assumes it should be overridden and of course this error occurs. It doesn't look like there's any easy way to specify in this case what LD to use within the 'configure' script. Sure I can enable the path, or specify a config.site script. But it's less hassle if it works out of the box on a standard installed Solaris box. Because AC_PROG_LIBTOOL looks for an 'ld'. It can't find it and dies. But if I specify one too early, on most systems it will fail. What can I do? All I assume is I can update the PATH environment to point to LD. I'm trying my best to remove the need for a 'config.site' file for systems that have a pretty much standard install. I'm supporting FreeBSD6.1, Solaris 9, Solaris 10, Linux and Cygwin. I might have to copy the As I said, I'm still coming
Re: Creating ONLY static libraries
Omri Azencot wrote: Hello I am using libtool 1.5.23 during the building process, I am also using autoconf(2.61) to create the configure file. in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the following line: checking whether to build shared libraries... no but, after make install the package did installed in the installation folder files of the type *.la *.dll.a. My goal is to create only static libraries of this module, am I missing something ? If you don't need to have the libraries installed for a convenience library, use noinst_*. See: http://www.gnu.org/software/automake/manual/automake.html#A-Library Similarly for libtool: http://www.gnu.org/software/libtool/manual.html#Static-libraries The answer from Mike is correct, they're static libraries that other programs may link to if wanted. How do you plan to use this library? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Brian Dessent wrote: .dll.a is the import library. .dll is the actual library. Both should be produced. The import library is used when linking against the library, but it is not needed at runtime and contains no code. It's typically distributed in the same context as headers -- it is needed by developers who want to build against your library, but not users who simply want to run software that uses your library. In some cases it is also named just libfoo.a, or perhaps foo.lib if you want compatibility with users of the MS toolchain. As its name suggests this is actaully an ar archive. It looks like you may be getting confused because the linker outputs a message along the lines of creating file libfoo.dll.a when the --out-implib linker switch is used, but this really means in addition to the normal output libfoo.dll I'm also producing an import library libfoo.dll.a as a side effect of creating the library not that the library would actually be named libfoo.dll.a. The concept of an import library is a bit of a hold-back to days past. Using the GNU linker at least, you can link directly to a DLL without any import library. However, there is one function of an import library that cannot be duplicated otherwise, and that is the ability to provide aliases for symbol names. This allows you to do things like rename functions in the actual library without affecting callers/users that use the old name. It also comes in very handy when reconciling differences in stdcall function decoration when trying to mix code between different vendors' toolchains. PE has no means of explicit symbol versioning. Shared library versioning works on the basis of choosing an appropriate filename for the library, i.e. libfoo-n.dll. This should happen automatically when you use -version-info appropriately. The import library thus also provides one further function that makes it very handy -- it functions analogously to the foo.so - foo.so.1 symlink on POSIX systems. The import library is always named just libfoo.dll.a without any version numbers, and so the linker finds it when you specify -lfoo. However, the actual name of the library may be libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the import library is the thing that selects which version of the library to link against. For example on Cygwin: $ ls -l /usr/bin/cygintl* /usr/lib/libintl* -rwxr-x---+ 1 brian Users 22K Dec 13 2001 /usr/bin/cygintl-1.dll -rwxr-x---+ 1 brian Users 37K Aug 10 2003 /usr/bin/cygintl-2.dll -rwxr-x---+ 1 brian Users 31K Nov 19 2005 /usr/bin/cygintl-3.dll -rwxr-x---+ 1 brian Users 31K Oct 22 2006 /usr/bin/cygintl-8.dll -rwxr-x---+ 1 brian Users 48K Oct 22 2006 /usr/lib/libintl.a -rwxr-x---+ 1 brian Users 30K Oct 22 2006 /usr/lib/libintl.dll.a -rwxr-x---+ 1 brian Users 800 Oct 22 2006 /usr/lib/libintl.la Here you see that there are four versions of the libintl library installed, however there is just the one import library. The name of the DLL is encoded into the import library, so this means any new code that is compiled today with -lintl will find /usr/lib/libintl.dll.a which internally specifies the filename corresponding to ABI version 8 of the library. But the other versions can still exist on disk for the sake of supporting existing binary packages of the previous ABI versions. So this works just like the symlink on POSIX that selects which version of the library all new binaries should link against (which is almost always the newest.) Brian - thanks for the concise description. Ralf - any way to may be add an addendum to the libtool docs for this, just for info? Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Brian Dessent wrote: Jason Curl wrote: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info 0:0:0 -o libtp.la -rpath /usr/local/lib version.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries Libtool won't build shared libraries on Win32/PE targets without -no-undefined in *_LDFLAGS. The text of this warning message could perhaps be clearer, because it's not telling you that you necessarily have any undefined symbols, it's telling you that you didn't assure libtool that you don't. I guess what happens if I don't say this the build will fail. I've turned it on and it looks good. I'll try and search more info later, but while I'm at it: - Why is it .dll.a and not .dll? - How is versioning information embedded in the DLL, or is the basis of the DLL hell? lib -OUT:.libs/libtp.lib version.o ../libtool: line 5973: lib: command not found I'm not sure why it's trying to use lib here, that seems wrong if you're using gcc/binutils. Possibly a configure problem? It was a configure problem. My shame! Trying to work around a Solaris 10 issue, where the ld is not found automatically I wrote an AC_PROG_LD. Unfortunately this gets used instead of the original and I never noticed if there were any conflicts. That's why it didn't matter if I used it or not in my configure.ac script, I actually had to delete it first before everything came back to normal. Sorry for the noise. It looks like I'll have to read up a lot more about shared library concepts in general to understand libtool better. Only one more problem I know of to go! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool for linking
Bob Friesenhahn wrote: On Fri, 17 Aug 2007, Jason Curl wrote: I have a system that supports shared libraries (Solaris 9). As part of some checks for 'getopt_long' I check if it exists in 'libiberty' if I can't find it in the standard system. It's there in libiberty. Now the problem occurs because there's only libiberty.a and no libiberty.so.x.y.z file. Shouldn't AC_CHECK_LIB support shared/static libraries too? Or should libtool see that there's no shared library and statically link it somehow into my library that will become shared? When libiberty is installed, it does not also install the .la file necessary for libtool to know that the library is static, and where to find the static library. Perhaps the authors of libiberty do not expect that it will be used by anyone else. Then this condition needs to be testable. I see two options: - Automatically disable shared libraries on this platform - Link statically from this library to our shared library There is no .la for this of course, I don't think it can be expected for it to be installed just for the sake of libtool. Almost every library on my system does not have the corresponding .la. Shouldn't libtool notice it is missing and try to deduce from naming conventions at least on sane systems what the situation is? As for testing the situation, AC_CHECK_LIB makes me believe it will work. But it only works in a subset of cases (i.e. static only). I have another implementation that I can compile in but at the moment there is no indication I should use my own internal implementation (I'd rather use an external implementation where possible in the belief it's probably been better debugged). So, ideas how to work around this problem to achieve my goal? Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool for linking
Peter O'Gorman wrote: On Fri, 2007-08-17 at 13:29 +0200, Jason Curl wrote: As for testing the situation, AC_CHECK_LIB makes me believe it will work. But it only works in a subset of cases (i.e. static only). I have another implementation that I can compile in but at the moment there is no indication I should use my own internal implementation (I'd rather use an external implementation where possible in the belief it's probably been better debugged). So, ideas how to work around this problem to achieve my goal? Why not import the libiberty sources into your project and build a convenience libiberty. I'd rather use what's already installed. AC_CHECK_LIB does not check for static/shared/can be used as input by libtool, nor should it, imo. What if I come across something else that's not libiberty that has no shared library? or more likely no .la files? The autotools documentation goes to a bit of length to show how it's done without libtool. So, is there something to check if it will work shared or static or both (if it's not going to be AC_CHECK_LIB)? Then at least the user can be warned. Seeing as libtool does a lot of this in anycase, maybe something just needs to be exposed? Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool for linking
Ralf Wildenhues wrote: Then this condition needs to be testable. I see two options: - Automatically disable shared libraries on this platform - Link statically from this library to our shared library There are more options; see below. FWIW, I typically use notation that's the other way round, as I would call the situation Link statically to this library from our shared library. Just to avoid confusion. ;-) There is no .la for this of course, I don't think it can be expected for it to be installed just for the sake of libtool. Indeed. And IMHO it's libtool's job to cope with system libraries that do not ship .la files, at the very least if they weren't created by libtool. As for testing the situation, AC_CHECK_LIB makes me believe it will work. AC_CHECK_LIB checks whether you can link a program against a library, not a library against a library. Hint: try AC_CHECK_LIB with CFLAGS=-fpie on GNU/Linux/x86_64 with a static library containing non-PIC code. So, ideas how to work around this problem to achieve my goal? I suppose going by Peter's suggestion is a good idea. Otherwise read on: This libtool bug is a consequence of the setting(s) deplibs_check_method=pass_all in the libtool script. You could try setting them to test_compile. Report the inevitable bugs to bug-libtool, please, including the exact Libtool version you used, and the output of `libtool --tag=TAG --config', with TAG replaced, and of `libtool --debug --mode=link...', i.e., --debug added to the failing link command. Thanks. (IIRC I fixed a couple of test_compile bugs in HEAD a while ago.) Thanks Ralf. I'll have to find some more that describes the internals of libtool to figure out how best to use it. I'll play around with it some more. Not sure I'm reporting a bug just yet, assuming it's my limited experience with libtool for now. FWIW, there has at one time been a long, heated debate around all this. To really fix things, some work would need to be done (rather than rehashing of old arguments). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool woes
Hello, I'm having some real problems with libtool getting it to link shared libraries. I've created a very basic system that exhibits the same problems I'm seeing. At the end is a brief overview of the configure.ac and the Makefile.am's. *** Cygwin: Detects shared/static but won't build. $ ./configure checking whether the gcc linker (ld) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes ... $ make Making all in libtp make[1]: Entering directory `/cygdrive/y/tmp/libtp' make all-am make[2]: Entering directory `/cygdrive/y/tmp/libtp' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -g -O2 -MT version.lo -MD -MP -MF .deps/version.Tpo -c -o version.lo version.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -g -O2 -MT version.lo -MD -MP -MF .deps/version.Tpo -c version.c -DDLL_EXPORT -DPIC -o .libs/version.o gcc -DHAVE_CONFIG_H -I. -g -O2 -MT version.lo -MD -MP -MF .deps/version.Tpo -c version.c -o version.o /dev/null 21 mv -f .deps/version.Tpo .deps/version.Plo /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info 0:0:0 -o libtp.la -rpath /usr/local/lib version.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries lib -OUT:.libs/libtp.lib version.o ../libtool: line 5973: lib: command not found make[2]: *** [libtp.la] Error 127 make[2]: Leaving directory `/cygdrive/y/tmp/libtp' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cygdrive/y/tmp/libtp' make: *** [all-recursive] Error 1 *** Linux: Won't build shared libraries (it should be able to) $ ./configure checking whether the gcc linker (ld) supports shared libraries... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes *** FreeBSD 6.1: (works with shared/static) *** Solaris 10 w/ GCC (works with shared/static) $ AR=gar LD=gld RANLIB=granlib STRIP=gstrip MAKE=gmake ./configure *** Solaris 10 w/ SunStudio CC (works with shared/static) Tools being used: - automake-1.10 - autoconf-2.61 - libtool-1.5.24 configure.ac AC_PREREQ(2.61) AC_INIT([TestProg], [1.0.0.cvs], [EMAIL PROTECTED], [tp]) AC_CONFIG_AUX_DIR(config) AC_COPYRIGHT([GPL]) AC_REVISION([$Revision: $]) AC_CONFIG_SRCDIR(tp/main.c) AM_CONFIG_HEADER(libtp/config.h) AC_CANONICAL_BUILD AC_CANONICAL_HOST AC_CANONICAL_TARGET AM_INIT_AUTOMAKE AM_MAINTAINER_MODE AC_GNU_SOURCE AC_PROG_CC AC_HEADER_STDC AC_PROG_LIBTOOL AC_PROG_INSTALL AC_PROG_MAKE_SET AC_CONFIG_FILES([Makefile libtp/Makefile tp/Makefile]) AC_OUTPUT tp/Makefile.am == bin_PROGRAMS=tp tp_SOURCES=main.c [EMAIL PROTECTED]@/libtp tp_LDADD=../libtp/libtp.la libtp/Makefile.am = lib_LTLIBRARIES=libtp.la libtp_la_SOURCES=version.c version.h [EMAIL PROTECTED]@ libtp_la_LDFLAGS=-version-info 0:0:0 Makefile.am === ACLOCAL_AMFLAGS = -I m4 SUBDIRS = libtp tp ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
Bad posting to my own posts so soon. But I've tried a few other systems I have at hand. Jason Curl wrote: Hello, I've just switched over to using libtool instead of using static libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24. The library builds fine under Linux, but won't link under Solaris Sparc 2.10. /bin/bash ../../libtool --tag=CC --mode=link /opt/sfw/bin/gcc -DSYSCONFDIR=\/usr/local/etc\ -O0 -g -Wall -version-info 0:0:0 -lnsl -lsocket -lcurses -o liblogger.la -rpath /usr/local/lib console.lo file.lo output.lo profile.lo queue.lo serial.lo strfunc.lo tcpip.lo ipcproto.lo dbgmsg.lo appframework.lo confopts.lo netif.lo ether_ntoa.lo getline.lo strnlen.lo timersub.lo timeradd.lo /opt/sfw/bin/gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lcurses -lc -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.0: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.0.0.0 collect2: ld returned 1 exit status gmake[3]: *** [liblogger.la] Error 1 gmake[3]: Leaving directory `/net/jupiter/home/projects/LX2005.886/build/sol/liblogger/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/net/jupiter/home/projects/LX2005.886/build/sol/liblogger/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/net/jupiter/home/projects/LX2005.886/build/sol/liblogger' gmake: *** [all-recursive] Error 1 * Solaris 2.10 uses the packaged version of GCC. (fails, have to use --disable-shared for it to work) gcc (GCC) 3.4.2 * Solaris 2.10 using SunStudio 11 (cc, works) ganymede:jcurl:sol$ cc -V cc: Sun C 5.8 2005/10/13 It just dies during configure. I had to add 'LD=/usr/ccs/bin/ld AR=/usr/ccs/bin/ar'. It would be easier if configure just found these libraries on Solaris without having to explicitly set them. I'll probably write some macros to do this for me. Other than that it works. * SuSE 10.0 Linux uses a newer version. (works) gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) /bin/sh ../../libtool --tag=CC --mode=link gcc -DSYSCONFDIR=\/usr/local/etc\ -O0 -g -Wall -version-info 0:0:0 -lnsl -lncurses -o liblogger.la -rpath /usr/local/lib console.lo file.lo output.lo profile.lo queue.lo serial.lo strfunc.lo tcpip.lo ipcproto.lo dbgmsg.lo appframework.lo confopts.lo netif.lo gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o -lnsl -lncurses -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 (cd .libs rm -f liblogger.so.0 ln -s liblogger.so.0.0.0 liblogger.so.0) (cd .libs rm -f liblogger.so ln -s liblogger.so.0.0.0 liblogger.so) ar cru .libs/liblogger.a console.o file.o output.o profile.o queue.o serial.o strfunc.o tcpip.o ipcproto.o dbgmsg.o appframework.o confopts.o netif.o ranlib .libs/liblogger.a creating liblogger.la * Cygwin 1.5.24 with stuff uses an old version too (works, static only, I'll deal with that later) gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /bin/sh ../../libtool --tag=CC --mode=link gcc -DSYSCONFDIR=\/usr/local/etc\ -O0 -g -Wall -version-info 0:0:0 -lncurses -o liblogger.la -rpath /usr/local/lib console.lo file.lo output.lo profile.lo queue.lo serial.lo strfunc.lo tcpip.lo ipcproto.lo dbgmsg.lo appframework.lo confopts.lo netif.lo ether_ntoa.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries ar cru .libs/liblogger.a console.o file.o output.o profile.o queue.o serial.o strfunc.o tcpip.o ipcproto.o dbgmsg.o appframework.o confopts.o netif.o ether_ntoa.o ranlib .libs/liblogger.a creating liblogger.la (cd .libs rm -f liblogger.la ln -s ../liblogger.la liblogger.la) * FreeBSD 6.1 (works) gcc (GCC) 3.4.4 [FreeBSD] 20050518 /usr/local/bin/bash ../../libtool --tag=CC--mode=link gcc -DSYSCONFDIR=\/usr/local/etc\ -O0 -g -Wall -version-info 0:0:0 -lncurses -o liblogger.la -rpath /usr/local/lib console.lo file.lo output.lo profile.lo queue.lo serial.lo strfunc.lo tcpip.lo ipcproto.lo dbgmsg.lo appframework.lo confopts.lo netif.lo ether_ntoa.lo getline.lo strnlen.lo gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o -lncurses -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0 (cd .libs rm -f
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
Ralf Wildenhues wrote: * Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST: I've just switched over to using libtool instead of using static libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24. The library builds fine under Linux, but won't link under Solaris Sparc 2.10. [...] /opt/sfw/bin/gcc -shared .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lcurses -lc -Wl,-soname -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 ld: warning: option -o appears more than once, first setting taken ld: fatal: file liblogger.so.0: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/liblogger.so.0.0.0 collect2: ld returned 1 exit status [...] So I play around a little with the options. 1. Remove -wl,-soname That won't do good unless you also remove the argument to -soname, i.e., remove -Wl,liblogger.so.0. Could you please try merging this, i.e., instead of -Wl,-soname -Wl,liblogger.so.0 use -Wl,-soname,liblogger.so.0 and also add -v to see whether gcc happens to reorder arguments for ld? Just to be sure: the .libs directory does exist, no? The .libs directory exists. Using the recommendation -Wl,-soname,liblogger.so.0 didn't work either. but... I'm stumped. I just recompiled, and it worked. The libtool command was the same, but the command generated by libtool changed (I added something to check for 'ld' and 'ar'). /opt/sfw/bin/gcc -shared -Wl,-h -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/netif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -lcurses -lc I've got a very little idea how libtool works. The ordering of the -Wl,xx changed and so did a new option appear. The only thing I can think of is I did a configure and build with 'cc' and somehow recompiled with 'gcc' (looks plausible from my last post), or even configured on linux and built on solaris (I'm using NFS), which if it were the case, all bets are off of course. In another mail: * Cygwin 1.5.24 with stuff uses an old version too (works, static only, I'll deal with that later) Typically that's because you need to add -no-undefined. Well, I guess I need to add support specifically for Cygwin with AC_LIBTOOL_WIN32_DLL first. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Using libtool for linking
Hello, I've been testing my library now on various platforms and have come across something else that I didn't expect. I have a system that supports shared libraries (Solaris 9). As part of some checks for 'getopt_long' I check if it exists in 'libiberty' if I can't find it in the standard system. It's there in libiberty. Now the problem occurs because there's only libiberty.a and no libiberty.so.x.y.z file. Shouldn't AC_CHECK_LIB support shared/static libraries too? Or should libtool see that there's no shared library and statically link it somehow into my library that will become shared? Aside all this, any ideas how to work around the problem besides configure --disable-shared? or knowing if the library is shared or not and then changing the behaviour maybe somehow? /bin/bash ../../libtool --tag=CC--mode=link gcc -DSYSCONFDIR=\/usr/local/etc\ -O2 -Wall -version-info 0:0:0 -lnsl -lsocket -o liblogger.la -rpath /usr/local/lib console.lo file.lo output.lo profile.lo queue.lo serial.lo strfunc.lo tcpip.lo ipcproto.lo db gmsg.lo appframework.lo confopts.lo netif.lo ether_ntoa.lo getline.lo strnlen.lo timersub.lo timeradd.lo -liberty gcc -shared -Wl,-h -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0 .libs/console.o .libs/file.o .libs/output.o .libs/profile.o .libs /queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o .libs/ne tif.o .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket -liberty -lc Text relocation remains referenced against symbol offset in file optopt 0x5f8 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/../../../libiberty.a(getopt.o) optopt 0x600 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/../../../libiberty.a(getopt.o) optopt 0x8d0 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/../../../libiberty.a(getopt.o) optopt 0x8d8 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/../../../libiberty.a(getopt.o) Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
