Re: Include file search path
On Wed, Sep 14, 2011 at 8:23 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, ... ping, Warner ? FWIW, I guess that in 4 months, either you had time to finish the patch, or I could have found to time to complete it myself based on your incomplete version. I'd really be interested to benchmark recent, decent, compiler. I've pinged Warner multiple times with no response on this issue apart from the first reply. I'll try to compile all of the details in this thread and do my best to engineer the work from scratch because it appears that the work was never made available for public consumption. So rather than wait for 2038 to roll around, I'll talk to folks (brooks, etc) and just get it done. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi, On Fri, Jul 8, 2011 at 5:16 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Jun 25, 2011 at 2:01 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Mon, Jun 6, 2011 at 5:37 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote: On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. any chances to have a look at the patch or should I wait for the final commit ? ping ? ping ? ping, Warner ? FWIW, I guess that in 4 months, either you had time to finish the patch, or I could have found to time to complete it myself based on your incomplete version. I'd really be interested to benchmark recent, decent, compiler. Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi, On Sat, Jun 25, 2011 at 2:01 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Mon, Jun 6, 2011 at 5:37 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote: On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. any chances to have a look at the patch or should I wait for the final commit ? ping ? ping ? - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi, On Mon, Jun 6, 2011 at 5:37 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote: On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. any chances to have a look at the patch or should I wait for the final commit ? ping ? - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote: On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. any chances to have a look at the patch or should I wait for the final commit ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On Wed, 30 Mar 2011, Warner Losh wrote: On Mar 30, 2011, at 9:23 AM, Dimitry Andric wrote: This is a rather nasty hack, though. If we can make it work, we should probably try using --sysroot instead, or alternatively, -nostdinc and adding include dirs by hand. The same for executable and library search paths, although I am not sure if there is a way to completely reset those with the current options. I'm pretty sure that the origins of this hack pre-dates the -sysroot feature in gcc. It works in -current and has for years, so nobody has cared enough to even contemplate changing it. If you can make the sysroot feature work, that would be great, since that would allow us to skip the compiler building phase if we were building using external compilers. I have some patches to make that work, but this very problem is what I'd worked my way up to. It works well if you are building current on current, but not so well if you are mixing versions (you can mix architectures if you are using the xdev feature I put in a while ago, but even that has one or two niggles I need to iron out). Count me as another eager consumer awaiting a nice answer to the general cross-compile problem. I'm really looking for three things: (1) A bit more intelligence from our build framework regarding not rebuilding the toolchain quite so many times! I'd like to be able to do a buildworld with TARGET_ARCH with significantly improved performance. Perhaps we can do this already, in which case a pointer considered welcome. (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? (3) Making it easy to plug in, first, an external gcc easily, and second, an external clang/LLVM. One worrying point for me on the last one is that we can't yet build the whole kernel with clang/LLVM, at least for i386/amd64, so I guess you need both external gcc *and* external clang/LLVM? We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On Apr 2, 2011, at 12:29 PM, Robert Watson wrote: On Wed, 30 Mar 2011, Warner Losh wrote: On Mar 30, 2011, at 9:23 AM, Dimitry Andric wrote: This is a rather nasty hack, though. If we can make it work, we should probably try using --sysroot instead, or alternatively, -nostdinc and adding include dirs by hand. The same for executable and library search paths, although I am not sure if there is a way to completely reset those with the current options. I'm pretty sure that the origins of this hack pre-dates the -sysroot feature in gcc. It works in -current and has for years, so nobody has cared enough to even contemplate changing it. If you can make the sysroot feature work, that would be great, since that would allow us to skip the compiler building phase if we were building using external compilers. I have some patches to make that work, but this very problem is what I'd worked my way up to. It works well if you are building current on current, but not so well if you are mixing versions (you can mix architectures if you are using the xdev feature I put in a while ago, but even that has one or two niggles I need to iron out). Count me as another eager consumer awaiting a nice answer to the general cross-compile problem. I'm really looking for three things: (1) A bit more intelligence from our build framework regarding not rebuilding the toolchain quite so many times! I'd like to be able to do a buildworld with TARGET_ARCH with significantly improved performance. Perhaps we can do this already, in which case a pointer considered welcome. External toolchain will allow us to not build the cross compiler. another knob will allow us to omit building gcc and binutils for the target. Between the two of these, we can be good. We already have the cross tool (xdev) targets that can build the FreeBSD compiler to build on other architectures. This is what I'm using in the external toolchain work that I've done (it is presently stalled, but should start up again soon). It turns out that this is necessary for arbitrary external toolchains, but not sufficient. The xdev targets build a compiler with a fixed include path which the targets also install into. Generic external tools will need the -sysroot parameters passed into the build since they can (and will) be built without it. (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. (3) Making it easy to plug in, first, an external gcc easily, and second, an external clang/LLVM. One worrying point for me on the last one is that we can't yet build the whole kernel with clang/LLVM, at least for i386/amd64, so I guess you need both external gcc *and* external clang/LLVM? Yes. The generic external piece is what I'm going towards. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On Tuesday, March 29, 2011 5:20:30 pm m...@freebsd.org wrote:
I thought I knew something about how the compiler looks for include
files, but now I think maybe I don't know much. :-)
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
I see in the gcc documentation that -I paths are searched before the
standards paths. But isn't the lack of -nostdinc a bug (not just for
libc, but for any library in /usr/src/lib)? It somewhat feels to me
that all of the libraries and binaries in the source distribution
should use -nostdinc and include only from the source distribution
itself. This isn't always an issue, but for source upgrades it seems
crucial, and for a hacker it saves difficulties with having to install
headers before re-building.
Is that the intent, and it's not fully implemented? How badly would
things break if -nostdinc was included in e.g. bsd.lib.mk? (This would
break non-base libraries, yes? But as a thought experiment for the
base, how far off are we?)
If you are building a library by hand you do want to use the includes from
/usr/include. I am not sure how we accomplish during buildworld (but we do).
I think we actually build the compiler in the cross-tools stage such that
it uses the /usr/include directory under {WORLDTMP} in place of /usr/include
in the default search path.
Some other folks might be able to verify that (perhaps ru@?).
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi,
On Wed, Mar 30, 2011 at 8:00 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, March 29, 2011 5:20:30 pm m...@freebsd.org wrote:
I thought I knew something about how the compiler looks for include
files, but now I think maybe I don't know much. :-)
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
I see in the gcc documentation that -I paths are searched before the
standards paths. But isn't the lack of -nostdinc a bug (not just for
libc, but for any library in /usr/src/lib)? It somewhat feels to me
that all of the libraries and binaries in the source distribution
should use -nostdinc and include only from the source distribution
itself. This isn't always an issue, but for source upgrades it seems
crucial, and for a hacker it saves difficulties with having to install
headers before re-building.
Is that the intent, and it's not fully implemented? How badly would
things break if -nostdinc was included in e.g. bsd.lib.mk? (This would
break non-base libraries, yes? But as a thought experiment for the
base, how far off are we?)
If you are building a library by hand you do want to use the includes from
/usr/include. I am not sure how we accomplish during buildworld (but we do).
I think we actually build the compiler in the cross-tools stage such that
it uses the /usr/include directory under {WORLDTMP} in place of /usr/include
in the default search path.
Some other folks might be able to verify that (perhaps ru@?).
FWIW (I've been hacking around `buildworld' lately), yes, and the
`_includes' stage is responsible to populate ${WORLDTMP}/usr/include.
The same goes for ${WORLDTMP}/usr/lib and `_libraries'. That was with
a 7-stable tree, I'm not sure how clang integrates in all this. The
same way I suppose.
- Arnaud
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On 2011-03-29 23:20, m...@freebsd.org wrote:
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
E.g:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -v -E -x c /dev/null -o /dev/null
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
/usr/obj/usr/src/tmp/usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o
/dev/null
#include ... search starts here:
#include ... search starts here:
/usr/obj/usr/src/tmp/usr/include/gcc/4.2
/usr/obj/usr/src/tmp/usr/include
End of search list.
and:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -print-search-dirs
install: /usr/obj/usr/src/tmp/usr/libexec/
programs:
=/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/
libraries: =/usr/obj/usr/src/tmp/usr/lib/:/usr/obj/usr/src/tmp/usr/lib/
This is a rather nasty hack, though. If we can make it work, we should
probably try using --sysroot instead, or alternatively, -nostdinc and
adding include dirs by hand. The same for executable and library search
paths, although I am not sure if there is a way to completely reset
those with the current options.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On 03/30/11 10:23, Dimitry Andric wrote:
On 2011-03-29 23:20, m...@freebsd.org wrote:
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
E.g:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -v -E -x c /dev/null -o /dev/null
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
/usr/obj/usr/src/tmp/usr/libexec/cc1 -E -quiet -v -D_LONGLONG
/dev/null -o /dev/null
#include ... search starts here:
#include ... search starts here:
/usr/obj/usr/src/tmp/usr/include/gcc/4.2
/usr/obj/usr/src/tmp/usr/include
End of search list.
and:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -print-search-dirs
install: /usr/obj/usr/src/tmp/usr/libexec/
programs:
=/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/
libraries: =/usr/obj/usr/src/tmp/usr/lib/:/usr/obj/usr/src/tmp/usr/lib/
This is a rather nasty hack, though. If we can make it work, we should
probably try using --sysroot instead, or alternatively, -nostdinc and
adding include dirs by hand. The same for executable and library search
paths, although I am not sure if there is a way to completely reset
those with the current options.
Since you need to build two compilers anyway (one for the current
system, to build the new one, and one to live in the new one, linked
against new libraries), I don't see that it's such a nasty hack.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On 2011-03-30 17:26, Nathan Whitehorn wrote:
...
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
...
Since you need to build two compilers anyway (one for the current
system, to build the new one, and one to live in the new one, linked
against new libraries), I don't see that it's such a nasty hack.
The building itself is not a problem, of course, and it is even required
if you want to update anything in the toolchain itself.
However, we have added some custom #ifdef FREEBSD_NATIVE parts to
support this feature, so you cannot use stock gcc source to build such a
temporary compiler. This can be problematic if we ever want to be able
to use toolchains outside of the source tree.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
On Mar 30, 2011, at 9:23 AM, Dimitry Andric wrote: This is a rather nasty hack, though. If we can make it work, we should probably try using --sysroot instead, or alternatively, -nostdinc and adding include dirs by hand. The same for executable and library search paths, although I am not sure if there is a way to completely reset those with the current options. I'm pretty sure that the origins of this hack pre-dates the -sysroot feature in gcc. It works in -current and has for years, so nobody has cared enough to even contemplate changing it. If you can make the sysroot feature work, that would be great, since that would allow us to skip the compiler building phase if we were building using external compilers. I have some patches to make that work, but this very problem is what I'd worked my way up to. It works well if you are building current on current, but not so well if you are mixing versions (you can mix architectures if you are using the xdev feature I put in a while ago, but even that has one or two niggles I need to iron out). Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Include file search path
I thought I knew something about how the compiler looks for include
files, but now I think maybe I don't know much. :-)
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
I see in the gcc documentation that -I paths are searched before the
standards paths. But isn't the lack of -nostdinc a bug (not just for
libc, but for any library in /usr/src/lib)? It somewhat feels to me
that all of the libraries and binaries in the source distribution
should use -nostdinc and include only from the source distribution
itself. This isn't always an issue, but for source upgrades it seems
crucial, and for a hacker it saves difficulties with having to install
headers before re-building.
Is that the intent, and it's not fully implemented? How badly would
things break if -nostdinc was included in e.g. bsd.lib.mk? (This would
break non-base libraries, yes? But as a thought experiment for the
base, how far off are we?)
Thanks,
matthew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
