odd message from ld in -current around 9.0 branchpoint
I'm trying to compile a system based on current from just before the 9.x branchpoint. during hte build I got the following message: /usr/bin/ld: this linker was not configured to use sysroots does anyone have any idea what this means in a broader context? did I misconfigure something when I built this system? Julian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On 4/29/14, 8:57 AM, Ian Lepore wrote:
On Mon, 2014-04-28 at 18:36 -0600, Warner Losh wrote:
On Apr 28, 2014, at 1:48 AM, Julian Elischer wrote:
I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make
DESTDIR=/mumble all install”
cd /usr/src
make distributeworld DESTDIR=/mumble
cd cddl/usr.sbin/dtrace
make buildenv
make all install
but it pulls in libraries from the base system, which differ slightly from
those in the source tree.
The above will create the right /mumble hierarchy, and will pull the libraries
from the build rather than the local system.
How can I force it to use /mumble2/include and /mumble2/lib instead of / ?
I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make
includes" but
I need to be able to do selective builds of just subdirectories after that.. I haven't
spotted the right way of forcing the use of the "--system_root /mumble2" option
in the compiles.
I know we do it in 'buildworld' is there a more generic way?
I have been looking in the .mk files but I haven't spotted it so far.
You’re asking for some serious split-brain action. chroot builds are likely
your best option. There’s no easy way to force this, although you might get
some milage out of WMAKEENV options, but I think we bake most of the where to
look for things options into the binaries. One crazy option would be to set
CC=“cc —sysroot /mumble” but I’m sure there be dragons there…
Good luck with this crazy, never have we supported it very well, option :)
Warner
Actually the hooks are in place to do this stuff. Instead of make
buildenv to get an interactive shell you can do something like
BLDENV=`${MAKE} buildenvvars`
chroot buildchroot/ "env -i $${BLDENV} cd /usr/src/somewhere && \
make all install"
-- Ian
Is there a way to specify a different toolchain destination? i.e. not
/usr/obj/usr/src/tmp ?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips64/mips
TB --- 2014-04-29 01:21:58 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-29 01:21:58 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-29 01:21:58 - starting HEAD tinderbox run for mips64/mips TB --- 2014-04-29 01:21:58 - cleaning the object tree TB --- 2014-04-29 01:23:07 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-29 01:23:10 - At svn revision 265054 TB --- 2014-04-29 01:23:11 - building world TB --- 2014-04-29 01:23:11 - CROSS_BUILD_TESTING=YES TB --- 2014-04-29 01:23:11 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-29 01:23:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-29 01:23:11 - SRCCONF=/dev/null TB --- 2014-04-29 01:23:11 - TARGET=mips TB --- 2014-04-29 01:23:11 - TARGET_ARCH=mips64 TB --- 2014-04-29 01:23:11 - TZ=UTC TB --- 2014-04-29 01:23:11 - __MAKE_CONF=/dev/null TB --- 2014-04-29 01:23:11 - cd /src TB --- 2014-04-29 01:23:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Apr 29 01:23:19 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 29 02:24:09 UTC 2014 TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ADM5120 TB --- 2014-04-29 02:24:09 - skipping ADM5120 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALCHEMY TB --- 2014-04-29 02:24:09 - skipping ALCHEMY kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALFA_HORNET_UB TB --- 2014-04-29 02:24:09 - skipping ALFA_HORNET_UB kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP121 TB --- 2014-04-29 02:24:09 - skipping AP121 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP91 TB --- 2014-04-29 02:24:09 - skipping AP91 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP93 TB --- 2014-04-29 02:24:09 - skipping AP93 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP94 TB --- 2014-04-29 02:24:09 - skipping AP94 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP96 TB --- 2014-04-29 02:24:09 - skipping AP96 kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR71XX_BASE TB --- 2014-04-29 02:24:09 - skipping AR71XX_BASE kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR724X_BASE TB --- 2014-04-29 02:24:09 - skipping AR724X_BASE kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR91XX_BASE TB --- 2014-04-29 02:24:09 - skipping AR91XX_BASE kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR933X_BASE TB --- 2014-04-29 02:24:09 - skipping AR933X_BASE kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR934X_BASE TB --- 2014-04-29 02:24:09 - skipping AR934X_BASE kernel TB --- 2014-04-29 02:24:09 - cd /src/sys/mips/conf TB --- 2014-04-29 02:24:09 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m BERI_DE4_BASE TB --- 2014-04-29 02:24:09 - building BERI_DE4_BASE kernel TB --- 2014-04-29 02:24:09 - CROSS_BUILD_TESTING=YES TB --- 2014-04-29 02:24:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-29 02:24:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-29 02:24:09 - SRCCONF=/dev/null TB --- 2014-04-29 02:24:09 - TARGET=mips TB --- 2014-04-29 02:24:09 - TARGET_ARCH=mips64 TB --- 2014-04-29 02:24:09 - TZ=UTC TB --- 2014-04-29 02:24:09 - __MAKE_CONF=/dev/null TB --- 2014-04-29 02:24:09 - cd /src TB --- 2014-04-29 02:24:09 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Tue Apr 29 02:24:09 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the
Re: Make variables to force non default libraries and includes?
On Mon, 2014-04-28 at 18:36 -0600, Warner Losh wrote:
> On Apr 28, 2014, at 1:48 AM, Julian Elischer wrote:
>
> > I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make
> > DESTDIR=/mumble all install”
>
> cd /usr/src
> make distributeworld DESTDIR=/mumble
> cd cddl/usr.sbin/dtrace
> make buildenv
> make all install
>
> > but it pulls in libraries from the base system, which differ slightly from
> > those in the source tree.
>
> The above will create the right /mumble hierarchy, and will pull the
> libraries from the build rather than the local system.
>
> > How can I force it to use /mumble2/include and /mumble2/lib instead of / ?
> >
> > I can pre-populate /mumble2 using "make buildworld", "make libraries", and
> > "make includes" but
> > I need to be able to do selective builds of just subdirectories after
> > that.. I haven't spotted the right way of forcing the use of the
> > "--system_root /mumble2" option in the compiles.
> >
> > I know we do it in 'buildworld' is there a more generic way?
> >
> > I have been looking in the .mk files but I haven't spotted it so far.
>
> You’re asking for some serious split-brain action. chroot builds are likely
> your best option. There’s no easy way to force this, although you might get
> some milage out of WMAKEENV options, but I think we bake most of the where to
> look for things options into the binaries. One crazy option would be to set
> CC=“cc —sysroot /mumble” but I’m sure there be dragons there…
>
> Good luck with this crazy, never have we supported it very well, option :)
>
> Warner
Actually the hooks are in place to do this stuff. Instead of make
buildenv to get an interactive shell you can do something like
BLDENV=`${MAKE} buildenvvars`
chroot buildchroot/ "env -i $${BLDENV} cd /usr/src/somewhere && \
make all install"
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Apr 27, 2014, at 10:30 AM, Ian Lepore wrote: > On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: >> I need to hold off using CLANG for a while at $JOB. We are moving to a >> newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte >> picture for a bit longer before switching. What options do I put into >> various /etc/make.conf to keep CLANG out ofhte picture until we are >> ready for it? >> >> From reading various posts I see: >> WITHOUT_CLANG="yes" >> CC=gcc >> CXX=g++ >> CPP=gcc -E >> but that doesn't seem complete to me. >> >> For now I want to not compile clang in our official build environment. >> (and obviously not use it until we are ready for it later this year.) >> >> What other hooks do I need to set? >> >> Julian > > We've got the same situation at work. What I'm using right now to build > 11-current @ r264151 is this: > > WITH_GCC=yes \ > WITH_GNUCXX=yes \ > WITHOUT_CLANG=yes \ > WITHOUT_CLANG_IS_CC=yes \ > > But that's now several weeks out of date, and there are two new knobs I > haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. Just to be clear, you’ll need WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP for -current, but not -stable. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On Apr 28, 2014, at 1:48 AM, Julian Elischer wrote: > I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make > DESTDIR=/mumble all install” cd /usr/src make distributeworld DESTDIR=/mumble cd cddl/usr.sbin/dtrace make buildenv make all install > but it pulls in libraries from the base system, which differ slightly from > those in the source tree. The above will create the right /mumble hierarchy, and will pull the libraries from the build rather than the local system. > How can I force it to use /mumble2/include and /mumble2/lib instead of / ? > > I can pre-populate /mumble2 using "make buildworld", "make libraries", and > "make includes" but > I need to be able to do selective builds of just subdirectories after that.. > I haven't spotted the right way of forcing the use of the "--system_root > /mumble2" option in the compiles. > > I know we do it in 'buildworld' is there a more generic way? > > I have been looking in the .mk files but I haven't spotted it so far. You’re asking for some serious split-brain action. chroot builds are likely your best option. There’s no easy way to force this, although you might get some milage out of WMAKEENV options, but I think we bake most of the where to look for things options into the binaries. One crazy option would be to set CC=“cc —sysroot /mumble” but I’m sure there be dragons there… Good luck with this crazy, never have we supported it very well, option :) Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On 4/28/14, 11:57 PM, Alfred Perlstein wrote: On 4/28/14 12:48 AM, Julian Elischer wrote: I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. There may be a way to use bsd.*.mk to do this, however we just use chroots + nullfs mounts. Basically we buildworld into a directory and then nullfs mount our other sources under it, then we chroot to that "build". I recommend doing this (or even using vms) as it's way too easy to introduce contamination from the host build environment otherwise. we already do this.. but it's more complicated than that.. we end up needing both a chroot (as a stable build environment) AND a separate toolchain directory (like buildworld uses) which can be perturbed by some of our local sources.. anyhow, I now have the answer as to what to use.. "make buildenv " and "make toolchain" are the two points of interst for what I need. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Apr 28, 2014, at 11:38 AM, Ian Lepore wrote: > On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote: >> On Apr 28, 2014, at 9:52 AM, Kevin Oberman wrote: >> >>> On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore wrote: >>> On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > On 4/28/14, 8:05 PM, Ian Lepore wrote: >> On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: >>> On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ >>> forgot to ask.. is this in /etc/make.conf? >>> or elsewhere? >> Actually in our build system we build in a chroot, and we inject those >> args into the environment during the builds so that we can have >> different options for building world versus cross-world within the >> chroot, but I think the more-normal place would be make.conf. > > we also use a combination of environment and make.conf in a chroot. > though people sometimes talk about a src.conf (or is that src.mk?) but > I haven't found that one yet. >> >> -- Ian >> >> >> In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. >> >> That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not >> only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO >> mechanism from converting those options into MK_FOO options. >> >>> I have also heard this, but a grep of ports/Mk finds no matches to >>> src\.conf, so this appears to not be the case. >> >> Ports specifically goes out of its way to make sure this doesn’t happen. >> Perhaps >> it isn’t going out of its way far enough? >> >>> It should not be as the whole purpose of src.conf was to have a make >>> configuration that would be used to build the system, but not other things. >>> make.conf already provided for that. >> >> If someone can show me a specific, verifiable leak, I’ll look into it. Vague >> rumors about possible issues that may have existed once upon a time >> aren’t fruitful to chase. >> > > You've known me long enough to know that the "Vague rumors..." sentence > doesn't describe the way I operate. Sorry that I misconstrued the sentiment you were expressing. My bad. > I was vague on the fine details, > but I remember an email thread where it was specifically shown that the > contents of src.conf were affecting ports builds. I just tracked it > down [1] and about midway through that thread it materialized that some > ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the > inappropriate inclusion of src.conf into a port build. > > So I figured I'd do a quick look for ports makefiles that are including > bsd.[lib|prog|subdir].mk : > > revolution > find . -name Make* | xargs grep bsd.*mk | \ > grep -v bsd.port| grep -E "lib.mk|prog.mk|subdir.mk" | wc -l > 66 Ah, it is affecting the building of the actual ports, not the bsd.ports.mk system. That’s the kind of detail that’s good to know. In the near future, that won’t happen, unless the port’s controlling Makefile. > That's probably not a perfect search, but it looks like there are a few > ports that may be perturbed by src.conf settings, plus as was revealed > in that thread, if you use /usr/share/mk/bsd.*.mk for your own software > (as we do at $work) then your own builds are also affected by src.conf. It is sufficient for me to get the issue. I’d mistakenly thought it was affecting ports build orchestration, but it is affecting anything that causes bsd.own.mk to be included using our make(1). Since I thought it was a reference to the former I was quite confused. Now that I know it is to the latter, I’m no longer confused. > I quite agree with the sentiments expressed in that thread that the > genesis of the problem is the opt-out nature of src.conf. If it had > been designed as an opt-in feature with a handful of /usr/src makefiles > opting in as-needed, maybe the situation would be cleaner today. Then > again, maybe that leads to other problems -- it's always easy to say > "the right thing to do would have been..." when you haven't fought your > way through actually making your plan work. I agree as well… Which is why I have been moving the options into their own file and separating them into different categories. In my tree I have a src.opts.mk file now, which is easy enough to do from where we are in the tree. The trouble is untangling it so that we can set it free from the bsd.*.mk files and have it only influence the /usr/src build without breaking other currently useful features of the /usr/src build. My plan is to move inclusion of src.conf into that file once I work those kinks out. Once that happens
Re: options for forcing use of GCC
Em Mon, 28 Apr 2014 08:23:34 -0600, Ian Lepore escreveu > On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > > On 4/28/14, 8:05 PM, Ian Lepore wrote: > > > On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > > >> On 4/28/14, 12:30 AM, Ian Lepore wrote: > > >>> WITH_GCC=yes \ > > >>> WITH_GNUCXX=yes \ > > >>> WITHOUT_CLANG=yes \ > > >>> WITHOUT_CLANG_IS_CC=yes \ > > >> forgot to ask.. is this in /etc/make.conf? > > >> or elsewhere? > > > Actually in our build system we build in a chroot, and we inject those > > > args into the environment during the builds so that we can have > > > different options for building world versus cross-world within the > > > chroot, but I think the more-normal place would be make.conf. > > > > we also use a combination of environment and make.conf in a chroot. > > though people sometimes talk about a src.conf (or is that src.mk?) but > > I haven't found that one yet. You must be create in /etc the src.conf and put this knobs there. In my case I would like to use only clang, but have some ports that assume gcc as mandatory. Rizzo > > > > > > -- Ian > > > > > > > > > > > In theory, /etc/make.conf affects all builds you do -- world, kernel, > ports, your own apps, everything -- whereas /etc/src.conf affects > only kernel and world. I've heard it said that the reality falls > short of that and src.conf settings inappropriately leak into ports builds. > > -- Ian > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote: > On Apr 28, 2014, at 9:52 AM, Kevin Oberman wrote: > > > On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore wrote: > > > >> On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > >>> On 4/28/14, 8:05 PM, Ian Lepore wrote: > On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > > On 4/28/14, 12:30 AM, Ian Lepore wrote: > >> WITH_GCC=yes \ > >> WITH_GNUCXX=yes \ > >> WITHOUT_CLANG=yes \ > >> WITHOUT_CLANG_IS_CC=yes \ > > forgot to ask.. is this in /etc/make.conf? > > or elsewhere? > Actually in our build system we build in a chroot, and we inject those > args into the environment during the builds so that we can have > different options for building world versus cross-world within the > chroot, but I think the more-normal place would be make.conf. > >>> > >>> we also use a combination of environment and make.conf in a chroot. > >>> though people sometimes talk about a src.conf (or is that src.mk?) but > >>> I haven't found that one yet. > > -- Ian > > > > >> > >> In theory, /etc/make.conf affects all builds you do -- world, kernel, > >> ports, your own apps, everything -- whereas /etc/src.conf affects only > >> kernel and world. I've heard it said that the reality falls short of > >> that and src.conf settings inappropriately leak into ports builds. > > That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not > only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO > mechanism from converting those options into MK_FOO options. > > > I have also heard this, but a grep of ports/Mk finds no matches to > > src\.conf, so this appears to not be the case. > > Ports specifically goes out of its way to make sure this doesn’t happen. > Perhaps > it isn’t going out of its way far enough? > > > It should not be as the whole purpose of src.conf was to have a make > > configuration that would be used to build the system, but not other things. > > make.conf already provided for that. > > If someone can show me a specific, verifiable leak, I’ll look into it. Vague > rumors about possible issues that may have existed once upon a time > aren’t fruitful to chase. > You've known me long enough to know that the "Vague rumors..." sentence doesn't describe the way I operate. I was vague on the fine details, but I remember an email thread where it was specifically shown that the contents of src.conf were affecting ports builds. I just tracked it down [1] and about midway through that thread it materialized that some ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the inappropriate inclusion of src.conf into a port build. So I figured I'd do a quick look for ports makefiles that are including bsd.[lib|prog|subdir].mk : revolution > find . -name Make* | xargs grep bsd.*mk | \ grep -v bsd.port| grep -E "lib.mk|prog.mk|subdir.mk" | wc -l 66 That's probably not a perfect search, but it looks like there are a few ports that may be perturbed by src.conf settings, plus as was revealed in that thread, if you use /usr/share/mk/bsd.*.mk for your own software (as we do at $work) then your own builds are also affected by src.conf. I quite agree with the sentiments expressed in that thread that the genesis of the problem is the opt-out nature of src.conf. If it had been designed as an opt-in feature with a handful of /usr/src makefiles opting in as-needed, maybe the situation would be cleaner today. Then again, maybe that leads to other problems -- it's always easy to say "the right thing to do would have been..." when you haven't fought your way through actually making your plan work. [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039709.html -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building sys/boot ... shouldn't this "just work" ?
On Mon, 2014-04-28 at 09:00 -0700, Sean Bruno wrote: > ===> efi (all) > ===> efi/libefi (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/efi/libefi > ===> libstand32 (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/libstand32 > ===> zfs (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/zfs > ===> userboot (all) > ===> userboot/ficl (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/userboot/ficl > ===> userboot/libstand (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/userboot/libstand > ===> userboot/test (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/userboot/test > ===> userboot/zfs (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/userboot/zfs > ===> userboot/userboot (all) > Warning: Object directory not changed from > original /home/sbruno/bsd/head/sys/boot/userboot/userboot > building shared library userboot.so > cc: error: no such file or directory: > '/home/sbruno/bsd/head/sys/boot/userboot/userboot/../zfs/libzfsboot.a' > *** Error code 1 > > Stop. > make[2]: stopped in /home/sbruno/bsd/head/sys/boot/userboot/userboot > *** Error code 1 > > Stop. > make[1]: stopped in /home/sbruno/bsd/head/sys/boot/userboot > *** Error code 1 > > Stop. > make: stopped in /home/sbruno/bsd/head/sys/boot > Oh, so the "way" to do this is "MAKEOBJDIRPREFIX=/var/tmp make obj depend all" ... thanks to gjb for pointing that out. sean signature.asc Description: This is a digitally signed message part
Re: boot2 too large when built with BTX_SERIAL=yes
On Sat, 2014-04-26 at 21:15 -0400, Ryan Stone wrote: > I've been seeing the following build failure on HEAD when I set > BTX_SERIAL=yes in make.conf > > btxld -v -E 0x2000 -f bin -b > /usr/obj/repos/users/rstone/freebsd/sys/boot/i386/boot2/../btx/btx/btx > -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=6c0 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1551 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1e11 text=200 data=1c11 org=0 entry=0 > --- boot2 --- > --- rescue.all__D --- > --- init_make --- > (cd /repos/users/rstone/freebsd/rescue/rescue/../../sbin/init && make > -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/init/ depend && > make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/init/ > init.o) > --- sys.all__D --- > -17 bytes available confirmed, and gross: sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp cc -m32 -c boot2.s cc -Os -fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=115200 -I/home/sbruno/bsd/head/sys/boot/i386/boot2/../../common -I/home/sbruno/bsd/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -Qunused-arguments -m32 -c /home/sbruno/bsd/head/sys/boot/i386/boot2/sio.S ld -static -N --gc-sections -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /var/tmp/home/sbruno/bsd/head/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /var/tmp/home/sbruno/bsd/head/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=6c0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1551 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e11 text=200 data=1c11 org=0 entry=0 -17 bytes available *** Error code 1 Stop. make[2]: stopped in /home/sbruno/bsd/head/sys/boot/i386/boot2 *** Error code 1 Stop. make[1]: stopped in /home/sbruno/bsd/head/sys/boot/i386 *** Error code 1 Stop. make: stopped in /home/sbruno/bsd/head/sys/boot signature.asc Description: This is a digitally signed message part
building sys/boot ... shouldn't this "just work" ?
===> efi (all) ===> efi/libefi (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/efi/libefi ===> libstand32 (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/libstand32 ===> zfs (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/zfs ===> userboot (all) ===> userboot/ficl (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/userboot/ficl ===> userboot/libstand (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/userboot/libstand ===> userboot/test (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/userboot/test ===> userboot/zfs (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/userboot/zfs ===> userboot/userboot (all) Warning: Object directory not changed from original /home/sbruno/bsd/head/sys/boot/userboot/userboot building shared library userboot.so cc: error: no such file or directory: '/home/sbruno/bsd/head/sys/boot/userboot/userboot/../zfs/libzfsboot.a' *** Error code 1 Stop. make[2]: stopped in /home/sbruno/bsd/head/sys/boot/userboot/userboot *** Error code 1 Stop. make[1]: stopped in /home/sbruno/bsd/head/sys/boot/userboot *** Error code 1 Stop. make: stopped in /home/sbruno/bsd/head/sys/boot signature.asc Description: This is a digitally signed message part
Re: options for forcing use of GCC
On Apr 28, 2014, at 9:52 AM, Kevin Oberman wrote: > On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore wrote: > >> On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: >>> On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > On 4/28/14, 12:30 AM, Ian Lepore wrote: >> WITH_GCC=yes \ >> WITH_GNUCXX=yes \ >> WITHOUT_CLANG=yes \ >> WITHOUT_CLANG_IS_CC=yes \ > forgot to ask.. is this in /etc/make.conf? > or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. >>> >>> we also use a combination of environment and make.conf in a chroot. >>> though people sometimes talk about a src.conf (or is that src.mk?) but >>> I haven't found that one yet. -- Ian >> >> In theory, /etc/make.conf affects all builds you do -- world, kernel, >> ports, your own apps, everything -- whereas /etc/src.conf affects only >> kernel and world. I've heard it said that the reality falls short of >> that and src.conf settings inappropriately leak into ports builds. That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO mechanism from converting those options into MK_FOO options. > I have also heard this, but a grep of ports/Mk finds no matches to > src\.conf, so this appears to not be the case. Ports specifically goes out of its way to make sure this doesn’t happen. Perhaps it isn’t going out of its way far enough? > It should not be as the whole purpose of src.conf was to have a make > configuration that would be used to build the system, but not other things. > make.conf already provided for that. If someone can show me a specific, verifiable leak, I’ll look into it. Vague rumors about possible issues that may have existed once upon a time aren’t fruitful to chase. > The only exception I might see is the building of a kernel module which > might need to know how the system was made and that would be in the > specific port's Makefile, not a system wide file. I’m not sure I understand here. If a kernel module uses the kernel module build stuff, it should be affected by the src.conf files unless you specifically request otherwise because you know what you are doing (e.g., building for another system, cross building, etc). Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Apr 28, 2014, at 12:54 AM, Julian Elischer wrote: > On 4/28/14, 12:30 AM, Ian Lepore wrote: >> WITH_GCC=yes \ >> WITH_GNUCXX=yes \ >> WITHOUT_CLANG=yes \ >> WITHOUT_CLANG_IS_CC=yes \ > forgot to ask.. is this in /etc/make.conf? > or elsewhere? Add them to /etc/make.conf. They will be global to the entire system. Current may also require WITHOUT_CLANG_BOOTSTRAP=t and WITH_GCC_BOOTSTRAP=t if you want to build the system with gcc. The ‘build for the target’ and ‘what to build with’ have been decoupled and there’s no clean way to fallback. Also, in the future CLANG_IS_CC is going to die entirely. It was supposed to be a short-term hack, and it has lived too long and been used in too many lame, hackey ways. It is time to retire it. It will be replaced by DEFAULT_COMPILER= which will drive the defaults to build with as well as to install with (nicely solving the current friction points here). I have the start of patches to do this, so maybe by BSDcan it will be gone in current, along with every last clang-induced build-system kludge. I’ve killed about a dozen already, but more remain. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On 4/28/14 12:48 AM, Julian Elischer wrote: I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. There may be a way to use bsd.*.mk to do this, however we just use chroots + nullfs mounts. Basically we buildworld into a directory and then nullfs mount our other sources under it, then we chroot to that "build". I recommend doing this (or even using vms) as it's way too easy to introduce contamination from the host build environment otherwise. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore wrote: > On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > > On 4/28/14, 8:05 PM, Ian Lepore wrote: > > > On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > > >> On 4/28/14, 12:30 AM, Ian Lepore wrote: > > >>> WITH_GCC=yes \ > > >>> WITH_GNUCXX=yes \ > > >>> WITHOUT_CLANG=yes \ > > >>> WITHOUT_CLANG_IS_CC=yes \ > > >> forgot to ask.. is this in /etc/make.conf? > > >> or elsewhere? > > > Actually in our build system we build in a chroot, and we inject those > > > args into the environment during the builds so that we can have > > > different options for building world versus cross-world within the > > > chroot, but I think the more-normal place would be make.conf. > > > > we also use a combination of environment and make.conf in a chroot. > > though people sometimes talk about a src.conf (or is that src.mk?) but > > I haven't found that one yet. > > > > > > -- Ian > > > > > > > > > > > In theory, /etc/make.conf affects all builds you do -- world, kernel, > ports, your own apps, everything -- whereas /etc/src.conf affects only > kernel and world. I've heard it said that the reality falls short of > that and src.conf settings inappropriately leak into ports builds. > > -- Ian > I have also heard this, but a grep of ports/Mk finds no matches to src\.conf, so this appears to not be the case. It should not be as the whole purpose of src.conf was to have a make configuration that would be used to build the system, but not other things. make.conf already provided for that. The only exception I might see is the building of a kernel module which might need to know how the system was made and that would be in the specific port's Makefile, not a system wide file. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On 4/28/14, 10:27 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 22:07 +0800, Julian Elischer wrote: On 4/28/14, 8:19 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 15:50 +0800, Julian Elischer wrote: I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. An option woudl be a way to 'enter' a buildworld and just rebuild or reinstall small specified parts of it. Unfortunately at the moment I see no option other than a lot of WITHOUT_XXX and 'build everything'. Julian The 'buildenv' target does the "enter a buildworld" thing. Just "make buildenv" and you get a shell with all the environment variables set up for doing builds (or cross-builds if you set TARGET_ARCH) within that source tree. If csh isn't your favorite shell, set BUILDENV_SHELL in your environment. There's also a "buildenvvars" target that will let you capture the environment you need so that you can use it within your own build scripts without needing an interactive shell. -- Ian oh man that is just what I'm looking for Is there a single command for populating the buildenv resources? i.e. to compile and install all the tools and libraries (and includes etc) (into /usr/obj/usr/src/tmp... ) "make toolchain" should do that. There's also kernel-toolchain for building just the kernel; I think the only difference between the two is that kernel-toolchain doesn't build userland includes and libs. excellent ! -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2014-04-28 12:57:27 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-28 12:57:27 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-28 12:57:27 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-04-28 12:57:27 - cleaning the object tree TB --- 2014-04-28 12:57:27 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-28 12:57:33 - At svn revision 265036 TB --- 2014-04-28 12:57:34 - building world TB --- 2014-04-28 12:57:34 - CROSS_BUILD_TESTING=YES TB --- 2014-04-28 12:57:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-28 12:57:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-28 12:57:34 - SRCCONF=/dev/null TB --- 2014-04-28 12:57:34 - TARGET=powerpc TB --- 2014-04-28 12:57:34 - TARGET_ARCH=powerpc64 TB --- 2014-04-28 12:57:34 - TZ=UTC TB --- 2014-04-28 12:57:34 - __MAKE_CONF=/dev/null TB --- 2014-04-28 12:57:34 - cd /src TB --- 2014-04-28 12:57:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Apr 28 12:57:41 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/ARCMT.cpp -o ARCMT.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/ARCMTActions.cpp -o ARCMTActions.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/FileRemapper.cpp -o FileRemapper.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/ObjCMT.cpp -o ObjCMT.o c++ -O2 -pipe -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/
Re: [CFT] ASLR and PIE on amd64
Updated aslr + segvguard SNAPSHOT patches, see the attachments. freebsd-stable-10-r265039-aslr-segvguard-SNAPSHOT.diff : against stable/10 @r265039 freebsd-current-r265046-aslr-segvguard-SNAPSHOT.diff : against current @r265046 To apply the patch, use this command: patch -p1 < freebsd-stable-10-r265039-aslr-segvguard-SNAPSHOT.diff or patch -p1 < freebsd-current-r265046-aslr-segvguard-SNAPSHOT.diff github: https://github.com/HardenedBSD/hardenedBSD/commits/hardened/10/aslr github: https://github.com/HardenedBSD/hardenedBSD/commits/hardened/current/aslr git: https://github.com/HardenedBSD/hardenedBSD.git ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On Mon, 2014-04-28 at 22:07 +0800, Julian Elischer wrote: > On 4/28/14, 8:19 PM, Ian Lepore wrote: > > On Mon, 2014-04-28 at 15:50 +0800, Julian Elischer wrote: > >> I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; > >> make DESTDIR=/mumble all install" > >> > >> but it pulls in libraries from the base system, which differ slightly > >> from those in the source tree. > >> > >> How can I force it to use /mumble2/include and /mumble2/lib instead of / ? > >> > >> I can pre-populate /mumble2 using "make buildworld", "make libraries", > >> and "make includes" but > >> I need to be able to do selective builds of just subdirectories after > >> that.. I haven't spotted the right way of forcing the use of the > >> "--system_root /mumble2" option in the compiles. > >> > >> I know we do it in 'buildworld' is there a more generic way? > >> > >> I have been looking in the .mk files but I haven't spotted it so far. > >> > >> An option woudl be a way to 'enter' a buildworld and just rebuild or > >> reinstall small specified parts of it. > >> Unfortunately at the moment I see no option other than a lot of > >> WITHOUT_XXX and 'build everything'. > >> > >> > >> Julian > > The 'buildenv' target does the "enter a buildworld" thing. Just "make > > buildenv" and you get a shell with all the environment variables set up > > for doing builds (or cross-builds if you set TARGET_ARCH) within that > > source tree. If csh isn't your favorite shell, set BUILDENV_SHELL in > > your environment. There's also a "buildenvvars" target that will let > > you capture the environment you need so that you can use it within your > > own build scripts without needing an interactive shell. > > > > -- Ian > > > > > > > > > oh man that is just what I'm looking for > Is there a single command for populating the buildenv resources? > i.e. to compile and install all the tools and libraries (and includes > etc) (into /usr/obj/usr/src/tmp... ) "make toolchain" should do that. There's also kernel-toolchain for building just the kernel; I think the only difference between the two is that kernel-toolchain doesn't build userland includes and libs. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > On 4/28/14, 8:05 PM, Ian Lepore wrote: > > On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > >> On 4/28/14, 12:30 AM, Ian Lepore wrote: > >>> WITH_GCC=yes \ > >>> WITH_GNUCXX=yes \ > >>> WITHOUT_CLANG=yes \ > >>> WITHOUT_CLANG_IS_CC=yes \ > >> forgot to ask.. is this in /etc/make.conf? > >> or elsewhere? > > Actually in our build system we build in a chroot, and we inject those > > args into the environment during the builds so that we can have > > different options for building world versus cross-world within the > > chroot, but I think the more-normal place would be make.conf. > > we also use a combination of environment and make.conf in a chroot. > though people sometimes talk about a src.conf (or is that src.mk?) but > I haven't found that one yet. > > > > -- Ian > > > > > > In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Make variables to force non default libraries and includes?
On 4/28/14, 8:19 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 15:50 +0800, Julian Elischer wrote: I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. An option woudl be a way to 'enter' a buildworld and just rebuild or reinstall small specified parts of it. Unfortunately at the moment I see no option other than a lot of WITHOUT_XXX and 'build everything'. Julian The 'buildenv' target does the "enter a buildworld" thing. Just "make buildenv" and you get a shell with all the environment variables set up for doing builds (or cross-builds if you set TARGET_ARCH) within that source tree. If csh isn't your favorite shell, set BUILDENV_SHELL in your environment. There's also a "buildenvvars" target that will let you capture the environment you need so that you can use it within your own build scripts without needing an interactive shell. -- Ian oh man that is just what I'm looking for Is there a single command for populating the buildenv resources? i.e. to compile and install all the tools and libraries (and includes etc) (into /usr/obj/usr/src/tmp... ) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips64/mips
TB --- 2014-04-28 11:33:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-28 11:33:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-28 11:33:18 - starting HEAD tinderbox run for mips64/mips TB --- 2014-04-28 11:33:18 - cleaning the object tree TB --- 2014-04-28 11:34:24 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-28 11:34:27 - At svn revision 265036 TB --- 2014-04-28 11:34:28 - building world TB --- 2014-04-28 11:34:28 - CROSS_BUILD_TESTING=YES TB --- 2014-04-28 11:34:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-28 11:34:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-28 11:34:28 - SRCCONF=/dev/null TB --- 2014-04-28 11:34:28 - TARGET=mips TB --- 2014-04-28 11:34:28 - TARGET_ARCH=mips64 TB --- 2014-04-28 11:34:28 - TZ=UTC TB --- 2014-04-28 11:34:28 - __MAKE_CONF=/dev/null TB --- 2014-04-28 11:34:28 - cd /src TB --- 2014-04-28 11:34:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Apr 28 11:34:35 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Apr 28 12:36:15 UTC 2014 TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ADM5120 TB --- 2014-04-28 12:36:15 - skipping ADM5120 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALCHEMY TB --- 2014-04-28 12:36:15 - skipping ALCHEMY kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALFA_HORNET_UB TB --- 2014-04-28 12:36:15 - skipping ALFA_HORNET_UB kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP121 TB --- 2014-04-28 12:36:15 - skipping AP121 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP91 TB --- 2014-04-28 12:36:15 - skipping AP91 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP93 TB --- 2014-04-28 12:36:15 - skipping AP93 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP94 TB --- 2014-04-28 12:36:15 - skipping AP94 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP96 TB --- 2014-04-28 12:36:15 - skipping AP96 kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR71XX_BASE TB --- 2014-04-28 12:36:15 - skipping AR71XX_BASE kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR724X_BASE TB --- 2014-04-28 12:36:15 - skipping AR724X_BASE kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR91XX_BASE TB --- 2014-04-28 12:36:15 - skipping AR91XX_BASE kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR933X_BASE TB --- 2014-04-28 12:36:15 - skipping AR933X_BASE kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR934X_BASE TB --- 2014-04-28 12:36:15 - skipping AR934X_BASE kernel TB --- 2014-04-28 12:36:15 - cd /src/sys/mips/conf TB --- 2014-04-28 12:36:15 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m BERI_DE4_BASE TB --- 2014-04-28 12:36:15 - building BERI_DE4_BASE kernel TB --- 2014-04-28 12:36:15 - CROSS_BUILD_TESTING=YES TB --- 2014-04-28 12:36:15 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-28 12:36:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-28 12:36:15 - SRCCONF=/dev/null TB --- 2014-04-28 12:36:15 - TARGET=mips TB --- 2014-04-28 12:36:15 - TARGET_ARCH=mips64 TB --- 2014-04-28 12:36:15 - TZ=UTC TB --- 2014-04-28 12:36:15 - __MAKE_CONF=/dev/null TB --- 2014-04-28 12:36:15 - cd /src TB --- 2014-04-28 12:36:15 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Mon Apr 28 12:36:15 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the
Re: Make variables to force non default libraries and includes?
On Mon, 2014-04-28 at 15:50 +0800, Julian Elischer wrote: > I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; > make DESTDIR=/mumble all install" > > but it pulls in libraries from the base system, which differ slightly > from those in the source tree. > > How can I force it to use /mumble2/include and /mumble2/lib instead of / ? > > I can pre-populate /mumble2 using "make buildworld", "make libraries", > and "make includes" but > I need to be able to do selective builds of just subdirectories after > that.. I haven't spotted the right way of forcing the use of the > "--system_root /mumble2" option in the compiles. > > I know we do it in 'buildworld' is there a more generic way? > > I have been looking in the .mk files but I haven't spotted it so far. > > An option woudl be a way to 'enter' a buildworld and just rebuild or > reinstall small specified parts of it. > Unfortunately at the moment I see no option other than a lot of > WITHOUT_XXX and 'build everything'. > > > Julian The 'buildenv' target does the "enter a buildworld" thing. Just "make buildenv" and you get a shell with all the environment variables set up for doing builds (or cross-builds if you set TARGET_ARCH) within that source tree. If csh isn't your favorite shell, set BUILDENV_SHELL in your environment. There's also a "buildenvvars" target that will let you capture the environment you need so that you can use it within your own build scripts without needing an interactive shell. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > On 4/28/14, 12:30 AM, Ian Lepore wrote: > > WITH_GCC=yes \ > > WITH_GNUCXX=yes \ > > WITHOUT_CLANG=yes \ > > WITHOUT_CLANG_IS_CC=yes \ > forgot to ask.. is this in /etc/make.conf? > or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: options for forcing use of GCC vs CLANG
On Mon, 2014-04-28 at 14:47 +0800, Julian Elischer wrote: > On 4/28/14, 12:30 AM, Ian Lepore wrote: > > On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: > >> I need to hold off using CLANG for a while at $JOB. We are moving to a > >> newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte > >> picture for a bit longer before switching. What options do I put into > >> various /etc/make.conf to keep CLANG out ofhte picture until we are > >> ready for it? > >> > >> From reading various posts I see: > >> WITHOUT_CLANG="yes" > >> CC=gcc > >> CXX=g++ > >> CPP=gcc -E > >> but that doesn't seem complete to me. > >> > >> For now I want to not compile clang in our official build environment. > >> (and obviously not use it until we are ready for it later this year.) > >> > >> What other hooks do I need to set? > >> > >> Julian > > We've got the same situation at work. What I'm using right now to build > > 11-current @ r264151 is this: > > > > WITH_GCC=yes \ > > WITH_GNUCXX=yes \ > > WITHOUT_CLANG=yes \ > > WITHOUT_CLANG_IS_CC=yes \ > > > > But that's now several weeks out of date, and there are two new knobs I > > haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. > > > > -- Ian > > > > > > > > > > Thanks Ian. > Can soneone who is driving this please chime in? I will need to keep > GCC on systems from 9.0 to 10.1 (and various points in between on the > -current lineage). Will the lines above work for that whole range? or > did it change over time? > I expect to flip the CLANG switch sometime around the time when we > slide on to 10.1 or so. > Adding Warner, since he's the one doing the work on this stuff. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Make variables to force non default libraries and includes?
I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. An option woudl be a way to 'enter' a buildworld and just rebuild or reinstall small specified parts of it. Unfortunately at the moment I see no option other than a lot of WITHOUT_XXX and 'build everything'. Julian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Make variables to force non default libraries and includes?
I need to do the equivalent of "cd /usr/src/cddl/usr.sbin/dtrace; make DESTDIR=/mumble all install" but it pulls in libraries from the base system, which differ slightly from those in the source tree. How can I force it to use /mumble2/include and /mumble2/lib instead of / ? I can pre-populate /mumble2 using "make buildworld", "make libraries", and "make includes" but I need to be able to do selective builds of just subdirectories after that.. I haven't spotted the right way of forcing the use of the "--system_root /mumble2" option in the compiles. I know we do it in 'buildworld' is there a more generic way? I have been looking in the .mk files but I haven't spotted it so far. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
