Re: remove external/lib/Makefile and crypto/external/lib/Makefile

[Bernd Ernesti <netbsd%lists.veego.de@localhost>]

On Mon, Nov 22, 2010 at 07:20:12PM +0000, Iain Hibbert wrote:
> On Sat, 20 Nov 2010, Bernd Ernesti wrote:
> 
> > On Mon, Nov 15, 2010 at 04:02:40PM +0000, Iain Hibbert wrote:
> > > On Sun, 14 Nov 2010, Bernd Ernesti wrote:
> > > > If you want to move the entries from gnu/lib/Makefile into lib/Makefile 
> > > > then
> > > > this should be in a different order like the one used in 
> > > > compat/compatsubdir.mk
> > > > because all other libraries depends on some of the libraries from 
> > > > gnu/lib/Makefile:
> > > >  crtstuff4
> > > >  libgcc4
> > > > But these two libraries should not be added to src/lib/Makefile since 
> > > > they are
> > > > already handled in src/Makefile. I see no point in running the build 
> > > > target
> > > > multiple times, yes they will not really be build but it not necessary.
> > >
> > > They are of course already run multiple times and in fact are not the only
> > > libraries that reappear this way during a complete build (eg libc itself
> > > does). My proposed change does not really affect that, I think its a
> > > different issue..
> >
> > Yeah.
> 
> The main reason that they appear multiple times in the build is that they
> need to appear in the regular SUBDIR path because for example make(obj)
> proceeds in that order, even though a top-level make(build) will
> explicitly compile and install them in advance.. this means that the
> ordering in lib/Makefile and compatsubdir.mk for those items (csu,
> crtstuff4, libgcc4 and libc) is not as crucial as it would seem, since a
> make(build) from top-level does the right thing.
> 
> (and incidentally, "cd lib && make" does work fine too)
> 
> > > > Right now this it not optimal, crtstuff4 and libgcc4 should maybe 
> > > > removed
> > > > from src/gnu/lib/Makefile then add src/gnu/lib/Makefile in 
> > > > src/lib/Makefile
> > > > and remove the do-gnu-lib part from src/Makefile but I haven't thought 
> > > > about
> > > > that much.
> > >
> > > I believe some work is underway to update gcc to a later version, and
> > > perhaps that will include updating some of these and moving them to
> > > external/gpl3 ..  I was hoping that if this is the case, gnu/lib/Makefile
> > > would become mostly redundant at that time, and is why I thought it best
> > > to not modify it at this time..
> >
> > Hmm, what about leaving the include of it out of src/lib/Makefile for
> > the moment?
> 
> 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

> > > 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?

Bernd