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

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

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.

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

> > I'm not certain about libmalloc from src/gnu/lib/Makefile and how it is 
> > used.
> 
> I intend to visit this one shortly as I believe it may actually be no
> longer used..
> 
> > * c++
> > The c++ has to come after the atf libaries because the aft framework is in 
> > c++.
> 
> I wonder if you meant before the atf libraries?

Yes, sorry that what I meant.

> 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++.

Regards,
Bernd