Messages in this thread |  | | Date | Mon, 30 Oct 2000 15:15:57 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: test10-pre7 |
| |
On Tue, 31 Oct 2000, Keith Owens wrote: > > > >What would be wrong with just splitting it the other way, ie make OX_OBJS > >be the expanded (but not ordered) list? > > > >That should take care of it, no? > > usbcore.o is both multi part *and* order critical. This is a > combination that the existing "link order relies on declaration order" > kludge cannot cope with. It requires an explicit declaration of link > order, which is exactly what LINK_FIRST implements.
I don't see your point.
I'm saying that EVERYTHING should be order-critical.
It is NEVER acceptable to change the order of object files.
If the Makefile said that the ordering should be
obj-y = usb.o usbcore.o third.o last.o
then the fact that usbcore.o is a multi-part object file SHOULD NOT MATTER.
We should just link it in the order specified:
ld -r usbdrv.o $(obj-y)
No re-ordering. No expansion of multi-objs. No games. Do what the Makefile author expected.
In short, we should _remove_ all traces of stuff like
O_OBJS = $(filter-out $(export-objs), $(obj-y))
It's wrong.
We should just have
O_OBJS = $(obj-y)
which is always right.
Then we change the meaning of OX_OBJS, and instead of saying
ALL_O = $(OX_OBJS) $(O_OBJS)
we just say
ALL_O = $(O_OBJS)
and the meaning of $OX_OBJS is the _subset_ of object file that have SYMTAB objects.
This should all work pretty much as-is, with som every simple modifications to existing old-style Makefiles, and with some even simpler modifications to the new-style ones. In fact, it should remove pretty much all the ugly games that new-style files do.
And it should make all this FIRST/LAST object file mockery a total non-issue, because the whole concept turns out to be completely unnecessary.
Is there anything that makes this more complex than what I've outlined above?
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |