Re: Feedback on ld circular reference resolution code?

[Ted Lemon <mellon@ncd.com>]

> I would still prefer to see a feature more like what the FSF is
> requesting.  One that would essentially treat a set of libraries as a
> single library.

Sounds fine to me.   I haven't seen the request from the FSF, though.
Could I?

> One problem with my revised understanding of your patches (and please
> correct me if I am wrong) is that the libraries are researched after
> all the input files have been seen.

That's correct.

> For example, gcc on COFF or ELF requires that the crtend.o file be
> linked last, after all everything else (except a possible crtn.o)
> has been linked.  Do your patches accomodate that?

Nope.   I hadn't thought of that.   However, from what I've heard, if
I were to update my patches to do what rms is asking for, this would
satisfy your objection.   Although I do use ELF, I haven't had to use
crtend.o, so I wasn't aware that it was an issue.

> Also, adding new fields to the BFD structure itself must be avoided if
> at all possible.  I am constantly being beaten up about BFD memory
> usage, and doing a link on a large archive can open hundreds of BFD's.
> Each new four byte field in a BFD structure can lose a noticeable
> amount of memory.

Well, if we use your description (hundreds of BFDs), this would mean
at a maximum that we'd be using an additional 8k, since if you meant
over 2000 BFDs, you probably would have said ``thousands.''   I don't
mean to belittle the importance of conserving memory, but I have to
admit that I'm having trouble getting worked up about this.
Certainly it would be bad to add fields that serve no purpose, but I
think this is a weak argument against adding the feature we're talking
about.

In any case, if I can get a description of exactly what the FSF wants,
I'll be happy to modify my patch to provide a solution.   I could
probably make a guess from what's been alluded to in previous
messages, but I'd rather get it right the first time.

			       _MelloN_