Re: C flags and headers in a C library
Noah Misch wrote: > Add a line like this to Makefile.am: > > AM_CFLAGS = $(MINGA_CFLAGS) > > or simply: > > AM_CFLAGS = -ansi -pedantic -Wall > > Note that it's usually unwise to add such flags unconditionally; many > compilers > do not support them. Thanks very much. I hadn't thought about the compiler issue; can you suggest a conditional check that would sort this out? Alternatively, is there some way I can just request the extra flags when calling autoreconf or the ./configure script? After all, it's only really necessary for me, as the code author, to check ANSI compatibility. I thought of placing a line in configure.ac, CFLAGS="$USER_CFLAGS $CFLAGS" where USER_CFLAGS is meant to be defined via ./configure USER_CFLAGS="..." but I'm not sure that is an elegant or safe solution. > Adding such a line is generally correct. It sounds as though the headers do > not > exist under the names you call them from Makefile.am. If you do generate > these > headers during your build process, look at documentation for BUILT_SOURCES in > the GNU Automake manual. I think you're right: the main Makefile.am was unable to see the existence of the files, which are in a subdirectory. But I was able to include them via the sublibrary makefiles. A last query. When building a library, is it advisable to link to other libraries when compiling? e.g. if my library uses functions from libmath, should I compile my library with -lm, or leave that to the person creating executables linked with my library? Thanks again for all the advice and suggestions, -- Joe ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: C flags and headers in a C library
On Thu, May 03, 2007 at 01:02:49PM +0100, Joseph Wakeling wrote: > Noah Misch wrote: > > AM_CFLAGS = -ansi -pedantic -Wall > > > > Note that it's usually unwise to add such flags unconditionally; many > > compilers > > do not support them. > > Thanks very much. I hadn't thought about the compiler issue; can you > suggest a conditional check that would sort this out? You can do something like this: configure.ac: save_CFLAGS=$CFLAGS CFLAGS="$CFLAGS -Wall" AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [MINGA_CFLAGS=-Wall]) CFLAGS=$save_CFLAGS AC_SUBST([MINGA_CFLAGS]) Makefile.am: AM_CFLAGS = $(MINGA_CFLAGS) This is reasonable for `-Wall', but I don't recommend it for `-ansi' or `-pedantic', since the compiler may accept the option but then reject your code due to a pedantic language check. While useful for development, that does not aid those who simply want to build and use your library. > Alternatively, is there some way I can just request the extra flags when > calling autoreconf or the ./configure script? After all, it's only > really necessary for me, as the code author, to check ANSI compatibility. You can just `./configure CFLAGS='-g -O2 -ansi -pedantic -Wall' for your own development. > A last query. When building a library, is it advisable to link to other > libraries when compiling? e.g. if my library uses functions from > libmath, should I compile my library with -lm, or leave that to the > person creating executables linked with my library? You should link your own library to its dependencies. This is essential when building on systems that forbid undefined symbols in libraries. Furthermore, when others use Libtool to link with your library, Libtool will link in those dependencies automatically. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Question regarding interdependent convenience libraries
>> Is libtool or the underlying linker smart enough to recognize and >> ignore the duplicate libraries? > > I think that the content of convenience libraries is extracted into > individual .o files prior to being used for linkage. This is true if the linker doesn't have a functionality similar to --whole-archive, and if the resulting output is a library, rather than a program. > They are not used for > linking like traditional archive libraries. This means that any duplicates > would result in individual .o files being overwritten prior to use. This is not true. When extracted, object files with identical names are renamed. I think it might be helpful to distinguish two cases: 1) Multiple *different* object files with the same name 2) Multiple occurrences of the *same* object file Is it possible that renaming occurs in case #1 to disambiguate the object files, but for case #2 the object files get the same name or the duplicates are otherwise ignored? I ask because I tried building a program using two different approaches: 1) the approach I described previously, which results in linking a program with multiple convenience archives that contain intersecting sets of objects, and 2) an approach in which the program is linked with convenience archives that contain mutually disjoint sets of objects. Neither approach produced linker errors and the resulting programs appear to be exactly the same. It seems that either libtool or the underlying linker somehow ignored duplicate objects found in different convenience libraries. Unfortunately, I cannot find this behavior documented anywhere, which makes me nervous that the behavior is undefined and I am just getting lucky. > In other words non-fatal for building applications. However, if you > build installed libraries based on these convenience libraries, you > could run into trouble if two installed libraries included some of the > same objects. The rule of thumb is to put each convenience archive in at most one library, and never into a program. (Convenience archives do not end up as whole in a program; if that is not a problem for you, then that part should be ok.) I read this (or something similar) in the libtool documentation, and I find the program part a bit confusing. I recall reading that a program can also double as a library (with contained symbol table, etc.). Is that the case where linking with a convenience archive should be avoided? If you would please elaborate on this, I would be most appreciative. > A radically-different solution is to use a non-recursive Makefile scheme. > This eliminates the need for convenience libraries entirely and speeds up > the build. Automake does support this reasonably well and you can use > Makefile includes to still keep Makefile fragments alongside the sources. > However, the Makefile fragments require "namespacing" as if everything is > referenced from the top level Makefile (which they will be). This is a good suggestion. I am familiar with the criticism of recursive make, and I'm currently evaluating some non-recursive approaches to see if they'll work for me. For example, this non-recursive automake template looks promising: http://svn.ademar.org/code/trunk/autotools-build_system-template/ Thanks, Scott ___ http://lists.gnu.org/mailman/listinfo/libtool
lt_dlforeachfile
I'm a bit unclear on what I can expect about the filenames passed to the callback. I'm using libtool 1.5.22 and whatever libltdtl that comes with, and have found that it seems to pass basenames, suitable for use with lt_dlopenext, but the documentation is unclear on whether I can rely on this behaviour; it seems quite sensible, since each module in a directory typically comes in static and dynamic flavours and a bunch of links, and I wouldn't want to get passed every single filename. Either way, the documentation could use some clarification on this point, unless I've misread it. -- http://rrt.sc3d.org/ | certain, a. insufficiently analysed ___ http://lists.gnu.org/mailman/listinfo/libtool
