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
