headers
Blair Sadewitz | 4 May 2007 04:55
Picon

using mknative

I'd like to see how gcc 4.2 fares inside the tree, but I'm unsure of
exactly how to go about this.
Should I do a cvs merge in my local repository and then follow the
instructions in README.mknative, or is there something else that has
to be done as well?

Regards,

--Blair
Permalink | Reply | 1 comment |
headers
matthew green | 4 May 2007 06:26
Picon
Favicon

re: using mknative


   I'd like to see how gcc 4.2 fares inside the tree, but I'm unsure of

cool. :-)

   exactly how to go about this.
   Should I do a cvs merge in my local repository and then follow the
   instructions in README.mknative, or is there something else that has
   to be done as well?

also see src/doc/3RDPARTY's gcc entry.  between those two
it should cover pretty much everything.

at the very least i know of the following issue:

	- needs gmp

	- needs mpfr

but i haven't played around with it yet to fully understand
how they are used or needed.

let me know how it goes...

also, have you considered EXTERNAL_TOOLCHAIN?  it may allow
a significant portion of the work to be done with gcc that
is built externally.

.mrg.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blair Sadewitz | 15 May 2007 18:15
Picon

questions re: mknative and gcc 4.2.0

I'm trying to get gcc 4.2.0 to build in-tree (it was released a day or
two ago).  I'm wondering:

--Would building it without libgomp be OK?
--For libdecnumber and/or libgomp, which directories do I have to
create in my source tree?  That is, would libdecnumber go under
gnu/usr.bin/gcc4 and gnu/lib/libdecnumber, or just the former?  How
about libgomp?

Other than this, I've gotten everything to go OK, e.g. libdecnumber
builds properly and is used as a dependency, up until making includes
for libstdc++ (at the last step of mknative).  I'll address that on
the list if necessary, as I'd like to make sure I'm addressing these
two new libraries properly first.

Regards,

--Blair
Permalink | Reply | 1 comment |
headers
matthew green | 16 May 2007 01:56
Picon
Favicon

re: questions re: mknative and gcc 4.2.0


   --Would building it without libgomp be OK?

at least initially we don't need to support it.  people who
really need it can build their own for now... if it is not
a big deal to support, do it.

   --For libdecnumber and/or libgomp, which directories do I have to
   create in my source tree?  That is, would libdecnumber go under
   gnu/usr.bin/gcc4 and gnu/lib/libdecnumber, or just the former?  How
   about libgomp?

they both belong in gnu/lib.

   Other than this, I've gotten everything to go OK, e.g. libdecnumber
   builds properly and is used as a dependency, up until making includes
   for libstdc++ (at the last step of mknative).  I'll address that on
   the list if necessary, as I'd like to make sure I'm addressing these
   two new libraries properly first.

thanks for looking at this.

.mrg.
Permalink | Reply | 0 comments |
headers
Masao Uebayashi | 24 May 2007 15:12
Picon
Gravatar

Re: INSTALLSETS

Forgot this.

Index: Makefile
===================================================================
RCS file: /src/netbsd/cvsroot/src/Makefile,v
retrieving revision 1.247
diff -u -r1.247 Makefile
--- Makefile	6 Mar 2007 21:56:47 -0000	1.247
+++ Makefile	24 May 2007 12:57:00 -0000
 <at>  <at>  -283,7 +283,7  <at>  <at> 
 .endif
 .endif
 	${MAKEDIRTARGET} distrib/sets installsets \
-	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=
+	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=${INSTALLSETS}
 	${MAKEDIRTARGET} . postinstall-check DESTDIR=${INSTALLWORLDDIR}
 	 <at> echo   "make ${.TARGET} started at:  ${START_TIME}"
 	 <at> printf "make ${.TARGET} finished at: " && date
Permalink | Reply | 2 comments |
headers
Masao Uebayashi | 24 May 2007 15:00
Picon
Gravatar

INSTALLSETS

This makes INSTALLSETS parameter work as intended (I believe).  With
this I can install only specified sets as

	% ./build.sh ... -V INSTALLSETS="base etc" install=/

Comments?

Masao
Permalink | Reply | 3 comments |
headers
Alan Barrett | 28 May 2007 17:26
Gravatar

Re: INSTALLSETS

On Thu, 24 May 2007, Masao Uebayashi wrote:
>  	${MAKEDIRTARGET} distrib/sets installsets \
> -	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=
> +	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=${INSTALLSETS}

I think it needs a :Q modifier, as in INSTALLSETS=${INSTALLSETS:Q},
because INSTALLSETS is very likely to contain spaces.

--apb (Alan Barrett)
Permalink | Reply | 1 comment |
headers
Luke Mewburn | 29 May 2007 06:07
Picon

Re: INSTALLSETS

On Mon, May 28, 2007 at 05:26:38PM +0200, Alan Barrett wrote:
  | On Thu, 24 May 2007, Masao Uebayashi wrote:
  | >  	${MAKEDIRTARGET} distrib/sets installsets \
  | > -	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=
  | > +	    INSTALLDIR=${INSTALLWORLDDIR:U/} INSTALLSETS=${INSTALLSETS}
  | 
  | I think it needs a :Q modifier, as in INSTALLSETS=${INSTALLSETS:Q},
  | because INSTALLSETS is very likely to contain spaces.

Masao's proposed change (with Alan's change if necessary)
looks sensible to me.
Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 30 May 2007 00:02

HEADS UP: static libraries and FORTIFY_SOURCE

[Apologies for not giving more notice/warning about turning on
 FORTIFY_SOURCE for some system libraries at the time of my commit; it's
 clear to me now that the implications for 3rd-party code were considerably
 greater than I mistakenly expected]

A few days ago, I turned on the "fortify source" (argument length checking
on memory and string copy and set functions) for those system libraries
which handle network data or have a history of data-driven bugs (or, of
course, in many cases, both).  For various technical reasons I didn't
turn it on for libc, but this didn't limit the scope of the resulting
inter-library dependencies on libssp as much as one might think.

For dynamic libraries, the dependencies don't cause any problem: they
are automatically handled by the runtime linker.  But for programs that
are statically linked to a library which was built with FORTIFY_SOURCE,
this imposes a requirement to link to libssp.  This kind of implicit
dependency between static libraries is one reason an increasing number
of Unixy operating systems have deprecated static linkage, but though
NetBSD links the whole system static by default, that would be a rather
dramatic step to take at this time.

The issue shows up most obviously as undefined symbols in programs in
pkgsrc that build with -static (though they often don't need to).

After examining the problem at a bit more length I think the right
solution is to move the FORTIFY_SOURCE support we currently have in
libssp into libc.  The increase in size of the dynamic libc will be
approximately 8 kilobytes, and, of course, static programs that don't
use the functions in question won't grow at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 30 May 2007 00:05

Re: HEADS UP: static libraries and FORTIFY_SOURCE

On Tue, May 29, 2007 at 06:02:21PM -0400, Thor Lancelot Simon wrote:
>
> of Unixy operating systems have deprecated static linkage, but though
> NetBSD links the whole system static by default, that would be a rather

Heh.  I meant, "NetBSD links the whole system dynamic by default," of
course.

Thor
Permalink | Reply | 0 comments |

Gmane