Re: Building world with gcc9 not working
On 2019-09-09 23:08, Warner Losh wrote: > >> Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc >> buildworld earlier this week. (It doesn't play well with binary pkg's >> built with Clang, so I ended up replacing it with a Clang-built world >> instead, but it compiled.) >> >> Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while >> you're running the much more recent GCC9. I think GCC6.4.0 is more or >> less expected to build world today, but I don't think many people are >> building with GCC9. I would love for amd64-xtoolchain to move to a >> newer version, but I don't know what is blocking that — it seems like >> it should be straightforward. >> > I did a gcc8 build about a year or so ago, though I had to turn off Werror > to complete the build... Thanks. I kept running into build errors with gcc 8 and 9 (even with WERROR= in src.conf), but building with gcc 6 from the amd64-gcc port worked. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with gcc9 not working
On Mon, Sep 9, 2019 at 11:05 PM Conrad Meyer wrote: > On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran wrote: > > > > Is building world with gcc still supported? I'm getting an error running > > the following: > > > > make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld > > Hi Rebecca, > > Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc > buildworld earlier this week. (It doesn't play well with binary pkg's > built with Clang, so I ended up replacing it with a Clang-built world > instead, but it compiled.) > > Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while > you're running the much more recent GCC9. I think GCC6.4.0 is more or > less expected to build world today, but I don't think many people are > building with GCC9. I would love for amd64-xtoolchain to move to a > newer version, but I don't know what is blocking that — it seems like > it should be straightforward. > I did a gcc8 build about a year or so ago, though I had to turn off Werror to complete the build... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with gcc9 not working
On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran wrote: > > Is building world with gcc still supported? I'm getting an error running > the following: > > make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld Hi Rebecca, Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc buildworld earlier this week. (It doesn't play well with binary pkg's built with Clang, so I ended up replacing it with a Clang-built world instead, but it compiled.) Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while you're running the much more recent GCC9. I think GCC6.4.0 is more or less expected to build world today, but I don't think many people are building with GCC9. I would love for amd64-xtoolchain to move to a newer version, but I don't know what is blocking that — it seems like it should be straightforward. Best regards, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building world via ccache broken?
On 10/02/2017 16:35, Pete Wright wrote:
On 10/02/2017 16:33, Matt Joras wrote:
On 10/02/2017 15:23, Pete Wright wrote:
On 10/02/2017 13:07, Pete Wright wrote:
hey there,
i've been unable to buildworld using ccache for a while. initially i
assumed it was due to some incompatibilities on the drm-next branch
which i was running, but i've since cut over to CURRENT and am still
having issues. running "make buildworld" i am running into this
exception:
/usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no
member named 'fs_metackhash' in 'struct fs'
if ((fs->fs_metackhash & CK_CYLGRP) != 0) {
~~ ^
full exception here:
https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61
I am going to re-run this w/o ccache - to verify that this is a
ccache related issue. I guess my first question - is anyone else
using ccache successfully?
fwiw building the world without ccache works as expected. perhaps my
make.conf is not correctly configured?
$ cat /etc/make.conf
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
.endif
cheers,
-pete
Someone can correct me if I'm wrong but I believe the current "correct"
way to get ccache builds is WITH_CCACHE_BUILD set in src.conf.
src.conf(5) seems to indicate as much as well. To answer your question,
yes, I am I'm sure many others are building world on HEAD with ccache
without issue.
thanks, i had another person point me in this direction - and after
reading the man page it does indeed clearly state as much :)
what had tripped me up is that the ccache portfile installs:
/usr/local/share/doc/ccache/ccache-howto-freebsd.txt
which does not mention src.conf, but states:
To use ccache for base add the following to /etc/make.conf.
You can replace cc and c++ with the compilers of your choice.
(remember that only GCC and Clang can build world and kernel)
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
if i'm able to successfully build my world and kernel via src.conf
i'll file a PR against the ccache port.
cheers!
-pete
I can verify that this works on my system, firing off a PR now to the
ports team to update documentation shortly :)
thanks for the input everyone.
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building world via ccache broken?
On 10/02/2017 15:23, Pete Wright wrote:
>
>
> On 10/02/2017 13:07, Pete Wright wrote:
>> hey there,
>> i've been unable to buildworld using ccache for a while. initially i
>> assumed it was due to some incompatibilities on the drm-next branch
>> which i was running, but i've since cut over to CURRENT and am still
>> having issues. running "make buildworld" i am running into this
>> exception:
>>
>> /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no
>> member named 'fs_metackhash' in 'struct fs'
>> if ((fs->fs_metackhash & CK_CYLGRP) != 0) {
>> ~~ ^
>>
>>
>> full exception here:
>> https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61
>>
>> I am going to re-run this w/o ccache - to verify that this is a
>> ccache related issue. I guess my first question - is anyone else
>> using ccache successfully?
>>
>
> fwiw building the world without ccache works as expected. perhaps my
> make.conf is not correctly configured?
>
> $ cat /etc/make.conf
> .if !defined(NO_CCACHE)
> CC= /usr/local/libexec/ccache/world/cc
> CXX= /usr/local/libexec/ccache/world/c++
> .endif
>
> cheers,
> -pete
>
Someone can correct me if I'm wrong but I believe the current "correct"
way to get ccache builds is WITH_CCACHE_BUILD set in src.conf.
src.conf(5) seems to indicate as much as well. To answer your question,
yes, I am I'm sure many others are building world on HEAD with ccache
without issue.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building world via ccache broken?
On 10/02/2017 16:33, Matt Joras wrote:
On 10/02/2017 15:23, Pete Wright wrote:
On 10/02/2017 13:07, Pete Wright wrote:
hey there,
i've been unable to buildworld using ccache for a while. initially i
assumed it was due to some incompatibilities on the drm-next branch
which i was running, but i've since cut over to CURRENT and am still
having issues. running "make buildworld" i am running into this
exception:
/usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no
member named 'fs_metackhash' in 'struct fs'
if ((fs->fs_metackhash & CK_CYLGRP) != 0) {
~~ ^
full exception here:
https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61
I am going to re-run this w/o ccache - to verify that this is a
ccache related issue. I guess my first question - is anyone else
using ccache successfully?
fwiw building the world without ccache works as expected. perhaps my
make.conf is not correctly configured?
$ cat /etc/make.conf
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
.endif
cheers,
-pete
Someone can correct me if I'm wrong but I believe the current "correct"
way to get ccache builds is WITH_CCACHE_BUILD set in src.conf.
src.conf(5) seems to indicate as much as well. To answer your question,
yes, I am I'm sure many others are building world on HEAD with ccache
without issue.
thanks, i had another person point me in this direction - and after
reading the man page it does indeed clearly state as much :)
what had tripped me up is that the ccache portfile installs:
/usr/local/share/doc/ccache/ccache-howto-freebsd.txt
which does not mention src.conf, but states:
To use ccache for base add the following to /etc/make.conf.
You can replace cc and c++ with the compilers of your choice.
(remember that only GCC and Clang can build world and kernel)
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
if i'm able to successfully build my world and kernel via src.conf i'll
file a PR against the ccache port.
cheers!
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building world via ccache broken?
On 10/02/2017 13:07, Pete Wright wrote:
hey there,
i've been unable to buildworld using ccache for a while. initially i
assumed it was due to some incompatibilities on the drm-next branch
which i was running, but i've since cut over to CURRENT and am still
having issues. running "make buildworld" i am running into this
exception:
/usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no
member named 'fs_metackhash' in 'struct fs'
if ((fs->fs_metackhash & CK_CYLGRP) != 0) {
~~ ^
full exception here:
https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61
I am going to re-run this w/o ccache - to verify that this is a ccache
related issue. I guess my first question - is anyone else using
ccache successfully?
fwiw building the world without ccache works as expected. perhaps my
make.conf is not correctly configured?
$ cat /etc/make.conf
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
.endif
cheers,
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with clang ToT
Hi Brook, On 12-09-12 18:34, Brooks Davis wrote: snip Note that some people have been working on external toolchain support. This would aim to make it possible to do what you were trying, e.g. building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG and WITHOUT_GCC, among others. However, I am not sure how far these efforts have come by now. :-) I've got some patches that aren't quite ready for prime-time that allow me to cross build world with an external CLANG. I'll post them to the toolchain@ list when they are closer to ready (hopefully quite soon). -- Brooks I'd be interested in those, even if there are some rough edges. (I don't mind sub-prime, this time ;) FWIW: The clang build finished too, but with two hick-ups: 1. - kdump: build reports 4 errors: === usr.bin/kdump (depend) sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include kdump_subr.c env MACHINE=amd64 CPP=cpp sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c stdin:8:31: error: cam/scsi/scsi_enc.h: No such file or directory stdin:17:33: error: dev/filemon/filemon.h: No such file or directory stdin:35:33: error: fs/nandfs/nandfs_fs.h: No such file or directory stdin:46:24: error: net/netmap.h: No such file or directory (As a consequence ?) clang doesn't pick up 2 symbols: MFI_CMD32 and MFIIO_PASSTHRU32 which are defined if COMPAT_FREEBSD32 is set in sys/dev/mfi/mfi_ioctl.h 2. lint calls tmp/usr/cc directly: buildworld-clang.log:=== usr.bin/xlint/llib (all) buildworld-clang.log:lint -cghapbx -Cposix /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib/llib-lposix buildworld-clang.log:lint: cannot exec /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/bin/cc: No such file or directory buildworld-clang.log:Stop in /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib. A link from cc to clang in the same directory fixes that. Regards, Ed. ps: re. 1: the gcc build calls: === usr.bin/kdump (depend) /bin/sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/../../sys/kern/makesyscalls.sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/../../sys/amd64/linux32/syscalls.master /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/linux_syscalls.conf sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include | sed -n 's/^\([a-z].*)\)$/void \1;/p' kdump_subr.h echo int nlinux_syscalls = sizeof(linux_syscallnames) / sizeof(linux_syscallnames[0]); linux_syscalls.c env MACHINE=amd64 CPP=cpp sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c ___ 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 world with clang ToT
On 2012-09-13 11:27, Edward Meewis wrote:
...
FWIW: The clang build finished too, but with two hick-ups:
1. - kdump: build reports 4 errors:
=== usr.bin/kdump (depend)
sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include kdump_subr.c
env MACHINE=amd64 CPP=cpp sh
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c
stdin:8:31: error: cam/scsi/scsi_enc.h: No such file or directory
stdin:17:33: error: dev/filemon/filemon.h: No such file or directory
stdin:35:33: error: fs/nandfs/nandfs_fs.h: No such file or directory
stdin:46:24: error: net/netmap.h: No such file or directory
(As a consequence ?) clang doesn't pick up 2 symbols: MFI_CMD32 and
MFIIO_PASSTHRU32 which are defined if COMPAT_FREEBSD32 is set in
sys/dev/mfi/mfi_ioctl.h
I don't think this has anything to do with clang, since you can see
CPP=cpp in that command line, which usually is GNU cpp. For clang,
you should set CPP=clang-cpp instead.
What seems to be happening is that certain headers it expects are not
install in ${DESTDIR}, which should be ${WORLDTMP} during buildworld.
It is possible that due to all the WITHOUT_ options you have defined,
some of those headers may not be installed.
2. lint calls tmp/usr/cc directly:
buildworld-clang.log:=== usr.bin/xlint/llib (all)
buildworld-clang.log:lint -cghapbx -Cposix
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib/llib-lposix
buildworld-clang.log:lint: cannot exec
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/bin/cc: No such
file or directory
buildworld-clang.log:Stop in
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib.
A link from cc to clang in the same directory fixes that.
Yes, that is a known problem in lint, but I have no great urge to fix
it. IMHO lint should be axed, the program is simply obsolete.
___
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 world with clang ToT
On 2012-09-12 12:46, Edward Meewis wrote: Has anyone recently built FreeBSD10-current with clang on a FreeBSD9 amd64 system? I've bumped into a number of issues. Mainly, buildworld picks up the old system includes, which miss newly introduced symbols; same thing with libraries. I fixed that by pointing compiler and linker to /usr/obj/FreeBSD-HEAD/tmp/include and lib. Strange, it should not do that. How exactly did you point compiler and linker? What is your make.conf and/or src.conf? If had to hazard a guess based on this information alone, I would say you are assigning to CFLAGS somewhere, instead of using +=. Building stops in lib/libstand: /usr/home/emeewis/src/FreeBSD-HEAD/lib/libstand/i386/_setjmp.S:50:82: error: register %rbp is only available in 64-bit mode .text; .p2align 4,0x90; .globl _setjmp; .type _setjmp,@function; _setjmp:; pushq %rbp; movq %rsp,%rbp; call .mcount; popq %rbp; 9: Libstand is build in i386 mode, but includes machine/asm.h in _setjmp.S. Is there a way to force it to use i386/asm.h? I had a go with gcc, but I got the same results... There must be a certain setting on your system which causes this. Most likely, it is again using your existing system headers, instead of those in /usr/obj. ___ 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 world with clang ToT
Hi Dimitry,
On 12-09-12 13:09, Dimitry Andric wrote:
On 2012-09-12 12:46, Edward Meewis wrote:
Has anyone recently built FreeBSD10-current with clang on a FreeBSD9
amd64 system?
I've bumped into a number of issues. Mainly, buildworld picks up the old
system includes, which miss newly introduced symbols; same thing with
libraries. I fixed that by pointing compiler and linker to
/usr/obj/FreeBSD-HEAD/tmp/include and lib.
Strange, it should not do that. How exactly did you point compiler and
linker? What is your make.conf and/or src.conf?
If had to hazard a guess based on this information alone, I would say
you are assigning to CFLAGS somewhere, instead of using +=.
I added the following lines to each individual Makefile it stumbled on:
CFLAGS+= -I/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/include
LDADD+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
or:
LDFLAGS+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
I hope to find a better place to set those, but it will do for now.
Building stops in lib/libstand:
/usr/home/emeewis/src/FreeBSD-HEAD/lib/libstand/i386/_setjmp.S:50:82:
error: register %rbp is only available in 64-bit mode
.text; .p2align 4,0x90; .globl _setjmp; .type _setjmp,@function;
_setjmp:; pushq %rbp; movq %rsp,%rbp; call .mcount; popq %rbp; 9:
Libstand is build in i386 mode, but includes machine/asm.h in _setjmp.S.
Is there a way to force it to use i386/asm.h?
I had a go with gcc, but I got the same results...
There must be a certain setting on your system which causes this. Most
likely, it is again using your existing system headers, instead of those
in /usr/obj.
I suppose so, but where?
Thanks for your help, Edward
/etc/make.conf:
--
#
# Clang
#
USE_CLANG?=no
#
.if ${USE_CLANG} == yes
.if !defined(CC) || ${CC} == cc
CC=/usr/local/bin/clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=/usr/local/bin/clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
#CPP=/usr/local/bin/clang
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
.endif
#
# Build kernel options
#
BOOTWAIT=5
KERNCONF=AMD-Minimal
#
# Kernel modules
#
# Needed by ssh and bind
MODULES_OVERRIDE+=random
#
# Power management options
MODULES_OVERRIDE+=cpuctl cpufreq
#MODULES_OVERRIDE+=coretemp
#
# Legacy ATA support
MODULES_OVERRIDE+=ata/atacore ata/atapci
MODULES_OVERRIDE+=ata/atapicd
MODULES_OVERRIDE+=md
#
# File systems
MODULES_OVERRIDE+=procfs pseudofs
MODULES_OVERRIDE+=msdosfs cd9660
MODULES_OVERRIDE+=krpc nfscl nfscommon nfslock nfssvc
MODULES_OVERRIDE+=libiconv smbfs
#MODULES_OVERRIDE+=ntfs
#
# Networking
MODULES_OVERRIDE+=netgraph/netgraph
MODULES_OVERRIDE+=mii re
#
# USB
MODULES_OVERRIDE+=usb/usb
MODULES_OVERRIDE+=usb/ugensa
MODULES_OVERRIDE+=usb/uhci usb/ohci usb/ehci
# HIDs, keyboards and mice
MODULES_OVERRIDE+=usb/uhid usb/ukbd usb/ums
# Printers
#MODULES_OVERRIDE+=usb/ulpt
# Storage
MODULES_OVERRIDE+=usb/umass
#
# Graphic display
MODULES_OVERRIDE+=agp
MODULES_OVERRIDE+=drm/drm drm/i915
#
# Serial port
MODULES_OVERRIDE+=uart
#
# Parallel port
MODULES_OVERRIDE+=ppc ppbus lpt
# Parallel Geek port
#MODULES_OVERRIDE+=ppi
#
# I2C bus
#MODULES_OVERRIDE+=i2c/iicbus i2c/smbus i2c/smb
#MODULES_OVERRIDE+=i2c/controllers/intpm
#
# Sound
MODULES_OVERRIDE+=sound/sound sound/driver/hda
#
# Linux emulation
#MODULES_OVERRIDE+=linux linprocfs
#
# Needed for firefox HTML5
#MODULES_OVERRIDE+=sem
# added by use.perl 2012-02-16 20:40:59
PERL_VERSION=5.12.4
/etc/src.conf
--
# src.conf - Source build options
#WITHOUT_TOOLCHAINS=yes
WITHOUT_ATM=yes
WITHOUT_BLUETOOTH=yes
WITHOUT_BSNMP=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CTM=yes
WITHOUT_CVS=yes
WITHOUT_GCC=yes
#WITHOUT_GROFF=yes
WITHOUT_IPX=yes
WITHOUT_IPX_SUPPORT=yes
WITHOUT_LIB32=yes
WITHOUT_NCP=yes
WITHOUT_OBJC=yes
WITHOUT_PPP=yes
WITHOUT_RCMDS=yes
WITHOUT_RESCUE=yes
WITHOUT_RCS=yes
WITHOUT_SENDMAIL=yes
WITHOUT_WIRELESS=yes
WITHOUT_WIRELESS_SUPPORT=yes
WITHOUT_WPA_SUPPLICANT_EAPOL=yes
WITHOUT_ZFS=yes
___
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 world with clang ToT
On 2012-09-12 13:45, Edward Meewis wrote:
...
I added the following lines to each individual Makefile it stumbled on:
CFLAGS+= -I/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/include
LDADD+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
or:
LDFLAGS+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
I hope to find a better place to set those, but it will do for now.
Normally this should never be done, but it could work in theory.
...
There must be a certain setting on your system which causes this. Most
likely, it is again using your existing system headers, instead of those
in /usr/obj.
I suppose so, but where?
...
/etc/make.conf:
--
#
# Clang
#
USE_CLANG?=no
#
.if ${USE_CLANG} == yes
.if !defined(CC) || ${CC} == cc
CC=/usr/local/bin/clang
Don't use absolute paths here, it will not work for buildworld. This
has been discussed recently in another thread. (Not an issue with
clang or gcc, but with the way buildworld bootstraps its compiler in
general.)
...
/etc/src.conf
--
# src.conf - Source build options
#WITHOUT_TOOLCHAINS=yes
WITHOUT_ATM=yes
WITHOUT_BLUETOOTH=yes
WITHOUT_BSNMP=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CTM=yes
WITHOUT_CVS=yes
WITHOUT_GCC=yes
I don't think buildworld can ever work correctly, if you have both
WITHOUT_CLANG and WITHOUT_GCC defined, at least not with how it is
currently implemented.
At least, certainly not for a -CURRENT build on -STABLE, that is. If
you'd build this on a fully installed -CURRENT box, it might complete,
but again, no guarantees.
Try building with gcc, while removing the WITHOUT_GCC line, or building
with clang, while removing the WITHOUT_CLANG line.
___
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 world with clang ToT
On 12-09-12 14:15, Dimitry Andric wrote: Try building with gcc, while removing the WITHOUT_GCC line, or building with clang, while removing the WITHOUT_CLANG line. I'll be damned, that did it! (with gcc) Thanks, guys! -- Ed. ___ 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 world with clang ToT
On 2012-09-12 17:31, Edward Meewis wrote: On 12-09-12 14:15, Dimitry Andric wrote: Try building with gcc, while removing the WITHOUT_GCC line, or building with clang, while removing the WITHOUT_CLANG line. I'll be damned, that did it! (with gcc) Note that some people have been working on external toolchain support. This would aim to make it possible to do what you were trying, e.g. building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG and WITHOUT_GCC, among others. However, I am not sure how far these efforts have come by now. :-) ___ 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 world with clang ToT
On Wed, Sep 12, 2012 at 06:18:06PM +0200, Dimitry Andric wrote: On 2012-09-12 17:31, Edward Meewis wrote: On 12-09-12 14:15, Dimitry Andric wrote: Try building with gcc, while removing the WITHOUT_GCC line, or building with clang, while removing the WITHOUT_CLANG line. I'll be damned, that did it! (with gcc) Note that some people have been working on external toolchain support. This would aim to make it possible to do what you were trying, e.g. building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG and WITHOUT_GCC, among others. However, I am not sure how far these efforts have come by now. :-) I've got some patches that aren't quite ready for prime-time that allow me to cross build world with an external CLANG. I'll post them to the toolchain@ list when they are closer to ready (hopefully quite soon). -- Brooks pgpnOOlvb5voa.pgp Description: PGP signature
Re: Building world with clang
Dimitry Andric dimi...@andric.com writes:
Alexander Kabaev kab...@gmail.com writes:
Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment.
I have not tested make buildenv with this method, but since ${CC} is
modified, not ${CFLAGS}, there is a reasonable chance that it might
work. :)
I'm not a big fan of reasonable chances when it comes to the
toolchain.
Note a similar method is already being using for the build32 stage on
amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
appended.
No, what is used is a variant of method 1 *on top of* method 2 for a
very specific case. You need a special version of clang (method 2)
anyway to support cross-building.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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 world with clang
On 2010-08-18 11:15, Dag-Erling Smørgrav wrote: I'm not a big fan of reasonable chances when it comes to the toolchain. Me neither, which is why I created method 2 originally. :) The -isysroot method was invented by Roman Divacky in r198248. No, what is used is a variant of method 1 *on top of* method 2 for a very specific case. You need a special version of clang (method 2) anyway to support cross-building. Eventually, clang should support building objects for all targets from one executable, but not in the short term, unfortunately... ___ 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 world with clang
Dimitry Andric dimi...@andric.com writes: Dag-Erling Smørgrav d...@des.no writes: No, what is used is a variant of method 1 *on top of* method 2 for a very specific case. You need a special version of clang (method 2) anyway to support cross-building. Eventually, clang should support building objects for all targets from one executable, but not in the short term, unfortunately... That doesn't matter. You still need two versions of the compiler. If you're cross-building sprac64 on an i386 machine, for instance, you need an i386 version of the compiler that produces sparc64 binaries *and* a sparc64 version that produces sparc64 binaries. The former is used only during the build, the latter is what will be installed on the target. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 world with clang
Hello Dimitry!
* Dimitry Andric dimi...@andric.com wrote:
@@ -408,9 +411,10 @@ static bool getWindowsSDKDir(std::string path) {
void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple triple,
const HeaderSearchOptions
HSOpts) {
-#if 0 /* Remove unneeded include paths. */
// FIXME: temporary hack: hard-coded paths.
- AddPath(/usr/local/include, System, true, false, false);
+#ifndef __FreeBSD__
+ AddPath(CLANG_PREFIX /usr/local/include, System, true, false, false);
+#endif
// Builtin includes use #include_next directives and should be positioned
// just prior C include dirs.
Hmmm... Do we really want this? /usr/local/include is omitted from our
compiler include paths on purpose, to prevent accidental linkage against
pieces of software built from ports.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgp8aoYpsSw3U.pgp
Description: PGP signature
Re: Building world with clang
On 2010-08-17 13:40, Ed Schouten wrote: +#ifndef __FreeBSD__ + AddPath(CLANG_PREFIX /usr/local/include, System, true, false, false); +#endif // Builtin includes use #include_next directives and should be positioned // just prior C include dirs. Hmmm... Do we really want this? /usr/local/include is omitted from our compiler include paths on purpose, to prevent accidental linkage against pieces of software built from ports. That is why it says #ifndef __FreeBSD__ :) I just changed the #if 0 from the clangbsd tree to this, so it is more palatable for upstream. ___ 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 world with clang
* Dimitry Andric dimi...@andric.com wrote: On 2010-08-17 13:40, Ed Schouten wrote: +#ifndef __FreeBSD__ + AddPath(CLANG_PREFIX /usr/local/include, System, true, false, false); +#endif // Builtin includes use #include_next directives and should be positioned // just prior C include dirs. Hmmm... Do we really want this? /usr/local/include is omitted from our compiler include paths on purpose, to prevent accidental linkage against pieces of software built from ports. That is why it says #ifndef __FreeBSD__ :) I just changed the #if 0 from the clangbsd tree to this, so it is more palatable for upstream. Sorry about that. I only read the `#if 0' part. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp17lcaec3D1.pgp Description: PGP signature
Re: Building world with clang
Hi,
On 17 Aug 2010, at 12:32, Dimitry Andric wrote:
Hi,
Since clang has gone into the tree, there has been an effort to get head
in a state where world can optionally be built with it.
[...]
Now, for building clang as the bootstrap compiler, there are basically
two methods to make it use the correct headers, C startup objects, and
libraries from the object tree (${WORLDTMP}):
1) The isysroot method: build a regular version of clang, and make
sure WMAKEENV contains something like:
CC=${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
-L${WORLDTMP}/usr/lib/
2) The tools-prefix method: build a special version of clang, that
has its default search paths for headers, startup objects and
libraries modified, to look for everything under ${WORLDTMP}.
Method 1) is used in the clangbsd project branch.
Method 2) is similar to what is used for building the in-tree gcc as
the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is
defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
search paths get prefixed with it.
An advantage of method 1) is that it does not require any modifications
to the compiler, and basically just a few extra command line arguments.
The same method could probably even be made to work for gcc.
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
This could be viewed as a bug ...
so there is still a chance that headers, objects or
libraries outside of ${WORLDTMP} will be picked up during the world
stage.
... and the last thing you want in buildworld is this kind of POLA violation ...
An advantage of method 2) is that you can be 100% sure all built-in
search paths of the bootstrap compiler point to directories under
${WORLDTMP}. Of course, a disadvantage is that you have to make some
modifications to the compiler source itself.
... so, which fix to the compiler do you want to make?
[etc]
--
Bob Bishop
r...@gid.co.uk
___
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 world with clang
On 2010-08-17 13:49, Bob Bishop wrote:
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
This could be viewed as a bug ...
It is probably a bit more complicated than that. Let me expand a bit
on those compiler flags (and note that clang tries to mimic gcc's
interpretation of them, but is not always perfect).
The -isysroot option
The -isysroot option is supposed to 'reset' the root for include files
to the specified path, according to the gcc documentation. If I compile
an empty .c file with gcc -v -S, the default include paths are
printed:
/usr/include/gcc/4.2
/usr/include
If you now add -isysroot ${WORLDTMP} (the default value of WORLDTMP is
/usr/obj/usr/src/tmp), the resulting include paths become:
/usr/include/gcc/4.2
${WORLDTMP}/usr/include
So unfortunately, gcc seems to only prepend the isysroot path to one of
the directories.
Clang's default include paths are:
/usr/include/clang/2.8
/usr/include
With the same -isysroot option added, they become:
${WORLDTMP}/usr/include/clang/2.8
${WORLDTMP}/usr/include
E.g. clang does the right thing here.
The -B option
=
The -B option is supposed to ...[specify] where to find the
executables, libraries, include files, and data files of the compiler
itself. This option is a bit strange, since it is used for finding
both executables (cc1, as, ld), objects (crt*.o) and libraries.
If you run gcc -print-search-dirs, it gives its defaults:
programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
libraries: =/usr/lib/:/usr/lib/
When you add -B${WORLDTMP}/usr/libexec/ (where the cross-tools
built cc1 and cc1plus are), it gives:
programs:
=${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
libraries:
=${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/lib/:/usr/lib/
Thus, the -B path is prepended (why it does it twice, I do not know;
probably a bug), but the defaults are *not* removed, so there is still a
risk of picking up an incorrect executable.
Note the path is also prepended to the libraries path, which is rather
useless; there are never any .o or .a files in a libexec directory. To
fix that path up, you would need to add yet *another* -B option, and you
probably also need yet another -B option to make it find the correct as
and ld. The final command line would then become:
gcc -B${WORLDTMP}/usr/bin/ -B${WORLDTMP}/usr/libexec/ -B${WORLDTMP}/usr/lib/
giving the following search dirs:
programs:
=${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
libraries:
=${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/lib/:/usr/lib/
Clang also implements the -B option, but it is not additive yet, so
there is no way to specify both the ${WORLDTMP}/usr/bin directory (for
finding its second stage, as and ld), and ${WORLDTMP}/usr/lib (for
finding startup objects and libraries).
This is also the reason clang-bootstrap-isysroot.diff needs to create
symlinks from ${WORLDTMP}/usr/bin/as and ld to ${WORLDTMP}/usr/lib, as
only the latter directory is specified with -B, and it otherwise would
not be able to find the correct as and ld.
The -L option
=
The -L option just adds the specified directory to the library search
path. It puts them before the built-in paths, but it does not disable
those either. Moreover, the -L paths are *not* used to find the CRT
startup objects:
$ gcc -L${WORLDTMP}/usr/lib -v test.c
[...]
/usr/bin/as -o /tmp/ccZcUXwc.o /tmp/ccYTRRrk.s
/usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o test
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib
-L/usr/lib -L/usr/lib /tmp/ccZcUXwc.o -lgcc --as-needed -lgcc_s --no-as-needed
-lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
The behaviour of clang is the same for this option, so it does not
improve the situation: it is still possible for libraries outside of
${WORLDTMP} to be found.
An advantage of method 2) is that you can be 100% sure all built-in
search paths of the bootstrap compiler point to directories under
${WORLDTMP}. Of course, a disadvantage is that you have to make some
modifications to the compiler source itself.
... so, which fix to the compiler do you want to make?
My personal preference is method 2), e.g. modify the compiler's
built-in paths, but it is more reasonable to present both methods, and
ask for opinions. Someone may even know another good method. :)
___
freebsd-current@freebsd.org mailing list
Re: Building world with clang
On Tue, Aug 17, 2010 at 1:49 PM, Bob Bishop r...@gid.co.uk wrote: On 17 Aug 2010, at 12:32, Dimitry Andric wrote: However, a disadvantage is that the built-in search paths of the bootstrap compiler are not entirely disabled by using the -isysroot, -B and -L flags, This could be viewed as a bug ... For clarification, did you (Dimitry, that is) mean a) The paths are still there so they could resurface if some Makefile doesn't specify those flags , or b) they sometimes come into play even when using the appropriate flags? -- Daniel Nebdal ___ 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 world with clang
On Tue, 17 Aug 2010 13:32:39 +0200
Dimitry Andric dimi...@andric.com wrote:
Hi,
Since clang has gone into the tree, there has been an effort to get
head in a state where world can optionally be built with it. A
number of changes required for this have already been committed,
mainly thanks to Ed Schouten, Roman Divacky and Rui Paulo. Most of
these changes were adapted from the clangbsd project branch.
There are several other changes in the queue, pending review and/or
further enhancement, but I would like to solicit your comments about
one particular set: the changes required to let buildworld use clang
as the compiler.
Probably the most logical way to specify that you want world built
with clang, is to put CC=clang and CXX=clang++ in /etc/src.conf. Any
necessary modifications to Makefile.inc1 or bsd.*.mk can then be put
between conditionals like:
.if ${CC:T:Mclang} == clang
[...stuff specific to clang...]
.endif
so nothing will change for non-clang builds.
Now, for building clang as the bootstrap compiler, there are basically
two methods to make it use the correct headers, C startup objects, and
libraries from the object tree (${WORLDTMP}):
1) The isysroot method: build a regular version of clang, and make
sure WMAKEENV contains something like:
CC=${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
-L${WORLDTMP}/usr/lib/
2) The tools-prefix method: build a special version of clang, that
has its default search paths for headers, startup objects and
libraries modified, to look for everything under ${WORLDTMP}.
Method 1) is used in the clangbsd project branch.
Method 2) is similar to what is used for building the in-tree gcc as
the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is
defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
search paths get prefixed with it.
An advantage of method 1) is that it does not require any
modifications to the compiler, and basically just a few extra command
line arguments. The same method could probably even be made to work
for gcc.
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot,
-B and -L flags, so there is still a chance that headers, objects or
libraries outside of ${WORLDTMP} will be picked up during the world
stage.
An advantage of method 2) is that you can be 100% sure all built-in
search paths of the bootstrap compiler point to directories under
${WORLDTMP}. Of course, a disadvantage is that you have to make some
modifications to the compiler source itself.
I would like to hear your opinions about which method is preferred, or
if there may be another good way to solve the bootstrap compiler
issue.
I have also attached two patches to this mail, which can be applied to
head, to show the exact set of changes required for each method.
Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Building world with clang
On 2010-08-17 15:03, Daniel Nebdal wrote:
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
...
For clarification, did you (Dimitry, that is) mean
a) The paths are still there so they could resurface if some Makefile
doesn't specify those flags , or
b) they sometimes come into play even when using the appropriate flags?
Any sub-makefiles would not have to specify those flags explicitly,
since they were added to ${CC} and ${CXX}.
But what I meant is that even if you specify those flags, the compiler
still searches for headers and libraries in the base system. So if some
header is removed from /usr/src, for example, but is still available in
/usr/include, it can be erroneously picked up during buildworld.
___
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 world with clang
On 2010-08-17 15:15, Alexander Kabaev wrote:
Dimitry Andric dimi...@andric.com wrote:
...
1) The isysroot method: build a regular version of clang, and make
sure WMAKEENV contains something like:
CC=${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
-L${WORLDTMP}/usr/lib/
2) The tools-prefix method: build a special version of clang, that
has its default search paths for headers, startup objects and
libraries modified, to look for everything under ${WORLDTMP}.
...
Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment.
I have not tested make buildenv with this method, but since ${CC} is
modified, not ${CFLAGS}, there is a reasonable chance that it might
work. :)
Note a similar method is already being using for the build32 stage on
amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
appended.
___
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 world with clang
On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric dimi...@andric.com wrote:
On 2010-08-17 15:03, Daniel Nebdal wrote:
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
...
For clarification, did you (Dimitry, that is) mean
a) The paths are still there so they could resurface if some Makefile
doesn't specify those flags , or
b) they sometimes come into play even when using the appropriate flags?
Any sub-makefiles would not have to specify those flags explicitly,
since they were added to ${CC} and ${CXX}.
But what I meant is that even if you specify those flags, the compiler
still searches for headers and libraries in the base system. So if some
header is removed from /usr/src, for example, but is still available in
/usr/include, it can be erroneously picked up during buildworld.
Mmh, I just read through the in-detail description you gave in another
mail. It's a bit surprising that there isn't a simple and reliable way
to disable/replace all hardcoded paths, but I guess it doesn't come up
that often.
As a third possibility, hacking a real -drop-all-builtin-paths flag
into the local copies of both compilers could work (essentially being
a cleanup of your alternative 1), though there's still the issues with
-B. All in all, I agree that your alternative 2 sounds better.
--
Daniel Nebdal
___
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 world with clang
On 2010-08-17 16:28, Daniel Nebdal wrote: Mmh, I just read through the in-detail description you gave in another mail. It's a bit surprising that there isn't a simple and reliable way to disable/replace all hardcoded paths, but I guess it doesn't come up that often. Well, except when you want to bootstrap something. :) I guess this whole issue is just not as applicable to Linux, where gcc's main development takes place. As a third possibility, hacking a real -drop-all-builtin-paths flag into the local copies of both compilers could work The idea of method 1) is that you do not modify the compiler at all, making it potentially easier to hook in any new compilers, provided they are option-compatible with gcc. ___ 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 world with clang
On Tue, Aug 17, 2010 at 10:28 AM, Daniel Nebdal dneb...@gmail.com wrote:
On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric dimi...@andric.com wrote:
On 2010-08-17 15:03, Daniel Nebdal wrote:
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
...
For clarification, did you (Dimitry, that is) mean
a) The paths are still there so they could resurface if some Makefile
doesn't specify those flags , or
b) they sometimes come into play even when using the appropriate flags?
Any sub-makefiles would not have to specify those flags explicitly,
since they were added to ${CC} and ${CXX}.
But what I meant is that even if you specify those flags, the compiler
still searches for headers and libraries in the base system. So if some
header is removed from /usr/src, for example, but is still available in
/usr/include, it can be erroneously picked up during buildworld.
Mmh, I just read through the in-detail description you gave in another
mail. It's a bit surprising that there isn't a simple and reliable way
to disable/replace all hardcoded paths, but I guess it doesn't come up
that often.
what about -nostdinc ?
Do not search the standard system directories for header files.
Or will this also disable the command line equivalents ?
--
Eitan Adler
___
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 world with clang
On 2010-08-17 17:04, Eitan Adler wrote:
what about -nostdinc ?
Do not search the standard system directories for header files.
Or will this also disable the command line equivalents ?
It seems that -isysroot doesn't work with that:
$ gcc -nostdinc -isysroot ${WORLDTMP} -S -v test.c
[...]
#include ... search starts here:
#include ... search starts here:
End of search list.
So you have to cumbersomely specify all needed include directories by
hand instead:
$ gcc -nostdinc -isystem ${WORLDTMP}/usr/include/gcc/4.2 -isystem
${WORLDTMP}/usr/include -S -v testc
[...]
#include ... search starts here:
#include ... search starts here:
${WORLDTMP}/usr/include/gcc/4.2
${WORLDTMP}/usr/include
End of search list.
An alternative that almost works properly, is when you use multiple -B
options:
- The first pointing to ${WORLDTMP}/usr/bin, where as and ld live
- The second pointing to ${WORLDTMP}/usr/libexec, where cc1, cc1obj and
cc1plus live
- The third pointing to ${WORLDTMP}/usr/lib, where the startup objects
and the libraries live
This results in:
$ gcc -B${WORLDTMP}/usr/bin -B${WORLDTMP}/usr/libexec -B${WORLDTMP}/usr/lib
-v test.c -o test
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase
test.c -auxbase test -version -o /tmp/cceCBnL1.s
#include ... search starts here:
#include ... search starts here:
${WORLDTMP}/usr/include/gcc/4.2
${WORLDTMP}/usr/include
End of search list.
GNU C version 4.2.1 20070719 [FreeBSD] (i386-undermydesk-freebsd)
compiled by GNU C version 4.2.1 20070719 [FreeBSD].
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948
Compiler executable checksum: c9b7cdb24796993b910f114335b27daf
${WORLDTMP}/usr/bin/as -o /tmp/ccTZPpZn.o /tmp/cceCBnL1.s
${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker
/libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o
${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/bin
-L${WORLDTMP}/usr/bin -L${WORLDTMP}/usr/libexec -L${WORLDTMP}/usr/libexec
-L${WORLDTMP}/usr/lib -L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib
/tmp/ccTZPpZn.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed ${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
The include directories have been completely reset, but unfortunately
you can still see the default library directory /usr/lib in there.
Yet another alternative is to use the COMPILER_PATH and LIBRARY_PATH
environment variables, which can contain colon-separated directories:
$ COMPILER_PATH=${WORLDTMP}/usr/bin:${WORLDTMP}/usr/libexec
LIBRARY_PATH=${WORLDTMP}/usr/lib gcc -v hello.c -o hello
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase
test.c -auxbase test -version -o /tmp/cciXQvhb.s
#include ... search starts here:
#include ... search starts here:
${WORLDTMP}/usr/include/gcc/4.2
${WORLDTMP}/usr/include
End of search list.
GNU C version 4.2.1 20070719 [FreeBSD] (i386-undermydesk-freebsd)
compiled by GNU C version 4.2.1 20070719 [FreeBSD].
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948
Compiler executable checksum: c9b7cdb24796993b910f114335b27daf
${WORLDTMP}/usr/bin/as -o /tmp/ccKJZI5V.o /tmp/cciXQvhb.s
${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker
/libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o
${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib
-L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib /tmp/ccKJZI5V.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
Conclusion: it looks like there is no working option to disable the
built-in library directory /usr/lib.
___
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 world with debugging symbols [broken?]
On Wednesday 31 March 2010 14:52:53 Giorgos Keramidas wrote: On Tue, 30 Mar 2010 15:10:58 -0400, John Baldwin j...@freebsd.org wrote: On Tuesday 30 March 2010 11:48:58 am Giorgos Keramidas wrote: +.It Va DEBUG_FLAGS +Defines a set of debugging flags that will be used to build all userland +binaries under +.Pa /usr/src . +When +.Va DEBUG_FLAGS +is defined, the +.Cm install +and +.Cm installworld +targets install binaries from the current +.Va MAKEOBJDIRPREFIX +without stripping too, so that debugging information is retained in the +installed binaries. I would drop the too and start 'so' on a new line (at least that is my interpretation of the line-break rules we use for mdoc). Other than that I think this looks fine. Fixed and committed in r205978. Thanks :) Hi, I've gotten several reports that cuse4bsd and other kernel modules built outside the kernel tree no longer load. Any clues about what is wrong? Is this a compiler issue, or has it got to do with missing/wrong symbols? For example one guy writes: On Tue, 22 Jun 2010 19:11:09 +0200 Hans Petter Selasky hsela...@freebsd.org wrote: On Tuesday 22 June 2010 18:06:58 Ted Faber wrote: FWIW, I'm seeing the same thing on 8.1-PRERELEASE csupped from yesterday. It's been going on foe a while, but I haven't been able to find the bug. (I was literally sitting down to type an e-mail about it when I saw this thread.) Same symptom: cuse4bsd loads but no device file appears in the /dev I also don't see the printfs from cuse_kern_init show up in the log. It seems like something's changed in the kernel module load path somehow. FWIW, the example in /usr/share/examples/kld/cdev/ doesn't work for me either. I've attached the verbose boot. Cuse4bsd is current from ports, recompiled after the new kernel install: $ pkg_info | grep cuse cuse4bsd-kmod-0.1.11 Cuse4BSD character device loopback driver for userspace Here's my loader.conf: $ cat /boot/loader.conf beastie_disable=YES acpi_ibm_load=YES snd_ich_load=YES cuse4bsd_load=YES The module is in the right place and seems to load: $ ls -l /boot/modules/ total 18 -r-xr-xr-x 1 root wheel 16505 Jun 21 19:02 cuse4bsd.ko $ kldstat Id Refs AddressSize Name 1 36 0xc040 bb8ea8 kernel 21 0xc0fb9000 7224 snd_ich.ko 32 0xc0fc1000 577a4sound.ko 41 0xc1019000 5244 acpi_ibm.ko 51 0xc101f000 4610 cuse4bsd.ko 61 0xc59c9000 8000 linprocfs.ko 71 0xc5a1d000 26000linux.ko 81 0xc5b07000 11000ipfw.ko 91 0xc5b18000 d000 libalias.ko 101 0xc5e2e000 2000 green_saver.ko 111 0xc5f0d000 68000radeon.ko 121 0xc5f84000 14000drm.ko $ uname -a FreeBSD praxis.lunabase.org 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #38: Mon Jun 21 17:14:31 PDT 2010 r...@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 I'm happy to try fixes or provide information. Are you sure the kernel sources are matched with your kernel. I find this rather odd. laptop# svn info Path: . URL: svn://svn.freebsd.by/base/head Repository Root: svn://svn.freebsd.by/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 209412 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 209408 Last Changed Date: 2010-06-22 03:26:07 +0300 (Tue, 22 Jun 2010) svn.freebsd.by - nearest svn mirror for me. [usern...@svn]~%crontab -l|grep svn 0 */2 * * * /usr/local/bin/svnsync sync file:///usr/local/repositories/freebsd/base/ %uname -a FreeBSD laptop.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #7 r209412M: Tue Jun 22 11:23:15 EEST 2010 r...@laptop.domain:/usr/obj/usr/src/sys/b450 i386 laptop# pwd /usr/src laptop# svn st laptop# The Cuse4BSD printout is called from a SYSINIT. If sysinits don't work then something fundamental is wrong. Also check: find /boot -name cuse4bsd* laptop# find /boot -name 'cuse*' /boot/modules/cuse4bsd.ko laptop# printf(Cuse4BSD v%d.%d.%d @ /dev/cuse\n, (CUSE_VERSION 16) 0xFF, (CUSE_VERSION 8) 0xFF, (CUSE_VERSION 0) 0xFF); } SYSINIT(cuse_kern_init, SI_SUB_DEVFS, SI_ORDER_ANY, cuse_kern_init, 0); --HPS ___ 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 world with debugging symbols [broken?]
I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set ___ 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 world with debugging symbols [broken?]
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set HPS: I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:28cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:28c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:28cc A __start_set_sysinit_set ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set ./cuse4bsd.ko:3194 d cuse_kern_init_sys_init ./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpQWyNSjmQCd.pgp Description: PGP signature
Re: building world on pre-signals-change systems
Ben Rosengart wrote: If I recall correctly, someone posted recently that the time is not far off when one will be able to make world on an older, pre-signals-change system. You can already do a buildworld, but you still have to make and install a new kernel in order to do a installworld. At this time you should therefore not use `make world' yet. A full upgrade path can only be offered if the kernel is also made along with a buildworld and is also installed as part of the installation process. This requires a bit more work though. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: building world
On Fri, Apr 9, 1999, Dana Huggard wrote: I see there has been some discussions around building world. I may have missed or forgotten something, or even not read the right README. Also seen some captured text of builds and where they fail. In gnu/usr.bin/cc mine fails as well, but complains of a missing `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago I cvsup'ed the complete /src. After a few attempts it's been building fine at least once a day till this missing header. Let me guess. You ran 'make -j4 buildworld' (or make -janything buildworld)? :) Cheers, Dana_H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- = * This process can check if this value is * * zero, and if it is, it does something* * child-like. -Forbes Burkowski, CS 454 * = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: building world
In gnu/usr.bin/cc mine fails as well, but complains of a missing `hconfig.h`, which in turn causes a screenfull of errrors. cd /usr/src make cleandir ; make cleandir then build your world normally and tell me if you still have the error. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: building world
gnu/usr.bin/cc mine fails as well, but complains of a missing `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago I know you've heard this before WRT to cc_tools/, but... is should be fixed now. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
