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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to