Date: Fri, 10 May 2002 13:43:01 -0400 From: Mikhail Teterin <mi+mx@aldan.algebra.com> To: Terry Lambert <tlambert2@mindspring.com>, Mikhail Teterin <mi@corbulon.video-collage.com> Cc: current@FreeBSD.org Subject: Re: does the order of .a files matter? Message-ID: <200205101343.01636.mi%2Bmx@aldan.algebra.com> In-Reply-To: <3CDBFA7E.A2A1F09F@mindspring.com> References: <200205101233.g4ACXctb041093@corbulon.video-collage.com> <3CDBFA7E.A2A1F09F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 10 May 2002 12:51 pm, Terry Lambert wrote: = 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". It is not my code. = 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. Thanks, this makes sense. = ... = = For my information: Why didn't you take John De Bowsky's advice to: = = ld $objlist `lorder $liblist | tsort -q` I tried that before I asked on the mailing list the first time. It did reduce the number of the undefined symbols, but not to zero. = ??? 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. It would probably be quite beneficial if you dropped this paternalistic attitude. "Pain high enough"... Please... = 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? [The term "holy crusade" does not help either -- it is not even paternalistic, just plain non-sense...] Tsort is ALREADY incorporated into ld in some shape, because object files on command line or within one .a CAN be misordered. All I ask, is why the collections of object files provided by different static libs are/can not be treated as one big collection. = 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. Of course. Does not seem like it will come to this, however. = 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. Hmm, no. The only reliable option is to either build a "library of all libraries" or link the the object files into the executable directly. This, BTW, shows how inconsistent the current situation is -- the linker does not mind misordered object files, but is very picky about the order of static libraries (shared ones are can be misordered too, AFAIK). I don't see how one can sincerely defend its lack of what still appears to be a missing feature. = By "the tools people", I mean our linker vendor, the Free Software = Foundation... not anyone in the FreeBSD Project. Ok. Thanks for the pointer. = 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. Many thanks to them. -mi -- Как, Вы разве без шпаги пришли? 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?200205101343.01636.mi%2Bmx>