* Transitive Linking fails @ 2010-03-15 17:28 Erik Rull 2010-03-15 19:17 ` John (Eljay) Love-Jensen 2010-03-16 15:57 ` Ian Lance Taylor 0 siblings, 2 replies; 5+ messages in thread From: Erik Rull @ 2010-03-15 17:28 UTC (permalink / raw) To: gcc-help Hi all, I want to do the following: dir1/*.o dir2/libx.so -> dir3/liby.so where dir2/libx.so is statically linked (using -static in the linker command). It seems to work until the liby.so is linked against other code: dir4/*.o dir3/liby.so -> dir5/app There, the linker complains that it doesn't know anything about dir2/libx.so, but I want this lib to be statically linked into the liby.so so that no application needs to care about where the object code from libx.so comes from. What is my fault here? Any ideas? Best regards, Erik ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Transitive Linking fails 2010-03-15 17:28 Transitive Linking fails Erik Rull @ 2010-03-15 19:17 ` John (Eljay) Love-Jensen 2010-03-18 0:50 ` Erik Rull 2010-03-16 15:57 ` Ian Lance Taylor 1 sibling, 1 reply; 5+ messages in thread From: John (Eljay) Love-Jensen @ 2010-03-15 19:17 UTC (permalink / raw) To: Erik Rull, GCC-help Hi Erik, I think you need to do it this way: dir1/*.o dir2/libx.a -> dir3/liby.so The point to -static is to prefer libx.a rather than libx.so when you ask for -lx. By specifying dir2/libx.so, you are bypassing the -static facility because you are using an explicitly named library. HTH, --Eljay ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Transitive Linking fails 2010-03-15 19:17 ` John (Eljay) Love-Jensen @ 2010-03-18 0:50 ` Erik Rull 2010-03-18 12:45 ` John (Eljay) Love-Jensen 0 siblings, 1 reply; 5+ messages in thread From: Erik Rull @ 2010-03-18 0:50 UTC (permalink / raw) To: John (Eljay) Love-Jensen; +Cc: GCC-help Hi John, John (Eljay) Love-Jensen wrote: > dir1/*.o dir2/libx.a -> dir3/liby.so > > The point to -static is to prefer libx.a rather than libx.so when you ask > for -lx. Well, the linking itself was now fine, but I've got new problems in parts of the software that do not use parts of the library. When I link the .o files directly into the shared object, then I have no problem, the software runs fine then. I've built the lib using $(AR) rcs libx.a obj1.o obj2.o where $(AR) put out "ar" > HTH, > --Eljay > As far as I understood it these two commands should result in the same file: (with the command above) $(LD) (shared object options) libshared.so libx.a obj5.o obj6.o and $(LD) (shared object options) libshared.so obj1.o obj2.o obj5.o obj6.o right or not? If not what must be done to make these two lines behaviour equivalent? or must I take -static -lx? Best regards, Erik ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Transitive Linking fails 2010-03-18 0:50 ` Erik Rull @ 2010-03-18 12:45 ` John (Eljay) Love-Jensen 0 siblings, 0 replies; 5+ messages in thread From: John (Eljay) Love-Jensen @ 2010-03-18 12:45 UTC (permalink / raw) To: Erik Rull; +Cc: GCC-help Hi Erik, > Well, the linking itself was now fine, but I've got new problems in parts of the software that do not use parts of the library. That sounds odd and unexpected to me. > When I link the .o files directly into the shared object, then I have no problem, the software runs fine then. > I've built the lib using > $(AR) rcs libx.a obj1.o obj2.o > where $(AR) put out "ar" That looks good. > As far as I understood it these two commands should result in the same file: > $(LD) (shared object options) libshared.so libx.a obj5.o obj6.o > and > $(LD) (shared object options) libshared.so obj1.o obj2.o obj5.o obj6.o > right or not? No, not right. For the libx.a file, the linker will only pull over the items from the libx.a that are associated with unresolved symbols. Since the files are processed in order (left-to-right), as specified on the command-line, the libx.a is processed first. When the libx.a is processed, at that time there are no unresolved symbols, so nothing will be copied out of the libx.a archive. > If not what must be done to make these two lines behaviour equivalent? Try this: $(LD) (shared object options) libshared.so obj5.o obj6.o libx.a However... If you really, really, really want everything included from the libx.a into libshared.so: $(LD) (shared object options) libshared.so obj5.o obj6.o --whole-archive libx.a --no-whole-archive However, I discourage that approach. Instead I suggest you extract out all the .o files from the libx.a, and put them on the link line explicitly: $(AR) x libx.a obj1.o obj2.o $(LD) (shared object options) libshared.so obj5.o obj6.o obj1.o obj2.o > or must I take -static -lx? Even if you use -static -lx, the order is still important and must appear after your object files (*.o). Also, you need to "undo" the static state after your library parameters, otherwise the static state is still in effect for any implicit libraries. (In such a situation people might say, "Why does my libshared.so go from 17 KB to 200 MB with the -Bstatic directive?") $(LD) (shared object options) libshared.so obj5.o obj6.o -Bstatic -lx -Bdynamic Sincerely, --Eljay ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Transitive Linking fails 2010-03-15 17:28 Transitive Linking fails Erik Rull 2010-03-15 19:17 ` John (Eljay) Love-Jensen @ 2010-03-16 15:57 ` Ian Lance Taylor 1 sibling, 0 replies; 5+ messages in thread From: Ian Lance Taylor @ 2010-03-16 15:57 UTC (permalink / raw) To: Erik Rull; +Cc: gcc-help Erik Rull <erik.rull@rdsoftware.de> writes: > dir1/*.o dir2/libx.so -> dir3/liby.so where dir2/libx.so is statically > linked (using -static in the linker command). You can't statically link a shared object. Ian ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-03-18 11:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-15 17:28 Transitive Linking fails Erik Rull 2010-03-15 19:17 ` John (Eljay) Love-Jensen 2010-03-18 0:50 ` Erik Rull 2010-03-18 12:45 ` John (Eljay) Love-Jensen 2010-03-16 15:57 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).