Date: Fri, 10 May 2002 09:51:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mikhail Teterin <mi@corbulon.video-collage.com> Cc: current@FreeBSD.org Subject: Re: does the order of .a files matter? Message-ID: <3CDBFA7E.A2A1F09F@mindspring.com> References: <200205101233.g4ACXctb041093@corbulon.video-collage.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > > > Is there a reason for it, or this just a not-yet-implemented > > > feature? It certainly seems like the latter -- why make the user > > > jump through all the sorting/reordering hoops? > > > Generally, this won't be necessary for properly organized code. The > > code in question is organized by software layering, right, so all you > > have to do is link the libraries in order? > > In other words, your answer is: "This just a not-yet-implemented feature"? Actually, it's "it would not be necessary, if your code were organized to best common practices principles". Or more roughly "It's not a feature". > > > = You might also want to consider using -L<path> -l<library>, > > > = instead of trying to link .a's directly. > > > > > > What would this do? > > > > Make it all go through the library linking code, instead of the single > > object archive linking code. a ".a" file treated as an object is not > > the same as a library. > > What's the difference if all I have are the static libraries anyway? > I actually tried this, and had the exactly same list of allegedly > undefined symbols... You can add "-lxxx" again, and it will only pull in those things that are missing. ... For my information: Why didn't you take John De Bowsky's advice to: ld $objlist `lorder $liblist | tsort -q` ??? I pointed you at tsort myself, but didn't provide the full command line like John did because I wanted the pain to be high enough that you would fix it the right way (reorganzing your library link order and using ranlib -- ppointed you at that, too) instead of glueing over the problem. Or are you on a holy crusade to get tsort incorporated into ld, so that most of the time, it will take a lot longer to link, with exatly the same results, since all the code everywhere else on the system has already solved the link order problem the right way? I have to say that, given a choice between "make world" taking several minutes longer and you not having to reorganize your code into logical component units, vs. it taking less time to do a make world, and one programmer having to *fix* their code, I have to pick you fixing your code. Also, this is a tools problem, and the tools provide a way (even if it's ugly) to get the behaviour you want, with a single option before your objects, and another one after. If you are going to convince anyone to make the change, it's going to have to be the tools people, and they are unlikely to be willing to take a hit on their benchmarks to please you, particularly if they've already externalized command line options so that you can solve your problem less automatically. By "the tools people", I mean our linker vendor, the Free Software Foundation... not anyone in the FreeBSD Project. FreeBSD itself is *incredibly* unlikely to make a local hack to the GNU toolchain to support what you want being automatic, since David O'Brien, Peter Wemm, and others have sweat *blood* in order to get FreeBSD over to as much of the standard toolchain as humanly possible. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CDBFA7E.A2A1F09F>