Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: remove external/lib/Makefile and crypto/external/lib/Makefile
On Thu, 25 Nov 2010, Bernd Ernesti wrote:
> > Well I was busy last week but did some builds this weekend with
> > gnu/lib/Makefile also entirely removed, and all lib items referred
> > directly from lib/Makefile. my patch is attached and I can detect no
> > problems with it here
>
> As I mentioned some gcc libraries have to be added earlier.
>
> You need to move the following two directly after csu if you really want
> to move gnu/lib/Makefile into lib/Makfile.
>
> .if (${MKGCC} != "no")
> SUBDIR+= ../gnu/lib/crtstuff4
> SUBDIR+= ../gnu/lib/libgcc4
> .endif
why "have to" and "need to"? please note that
- currently gnu/lib/Makefile is not processed until after the end of
lib/Makefile
- both those directories are still processed separately in the top level
Makefile before lib/Makefile is reached (agreed: between csu and libc)
- they are really present here for the purpose of targets other than
build & install (since they must be installed to ${DESTDIR} before the
build machinery will find them)
- if you try to bypass the build machinery (eg "cd lib && make") then you
will probably refer to the host libraries which may not be what you
want. (its likely ok on a NetBSD host with same version sources..)
As I mentioned, the constraints on these items are not as strict as it may
appear, since the build machinery only refers to versions from ${DESTDIR}
> > > > In the patch I gave, it
> > > > is already after the atf libraries and does build fine that way.. in
> > > > any
> > > > case, the atf-c++ library only results in .a files which don't have
> > > > dependencies as such (I believe the dependency occurs at link stage)
> > >
> > > I haven't checked that part and only had in my mind that this c++.
> >
> > Yeah it seems so, but its easy to shuffle around afterwards if somebody
> > wants to make it an actual dependency so I'm not too worried about that
> > one at the moment
>
> Hmm, what is the problem to move then before atf?
what is the requirement to do so?
I put the atf library there because in my mind there are two influences on
Makefile order - if there is an ordering constraint, the dependent item
should be after a .WAIT dependency barrier - otherwise it should just
appear in alphabetical order.
In this case there is no ordering constraint as ATF libs claim no
dependencies, therefore alphabetical order is used..
regards,
iain
Home |
Main Index |
Thread Index |
Old Index