libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding convenience libraries as aliases for objects


From: Ed Sweetman
Subject: Re: Regarding convenience libraries as aliases for objects
Date: Sat, 26 May 2007 00:23:46 -0400
User-agent: Icedove 1.5.0.10 (X11/20070328)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]