Re: test10-pre7

Linus Torvalds
2000-10-30T23:48:46Z

On Tue, 31 Oct 2000, Keith Owens wrote:
>
> >It is NEVER acceptable to change the order of object files.
>
> It is NEVER acceptable to change the order of object files, but only
> for those files where the developer has explicitly said what the order
> must be. In the case of USB, the developers say usb.o must be first,
> the rest can be in any order.

How much do you want to bet that this can and will change if people were
made aware of how easy ordering can be?

I think we have too many "subtle" rules already.

We should have some REALLY simple and to-the-point rules. Namely:

- object files get linked in the order specified

No ifs, buts, "except when the user doesn't care", or anything like that.
No extra new logic with fancy new names for FIRST and LAST objects. No,
that's the wrong thing.

> > ALL_O = $(O_OBJS)
> >
> >and the meaning of $OX_OBJS is the _subset_ of object file that have
> >SYMTAB objects.
>
> We do not have an automatic way of detecting SYMTAB objects, OX_OBJS is
> the only way that 2.4 kbuild can tell if an source has SYMTAB or not.

I _know_.

I'm saying that we should not care. OX_OBJS still exists, but it has
nothing to do with _linking_. It has everything to do with the build
rules.

OX_OBJS is just a list of files that have exports.

It won't affect linking. It will only affect the list of SYMTAB_OBJS,
_nothing_ more.

For example, the old-style kernel/Makefile, you'd have O_OBJS containing
signal.o and sys.o. As would OX_OBJS. They'd be in both places, because
O_OBJS would tell that yes, we want to link it into the kernel, and
OX_OBJS would tell that yes, we need to generate symtab informaiton for
the files in question.

The two things are entirely orthogonal, as far as I can see. Except
historically we've mixed them up (OX_OBJS + O_OBJS is the link-list,
O_OBJS is the symtab information). And this mixup is what the problems
come from.

Linus