Re: Building a static library consisting of libraries
Hello, On Mon, Jun 12, 2006 at 08:59:07PM +0200, Norbert Sendetzky wrote: > Let me first ask a question: Are .a libraries (libopendbx.a) static libraries > or is that only dependent on the -static flag? *.a is always a static library, AFAIK. But that was not the point of Ralf's answer. Again, I'm repeating part of Ralf's answer, in case there awas a misunderstanding: if you start using libtool, it's best to use it for all libraries, including the static one. All libtool libraries have the same extension: *.la. So please drop the line: > lib_LIBRARIES = libopendbx.a because the libtool library should contain both static and dynamic library inside. See the libtool manual for details. Have a nice day, Stepan
Re: Libraries in non-standard locations
Norbert Sendetzky wrote: > As you can see the call to libtool include the "-L /usr/lib/mysql", but the > gcc call doesn't. My Makefile.am for this lib is It is incorrect to put a space between -L and the path. Fix that and it should work fine. Brian
Libraries in non-standard locations
Hi all Another problem appeared: If someone have a library in a non-standard location, usually LDFLAGS=-L /path/to/lib is used but this doesn't seem to work: /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -L /usr/lib/mysql -o libmysqlbackend.la -rpath /usr/local/lib/opendbx -module -version-info 2:0:1 -L /usr/lib/mysql libmysqlbackend_la-mysqlbackend.lo -lmysqlclient_r -lz -ldl gcc -std=gnu99 -shared .libs/libmysqlbackend_la-mysqlbackend.o -L/home/nose/Project/opendbx/devel/backends/mysql -lmysqlclient_r -lz -ldl -Wl,-soname -Wl,libmysqlbackend.so.1 -o .libs/libmysqlbackend.so.1.1.0 /usr/bin/ld: cannot find -lmysqlclient_r collect2: ld returned 1 exit status As you can see the call to libtool include the "-L /usr/lib/mysql", but the gcc call doesn't. My Makefile.am for this lib is pkglib_LTLIBRARIES = libmysqlbackend.la libmysqlbackend_la_SOURCES = mysqlbackend.c mysqlbackend.h libmysqlbackend_la_CFLAGS = @PKGCFLAGS@ libmysqlbackend_la_LDFLAGS = -module -version-info @LIBVERSION@ -L /usr/lib/mysql libmysqlbackend_la_LIBADD = [EMAIL PROTECTED]@ and I've never fiddled around with LDFLAGS in my configure.ac. My system is Debian Etch with automake 1.9.6 but this appeared also on RHEL/CentOS 4 Thank you for any hints Norbert -- OpenPGP public key http://www.linuxnetworks.de/norbert.pubkey.asc pgp7bb4R3tzLM.pgp Description: PGP signature
Re: Building a static library consisting of libraries
On Monday 12 June 2006 12:57, Ralf Wildenhues wrote: > Mixing Libtool and non-Libtool libraries isn't the best idea. Better to > mix libtool libraries > lib_LTLIBRARIES = libfoo.la > > and libtool static libraries > lib_LTLIBRARIES = libbar.la > libbar_la_LDFLAGS = -static > > and libtool convenience archives > noinst_LTLIBRARIES = libbaz.la Let me first ask a question: Are .a libraries (libopendbx.a) static libraries or is that only dependent on the -static flag? I ask because my understanding may be wrong, which depends on automake creating .a files if --enable-static is used. > Yes. Convenience archives get incorporated into other libraries. > Static and shared libraries get dependency information. Both the > Automake and the Libtool manual have much more information. > > If with this information you still get errors, then please show > what's going wrong in more detail (link command lines plus output, > and/or Makefile.am snippets; cut and paste is much more helpful > than describing errors; of course a reproducible example is best). My Makefile.am in lib: include_HEADERS = odbx.h lib_LTLIBRARIES = libopendbx.la libopendbx_la_SOURCES = odbxlib.c odbxlib.h odbx.c odbxdrv.h libopendbx_la_CFLAGS = @PKGCFLAGS@ libopendbx_la_CPPFLAGS = -DLIBPATH=\"$(pkglibdir)/\" libopendbx_la_LDFLAGS = -version-info @LIBVERSION@ lib_LIBRARIES = libopendbx.a libopendbx_a_SOURCES = odbxlib.c odbxlib.h odbx.c odbxdrv.h libopendbx_a_CFLAGS = @PKGCFLAGS@ libopendbx_a_CPPFLAGS = -DODBX_STATIC libopendbx_a_LDFLAGS = -static libopendbx_a_LIBADD = $(top_builddir)/backends/mysql/libmysqlstatic.la A Makefile.am of a backend: pkglib_LTLIBRARIES = libmysqlbackend.la libmysqlbackend_la_SOURCES = mysqlbackend.c mysqlbackend.h libmysqlbackend_la_CFLAGS = @PKGCFLAGS@ libmysqlbackend_la_LDFLAGS = -module -version-info @LIBVERSION@ libmysqlbackend_la_LIBADD = [EMAIL PROTECTED]@ noinst_LTLIBRARIES = libmysqlstatic.la libmysqlstatic_la_SOURCES = mysqlbackend.c mysqlbackend.h libmysqlstatic_la_CFLAGS = @PKGCFLAGS@ libmysqlstatic_la_CPPFLAGS = -DODBX_STATIC libmysqlstatic_la_LDFLAGS = -static libmysqlstatic_la_LIBADD = [EMAIL PROTECTED]@ This generates an invalid libopendbx.a which contains the libopendbx object and an invalid libmysqlstatic.la file: [EMAIL PROTECTED]:~/Project/opendbx/devel$ nm lib/libopendbx.a libopendbx_a-odbx.o: U dcgettext ... (more functions) 0110 T odbx_bind nm: libmysqlstatic.la: File format not recognized Which tells me that you are right and mixing .la and .a libraries is a bad idea. So how do I get a valid static library (libopendbx.a) which contains all objects and doesn't fail when linking against a program: make[2]: Entering directory `/home/nose/Project/opendbx/devel/test' /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -o odbxtest-static odbx-regression.o ../lib/libopendbx.a gcc -std=gnu99 -g -O2 -o odbxtest-static odbx-regression.o ../lib/libopendbx.a ../lib/libopendbx.a(libopendbx_a-odbxlib.o):(.data+0x4): undefined reference to `mysql_odbx_ops' Thanks for any help Norbert -- OpenPGP public key http://www.linuxnetworks.de/norbert.pubkey.asc pgp53hP3yyoms.pgp Description: PGP signature
recommendation for GNU make (was: GNU Autoconf test version 2.59d available)
Hello Paul, Ralf,
* Paul Eggert wrote on Wed, Jun 07, 2006 at 12:18:55AM CEST:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > The sub-sentence I consider to be wrong is this:
> >
> > INSTALL now suggests VPATH builds (e.g., "sh ../srcdir/configure")
> > only if you use GNU make.
>
> This is merely a sentence taken from the NEWS file for Autoconf. It
> isn't a constraint on Autoconf's (or Automake's) behavior; it's not
> even part of the documentation proper.
>
> I think your real beef here is with the documentation, not with the
> news bulletin about it. If so, it would be helpful to suggest
> specific wording that would improve the documentation.
I've thought a bit about this, and I agree more with Ralf Corepius'
concerns. Coreutils simply needed to adjust to limitations of portable
make, and Automake should document this more prominently.
> Here's what the documentation currently says (in the INSTALL file):
*snip*
> For example, would it be OK if we simply changed the "should"s to
> "can"s? If not, then what extra wording do you suggest? Please bear
> in mind that the wording needs to be concise, accurate, and clear to
> non-experts.
Yes, using "can" seems better. See a proposed patch below.
> By the way, I just now went through the Autoconf manual and found
> several examples containing makefile rules that won't work with
> Solaris make in a VPATH build. I got tired of looking for them, so I
> haven't prepared a patch, but my favorite was this one:
>
> f.c: if.c
> cp `test -f if.c || echo $(VPATH)/`if.c f.c
>
> This is in code that is _trying_ to be portable to Solaris make, and
> yet the expert author still messed up! I suspect that bugs are quite
> common in this area, and we will be doing non-experts a service by
> steering them away from Solaris make for VPATH builds.
Well, I think the example is out of its context. If one reads the whole
"Limitations of Make" section, one gets the correct impression of an
evolving rule that takes more and more limitations into account. I'd
agree that this isn't the best way to describe these things, as users
would do it alike and pick just the example they see together with the
issue they are currently interested in. But it's not like the section
gives wrong advice per se, it's just not as clear as it could be.
Anyway, here's the proposed patch. Can we agree on this, and finish
up this topic for now?
Cheers,
Ralf
* doc/install.texi (Compilers and Options): Weaken the
suggestion to use GNU make for VPATH builds.
Index: doc/install.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/install.texi,v
retrieving revision 1.47
diff -u -r1.47 install.texi
--- doc/install.texi4 Jun 2006 07:38:29 - 1.47
+++ doc/install.texi12 Jun 2006 16:31:46 -
@@ -104,13 +104,13 @@
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
-own directory. To do this, you should use @acronym{GNU} @command{make}.
+own directory. To do this, you can use @acronym{GNU} @command{make}.
@command{cd} to the directory where you want the object files and
executables to go and run the @command{configure} script.
@command{configure} automatically checks for the source code in the
directory that @command{configure} is in and in @file{..}.
-With a [EMAIL PROTECTED] @command{make}, you should compile the package for one
+With a [EMAIL PROTECTED] @command{make}, it is safer to compile the package
for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use @samp{make distclean}
before reconfiguring for another architecture.
Re: AM_CFLAGS usage
Hello Norbert, * Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 06:42:15PM CEST: > > Ehm, where do I find the documentation to config.site? Oh, sorry, I forgot to mention that config.site is an Autoconf feature. Its manual has the information. (The current manual isn't online, but let's hope that changes next week...) Cheers, Ralf
Re: AM_CFLAGS usage
On Monday 12 June 2006 12:53, Ralf Wildenhues wrote:
> : ${CFLAGS='-Wall -ansi -pedantic'}
>
> before AC_PROG_CC in configure.ac. Users with non-GCC compilers won't
> like you because they will have to set CFLAGS to override this, and
> users (with any kind of compiler) won't like you because you take away
> the default (set -g if possible, add -O2 if possible) setting they
OK, not the best option ;-)
> FWIW, I prefer that packages don't override CFLAGS at all. For specific
> settings, I keep a long-term build tree with a working config.status
> file (and of course a config.cache as well) around. Or a config.site
> file (if you don't know what this is, read up on it in the Autoconf
> manual).
Ehm, where do I find the documentation to config.site? I couldn't find it in
the automake manual
http://sources.redhat.com/automake/automake.html
and in the autobook is only a short notice about this
http://sources.redhat.com/autobook/autobook/autobook_281.html
Google does also not reveal any useful information on the first pages.
Norbert
--
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc
pgpYjcZMRwCrQ.pgp
Description: PGP signature
Re: Target-specific flags not working
* Daniel Haude wrote on Mon, Jun 12, 2006 at 03:31:47PM CEST: > On Fri, 09 Jun 2006 14:16:57 +0200, Stepan Kasal <[EMAIL PROTECTED]> wrote: > > > I tried to reproduce your problem with Automake 1.9.5 and did not > >succeed either. > > Thanks for your reply. I don't know what you mean by "either", since yours > is the only reply I received. Presumably because of some spam trap gone insane somewhere on the way between me and you. http://lists.gnu.org/archive/html/automake/2006-06/msg00033.html Cheers, Ralf
Re: Target-specific flags not working
On Fri, 09 Jun 2006 14:16:57 +0200, Stepan Kasal <[EMAIL PROTECTED]> wrote: Hello, I tried to reproduce your problem with Automake 1.9.5 and did not succeed either. Thanks for your reply. I don't know what you mean by "either", since yours is the only reply I received. But anyway I was able to track this problem down to an automake version issue after all. Not having really understood the autotools stuff I'm using the files that Glade-2 provided me with (which originally are version 1.4), and there I noticed that I had to start a bit earlier in the build process to actually get the new Makefile built. And for that I had to use both aclocal-1.9 and automake-1.9. Now everything works. Thanks, --Daniel
Re: Building a static library consisting of libraries
Hello Norbert,
* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 12:02:06PM CEST:
>
> I ran into a rather tricky problem, but let me explain a little bit more in
> detail first:
>
> I've created a library (opendbx, a unified database layer) which uses backend
> libraries (like libmysqlbackend.so) to interface the native database library
> (libmysqlclient.so).
>
> Now I want to create a static libopendbx.a which contains the main library
> and
> all backend libraries. The problem is that I have to compile the all objects
> twice, once with libopendbx_la_LDFLAGS="-module -version 1:0:0" and a second
> time with libopendbx_a_CPPFLAGS="-ODBX_STATIC" and binding them to a single
> library fails.
Mixing Libtool and non-Libtool libraries isn't the best idea. Better to
mix libtool libraries
lib_LTLIBRARIES = libfoo.la
and libtool static libraries
lib_LTLIBRARIES = libbar.la
libbar_la_LDFLAGS = -static
and libtool convenience archives
noinst_LTLIBRARIES = libbaz.la
> Building the static libraries individually works but binding the libopendbx
> object with the libXXXbackend.a libraries fails (nm tells me that the file
> format for the backends is unknown). If I list the object files in
> libopendbx_a_LIBADD instead, it works but it contains no dependency
> information about the native libraries. So I've tried to build separate
> static backend libraries (libXXXstatic.la) with dependency informations
> instead, but linking fails also miserably ("ar cru" can only handle objects).
>
> The big question now: Is there a way to get around this?
Yes. Convenience archives get incorporated into other libraries.
Static and shared libraries get dependency information. Both the
Automake and the Libtool manual have much more information.
If with this information you still get errors, then please show
what's going wrong in more detail (link command lines plus output,
and/or Makefile.am snippets; cut and paste is much more helpful
than describing errors; of course a reproducible example is best).
Cheers,
Ralf
Re: AM_CFLAGS usage
* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 11:06:36AM CEST:
> On Monday 12 June 2006 10:28, Ralf Corsepius wrote:
> > > > Note though that
> > > > -Wall -ansi -pedantic
> > > >
> > > > is pretty GCC specific, and will make many other compilers barf
> > > > heavily. So if your package targets portability, it'd be nice
> > > > to allow your users to override these flags (preferably by
> > > > ./configure CFLAGS='...').
> > >
> > > How can I do this?
> >
> > NOTE: CFLAGS !!
> Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him
> correctly.
Yes. Maybe this should be in a FAQ or so: you can put
: ${CFLAGS='-Wall -ansi -pedantic'}
before AC_PROG_CC in configure.ac. Users with non-GCC compilers won't
like you because they will have to set CFLAGS to override this, and
users (with any kind of compiler) won't like you because you take away
the default (set -g if possible, add -O2 if possible) setting they
expect from packages using Autoconf. (I first through of
http://lists.gnu.org/archive/html/automake/2005-09/msg00108.html but
that tackles a slightly different problem setting.)
FWIW, I prefer that packages don't override CFLAGS at all. For specific
settings, I keep a long-term build tree with a working config.status
file (and of course a config.cache as well) around. Or a config.site
file (if you don't know what this is, read up on it in the Autoconf
manual).
Cheers,
Ralf
Building a static library consisting of libraries
Hi all
I ran into a rather tricky problem, but let me explain a little bit more in
detail first:
I've created a library (opendbx, a unified database layer) which uses backend
libraries (like libmysqlbackend.so) to interface the native database library
(libmysqlclient.so).
Now I want to create a static libopendbx.a which contains the main library and
all backend libraries. The problem is that I have to compile the all objects
twice, once with libopendbx_la_LDFLAGS="-module -version 1:0:0" and a second
time with libopendbx_a_CPPFLAGS="-ODBX_STATIC" and binding them to a single
library fails.
Building the static libraries individually works but binding the libopendbx
object with the libXXXbackend.a libraries fails (nm tells me that the file
format for the backends is unknown). If I list the object files in
libopendbx_a_LIBADD instead, it works but it contains no dependency
information about the native libraries. So I've tried to build separate
static backend libraries (libXXXstatic.la) with dependency informations
instead, but linking fails also miserably ("ar cru" can only handle objects).
The big question now: Is there a way to get around this?
Thanks for any suggestions
Norbert
--
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc
pgpTcNKalokHW.pgp
Description: PGP signature
Re: AM_CFLAGS usage
On Monday 12 June 2006 10:28, Ralf Corsepius wrote: > > > Note though that > > > -Wall -ansi -pedantic > > > > > > is pretty GCC specific, and will make many other compilers barf > > > heavily. So if your package targets portability, it'd be nice > > > to allow your users to override these flags (preferably by > > > ./configure CFLAGS='...'). > > > > How can I do this? > > NOTE: CFLAGS !! > > Not using AM_CFLAGS=-Wall -ansi -pedantic > > and > ./configure CFLAGS="-Wall -ansi -pedantic" > > is what Ralf W. is referring to. Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him correctly. If rewrite my files to support only ./configure CFLAGS="-Wall -ansi -pedantic" these flags are never set by default if only ./configure is called. Norbert -- OpenPGP public key http://www.linuxnetworks.de/norbert.pubkey.asc pgp5924OffuBx.pgp Description: PGP signature
Re: AM_CFLAGS usage
On Mon, 2006-06-12 at 10:16 +0200, Norbert Sendetzky wrote: > Hi Ralf > > > > Norbert Sendetzky wrote: > > > > This works, but as soon as I move AM_CFLAGS to the Makefile.am in the > > > > parent directory, they aren't set any more. Is this the way it was > > > > intended and the only way to set them globally is to AC_SUBST them or > > > > is there something wrong in my files? > > > > Besides the information Marc already gave you, what's wrong with > > globally setting it by AC_SUBSTing? You can still override it per > > Makefile.am. > > > > Note though that > > -Wall -ansi -pedantic > > > > is pretty GCC specific, and will make many other compilers barf > > heavily. So if your package targets portability, it'd be nice > > to allow your users to override these flags (preferably by > > ./configure CFLAGS='...'). > > How can I do this? NOTE: CFLAGS !! Not using AM_CFLAGS=-Wall -ansi -pedantic and ./configure CFLAGS="-Wall -ansi -pedantic" is what Ralf W. is referring to. > According to the docs, AM_CFLAGS will be overwritten by package specific > flags > but not by flags provided by the user. Nope. CFLAGS and AM_CFLAGS are being concatenated inside of a Makefile using AM_CFLAGS. Ralf
Re: AM_CFLAGS usage
Hi Ralf > > Norbert Sendetzky wrote: > > > This works, but as soon as I move AM_CFLAGS to the Makefile.am in the > > > parent directory, they aren't set any more. Is this the way it was > > > intended and the only way to set them globally is to AC_SUBST them or > > > is there something wrong in my files? > > Besides the information Marc already gave you, what's wrong with > globally setting it by AC_SUBSTing? You can still override it per > Makefile.am. > > Note though that > -Wall -ansi -pedantic > > is pretty GCC specific, and will make many other compilers barf > heavily. So if your package targets portability, it'd be nice > to allow your users to override these flags (preferably by > ./configure CFLAGS='...'). How can I do this? According to the docs, AM_CFLAGS will be overwritten by package specific flags but not by flags provided by the user. Thanks Norbert -- OpenPGP public key http://www.linuxnetworks.de/norbert.pubkey.asc pgpL8sGQvKzJd.pgp Description: PGP signature
