Regarding convenience libraries as aliases for objects
In the various tutorials and documentation I've read, convenience libraries are said to be like aliases for object files that can be generated to either static or shared libs. I want to use that idea literally. My project has multiple targets that share various groups of source files. The source files are currently compiled as libtool libraries (static) and are not to be installed with the program. My intention was to use libtool to alias the object files and then link them directly (as if it was a .a) rather than pointlessly generating the .a and then linking. Mostly this is done to save space and time, since the "libs" are just a way to get around compiling duplicate copies of the objects for each bin_PROGRAM target. Of course, creating a .a duplicates the space, thus nullifying that half of the benefit for using libs during compilation. I really dont see why libtool generates .a files when they're not going to be installed. Since libtool knows the list of objects related to a ".a" lib, the generation of the .a is a waste of disk space and time. Is it possible to have my makefile retrieve a list of the objects in a given libtool library so that i can just use that variable in the LDADD of the target? Or is there a way to tell libtool to link a .la such that it directly links the .o's associated with it directly to the executable and skips the intermediate and useless generation of the .a file? my makefile.am generally looks like this: mylib_la_SOURCES = \ lots of sources mylib2_la_SOURCES = \ lots of sources mylib3_la_LIBADD = \ mylib2.la mylib3_la_SOURCES = \ lots of sources bin_PROGRAMS = \ program1 \ program2 noinst_LTLIBRARIES = \ mylib.la \ mylib2.la \ mylib3.la program1_LDADD = \ mylib1.la \ mylib3.la program1_DEPENDENCIES = \ mylib1.la \ mylib3.la program2_LDADD = \ mylib1.la \ mylib2.la program2_DEPENDENCIES = \ mylib1.la \ mylib2.la ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Regarding convenience libraries as aliases for objects
On Fri, 25 May 2007, Ed Sweetman wrote: I really dont see why libtool generates .a files when they're not going to be installed. Since libtool knows the list of objects related to a ".a" lib, the generation of the .a is a waste of disk space and time. Is it possible One reason to do this is because since libtool is based on shell scripts, it must still work within command line limits. It is quite easy for even the list of object files in one library to exceed command line limits, even if the prefixing subdirectory path is not included. to have my makefile retrieve a list of the objects in a given libtool library so that i can just use that variable in the LDADD of the target? Or is there a way to tell libtool to link a .la such that it directly links the .o's associated with it directly to the executable and skips the intermediate and useless generation of the .a file? An avenue you can look at is the "non recursive make". Automake supports this. It is perhaps not for everyone, but it allows you to avoid the need for convenience libraries entirely and since make knows all of the dependencies, there is a minimum of rebuilding for each change. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Regarding convenience libraries as aliases for objects
Bob Friesenhahn wrote:
On Fri, 25 May 2007, Ed Sweetman wrote:
I really dont see why libtool generates .a files when they're not
going to be installed. Since libtool knows the list of objects
related to a ".a" lib, the generation of the .a is a waste of disk
space and time. Is it possible
One reason to do this is because since libtool is based on shell
scripts, it must still work within command line limits. It is quite
easy for even the list of object files in one library to exceed
command line limits, even if the prefixing subdirectory path is not
included.
Sure it could die during execution, but it already can do that with
normal extremely large (many objects) la files.What you're saying is
that my combination of "libs" may expand out during final linking to be
too large for the shell or libtools or gcc that's understandable,
and i dont care. This can also happen with the way libtool currently
operates while linking a single la lib. We dont stop letting users do it
just becaues there's an upper limit. Users should be able to choose,
and use the "virtual .la" files when they can in place of noinst .a files.
to have my makefile retrieve a list of the objects in a given libtool
library so that i can just use that variable in the LDADD of the
target? Or is there a way to tell libtool to link a .la such that it
directly links the .o's associated with it directly to the executable
and skips the intermediate and useless generation of the .a file?
An avenue you can look at is the "non recursive make". Automake
supports this. It is perhaps not for everyone, but it allows you to
avoid the need for convenience libraries entirely and since make knows
all of the dependencies, there is a minimum of rebuilding for each
change.
i'm fairly sure i am non-recursive already. For the most part anyway.
My problem may be linked to the way the Makefile.am is done up. I can't
just make a rule that says, compile all cpp's to .o and link all the
ones on list1 to target1 and list2 to target2 ... all i get is
undefined references because the list of objects are in the order that i
listed the source files .
the following always results in undefined references during final
linking. Mostly i believe because the .o's are not in the correct order
of dependency. Is there a way to order them so i can retain a list to
use with LDADD for the targets? It seems increasingly unlikely that
libtool can do the job i want.
what i tried was this:remember old makefile example.
mylib_sources = \
lots of sources
mylib_objs = ${mylib_sources:.cpp=.o}
mylib2_sources = \
lots of sources
mylib2_objs = ${mylib2_sources:.cpp=.o}
mylib3_sources = \
lots of sources
mylib3_objs = \
${mylib2_objs} \
${mylib3_sources:.cpp=.o}
bin_PROGRAMS = \
program1 \
program2
program1_LDADD = \
${mylib_objs} \
${mylib3_objs}
program1_DEPENDENCIES = \
${mylib_objs} \
${mylib3_objs}
program2_LDADD = \
${mylib_objs} \
${mylib2_objs}
program2_DEPENDENCIES = \
${mylib_objs} \
${mylib2_objs}
1. I dont want shared libs, my "static libs" are not going to be
installed.
2. I dont want .a's for intermediate use, i have the .o's right there.
3. my targets use different CXXFLAGS, thus prefixing the name to all
objects created from it's SOURCE list.
4. my directory structure doesn't reflect the "libs" i want to create.
5. the "libs" i want to create depend on source outside of themselves.
So the position that they're linked matters.
6. I dont want copies of .o's with separate names
___
http://lists.gnu.org/mailman/listinfo/libtool
