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
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 ___ 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; then
# The
Re: Getting filenames for libraries
Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: [SNIP] I've attached a sample of the macros if there are comments. e.g. configure.ac (only the interesting bits) [SNIP] LX_PROG_RC use AC_LIBTOOL_RC AC_CONFIG_FILES([src/rsrc.rc]) Makefile.am [SNIP] .rc.lo: $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(RC) $(RCFLAGS) $ -o $@ after AC_LIBTOOL_RC in configure you may use .. --tag=RC $(RC) .. [SNIP] windows) major=`expr $current - $age` versuffix=-$major ;; In case of make LDFLAGS=-avoid-version versuffix has to be ! [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
