From: Heilpern, M. <mar...@au...> - 2006-08-24 15:41:28
|
I've solved this, but I would like to know if there's a more robust solution. =20 The problem apparently is with the order of things on the link line -- you can see I have my -l's appearing before the .o's. If I place the .o's first I don't have the unresolved references. =20 Is there a better way to do things, which doesn't result in command line ordering requirements? ________________________________ From: gum...@li... [mailto:gum...@li...] On Behalf Of Heilpern, Mark Sent: Thursday, August 24, 2006 10:36 AM To: General mailing list for gumstix users. Subject: [Gumstix-users] arm-linux-gcc application/library link issues I'm trying to link my application, which requires 3 libraries that I've built. Nothing particularly out of the ordinary, but I get unresolved references which just aren't making sense.=20 I'm using arm-linux-gcc version 3.4.5, as built from the Gumstix buildroot. Any experts in gcc/libraries out here? =20 =20 Linking my application (partial output): /opt/gumstix/build_arm_nofpu/staging_dir/bin//arm-linux-gcc -o myapp -L/usr/local/src/mytools/libs -L../platform -ldevice myapp.o myapp.o: In function `main': /root/ae_linux/application/myapp.c:138: undefined reference to `MyInitModuleStorageTable' /root/ae_linux/application/myapp.c:147: undefined reference to `MyVersion' /root/ae_linux/application/myapp.c:149: undefined reference to `MyInit' =20 ---- =20 =20 $ /opt/gumstix/build_arm_nofpu/staging_dir/bin/arm-linux/nm /usr/local/src/mytools/libs/libdevice.a | grep MyInit api_MyInit.o: 00000000 T MyInit =20 =20 ---- =20 Now, if I extract all .o's from libdevice.a and, for example, include api_MyInit.o on the link line, the unresolved reference to MyInit goes away. I believe from this that there's nothing wrong with my .o files. =20 I've tried including multiple -l's on the link command but this hasn't gotton me any closer to getting things to link. =20 Any suggestions? =20 _______________________________________________________ NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com <http://www.authentec.com>=20 |
From: Heilpern, M. <mar...@au...> - 2006-08-24 17:59:57
|
Hi Alex, Thanks for the response. My full application actually uses several statically linked libraries, and the references are occassionally circular. To date, I've managed this by including each library on the link line multiple times. Is this my only real option (short of changing them to dynamic linked libs)? Thanks again, Mark =20 -----Original Message----- From: gum...@li... [mailto:gum...@li...] On Behalf Of Alexandre Pereira Nunes Sent: Thursday, August 24, 2006 1:00 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] arm-linux-gcc application/library link issues Heilpern, Mark escreveu: > I've solved this, but I would like to know if there's a more robust=20 > solution. > =20 > The problem apparently is with the order of things on the link line -- > you can see I have my -l's appearing before the .o's. If I place the=20 > .o's first I don't have the unresolved references. > =20 > Is there a better way to do things, which doesn't result in command=20 > line ordering requirements? The linker is sensitive to object order in command line, that's not exactly unavoidable but the tricks used to contorn it may turn linking a bit slower and prone to some very rare mistakes. the recommended order is: <linker and parameters> <objects in dependency order> <libraries in dependency order> The linker solves dependencies from left to right, meaning that the objects which depends on others must come to the left of (I mean, be mentioned before) those that provides the symbols for solving these dependencies. That's specially truth for static libraries, because that's a bunch of object files with an index, and that index is checked only once. Dynamic libraries are resolved at run time, so it's mutual-dependency are not exactly dependent on the order they're passed at link time, though that may influence the lazy object resolval (If you use pthread and explictly mention libc, -lpthread should appear before -lc at least once). I suggest you write a Makefile for your program, something like: program_objects :=3D obj1.o obj2.o obj3.o # ... and so on. program_libraries :=3D -llibone -llibtwo # ... and so on program: $(program_objects) $(LD) $^ $(program_libraries) -o $@ That way you will not need to remember the correct order more than once ... - Alexandre ------------------------------------------------------------------------ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users _______________________________________________________ NOTE: The information in this message is intended for the personal and = confidential use of the designated recipient(s) named above. To the extent the = recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an = obligation of confidentiality, with AuthenTec, then this message and/or any = attachments shall be considered confidential information and subject to the confidentiality = terms of that agreement. If the reader of this message is not the intended recipient = named above, you are notified that you have received this document in error, and any = review, dissemination, distribution or copying of this message is strictly prohibited. If you = have received this document in error, please delete the original message and notify the = sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com |
From: Alexandre P. N. <al...@om...> - 2006-08-24 18:24:42
|
Heilpern, Mark escreveu: >Hi Alex, > >Thanks for the response. > >My full application actually uses several statically linked libraries, >and the references are occassionally circular. To date, I've managed >this by including each library on the link line multiple times. Is this >my only real option (short of changing them to dynamic linked libs)? > >Thanks again, >Mark > > You can also use grouping, I can't remember the syntax right now, but you start and end groups where multiple dependencies are supposed to happen, and then the linker cycles between then until all cross dependencies are resolved. This is safe as long as there is no weak symbols to be resolved in a particular order. I guess if you use gcc as a linker front end, the option would be more or less like this: gcc obj1.o obj2.o -Wl,--start-group -ltest1 -ltest2 -Wl,--end-group -o executable-name Where you put all libraries with possible cross-references between the start-group and end-group declarations Not sure the syntax is correct, but it should be close :-) - Alexandre |
From: Dave H. <dhy...@gm...> - 2006-08-24 19:20:03
|
Hi Mark, > My full application actually uses several statically linked libraries, > and the references are occassionally circular. To date, I've managed > this by including each library on the link line multiple times. Is this > my only real option (short of changing them to dynamic linked libs)? There are a couple of ways of dealing with circular references. One is to list one of the libraries multiple times. The second is to use some linkner directives: --start-group and --end-group. Now these are linker directives, not gcc directives, so you need to specify them on the gcc command line something like this: gcc foo.o -Wl,--start-group -llib1 -llib2 -llib3 -Wl,--end-group The group causes the linker to scan that group of libraries as many times as required when trying to resolve symbols. Understanding how the linker resolves symbos is worthwhile. As the linker is doing it's job, at any moment in time it has basically two lists of symbols, resolved symbols (it knows which object file they come from) and unresolved symbols The linker deals with whole object files. As an object file is added, it will satisfy some of the unresolved symbols and may add more unresolved symbols, and some of the objects unresolved symbols may already be known by the linker so it resolves those as well. The linker scans the command line fro left to right. If an object file is encountered, then the object will be added whether the linker needs any of the symbols or not. When a library is encountered, if any of the objects contained within the library satisfy some unresolved symbols then those objects will be pulled in. The library is then "forgotten" and if some future object or library requires symbols from this library then the linker doesn't "go back". Using a group causes the linker to keep scanning all of the libraries in the group until it makes a pass where no symbols are resolved, then it moves on. A well designed project will have no circular references and doesn't need to rely on using groups or listing a library more than once. If you have a particular circular reference that you'd like to remove, I'd be happy to discuss techniques for removing them. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Heilpern, M. <mar...@au...> - 2006-08-24 19:40:01
|
Thank you Alex and Dave, the library grouping method worked like a champ.=20 > A well designed project will have no circular references and doesn't need to rely on using groups or listing a library more than once. If you have a particular circular reference that you'd like to remove, I'd be happy to discuss techniques for removing them. I can rebuild the libraries that are doing this but if I make changes to them, they'll just get reverted back on me. I wasn't aware of the start/end group linker options though, so I'm happy to have learned something new today. Thanks again! _______________________________________________________ NOTE: The information in this message is intended for the personal and = confidential use of the designated recipient(s) named above. To the extent the = recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an = obligation of confidentiality, with AuthenTec, then this message and/or any = attachments shall be considered confidential information and subject to the confidentiality = terms of that agreement. If the reader of this message is not the intended recipient = named above, you are notified that you have received this document in error, and any = review, dissemination, distribution or copying of this message is strictly prohibited. If you = have received this document in error, please delete the original message and notify the = sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com |
From: Alexandre P. N. <al...@om...> - 2006-08-24 16:59:48
|
Heilpern, Mark escreveu: > I've solved this, but I would like to know if there's a more robust > solution. > > The problem apparently is with the order of things on the link line -- > you can see I have my -l's appearing before the .o's. If I place the > .o's first I don't have the unresolved references. > > Is there a better way to do things, which doesn't result in command > line ordering requirements? The linker is sensitive to object order in command line, that's not exactly unavoidable but the tricks used to contorn it may turn linking a bit slower and prone to some very rare mistakes. the recommended order is: <linker and parameters> <objects in dependency order> <libraries in dependency order> The linker solves dependencies from left to right, meaning that the objects which depends on others must come to the left of (I mean, be mentioned before) those that provides the symbols for solving these dependencies. That's specially truth for static libraries, because that's a bunch of object files with an index, and that index is checked only once. Dynamic libraries are resolved at run time, so it's mutual-dependency are not exactly dependent on the order they're passed at link time, though that may influence the lazy object resolval (If you use pthread and explictly mention libc, -lpthread should appear before -lc at least once). I suggest you write a Makefile for your program, something like: program_objects := obj1.o obj2.o obj3.o # ... and so on. program_libraries := -llibone -llibtwo # ... and so on program: $(program_objects) $(LD) $^ $(program_libraries) -o $@ That way you will not need to remember the correct order more than once ... - Alexandre |