[My testing for the likes of the below does not yet extend outside powerpc64 

For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc use with, 
say, gcc49 materials as the so-called "host" compiler tools I have not yet 
found a way around using the workaround:

> # ls -l /usr/lib/libstdc++.*
> lrwxr-xr-x  1 root  wheel  17 Feb 23 00:09 /usr/lib/libstdc++.a -> 
> /usr/lib/libc++.a
> lrwxr-xr-x  1 root  wheel  18 Feb 23 00:09 /usr/lib/libstdc++.so -> 
> /usr/lib/libc++.so

But I appear to now have a src.conf (or a family of them) that avoids needing 
workarounds in /usr/local/include and /usr/local/lib for filename conflicts. 
This is based on CC/CXX ("HOST") and XCC/XCXX ("CROSS") in src.conf being the 
likes of:

> CC=env C_INCLUDE_PATH=/usr/include /usr/local/bin/gcc49 -L/usr/lib
> CXX=env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1 
> /usr/local/bin/g++49 -std=c++11 -nostdinc++ -L/usr/lib

and. . .

> TO_TYPE=powerpc64
> . . .
> . . .
> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++

In other words: CROSS use is already handled for /usr/local/. . . just given 
the compiler paths but some special src.conf adjustments beyond compiler paths 
were needed for HOST.

So far it appears that gcc49 materials can be used in "CROSS" and/or 
powerpc64-gcc materials can be used in "HOST" via just appropriate 
compiler-path editing. (I have jumped to testing -r297514 but am still doing 
various build tests. So this aspect is subject to updates.) It appears to be 
possible to use just one compiler/tool family --but in the 2 different ways-- 
instead of using a mix of 2 compiler/tool families.

Historically I've not gotten gcc variants to make a working lib32 for powerpc64 
and I've yet to retest this: So no claims about the lib32 status are implied 
here. (The problem was code in crtbeginS that arbitrarily used R30 in a way 
that the context was not set up for and so crtbeginS code was dereferencing 
arbitrary addresses.)

Mark Millard
markmi at dsl-only.net

On 2016-Apr-1, at 4:35 PM, Mark Millard <markmi at dsl-only.net> wrote:

[Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has for 
the default include search places:]

powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include before 
/usr/include : see below.

> # portmaster --list-origins
> . . .
> devel/powerpc64-xtoolchain-gcc
> . . .
> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version
> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for powerpc64) 
> 5.3.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ - -o 
> /dev/null
> . . .
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/powerpc64-portbld-freebsd11.0"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/backward"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
> /usr/local/include
> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
> /usr/include
> End of search list.
> . . .

Mark Millard
markmi at dsl-only.net

On 2016-Apr-1, at 7:25 AM, Warner Losh <imp at bsdimp.com> wrote:
> On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <d...@freebsd.org> wrote:
> On 01 Apr 2016, at 00:44, Warner Losh <i...@bsdimp.com> wrote:
>>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrew...@freebsd.org> wrote:
>>> I didn't realize the ports compiler was defaulting /usr/local/include
>>> into the search path now.  It does not have /usr/local/lib in the
>>> default library path as far as I can tell.  It's also broken for its
>>> -rpath (noted in its pkg-message).  So having a default
>>> /usr/local/include path seems odd.
>> It has for a while now. It’s one of the maddening inconsistencies that 
>> abound in this
>> area. I took a poll a while ago and there seemed to be widespread support 
>> for adding
>> it to the base compiler.
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds.  You can never know which conflicting
> headers a certain user has installed in /usr/local/include... :)
> That's why it shouldn't be *FIRST*, not why it shouldn't be there
> at all.
>>> Adding -isystem /usr/include to fix this is probably possible but
>>> there's a risk someone will remove it as redundant.  In this case I wish
>>> /usr/include was first but I'm not sure what impact that would have on
>>> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
>>> work, though they would need to pass a -L /usr/local/lib anyhow and
>>> would likely be passing -I /usr/local/lib too.
>> /usr/include should be first. But it isn’t. That’s another inconsistency 
>> that was found
>> when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
>> the path,
>> if I recall correctly.
> Isn't that a bit of a bikeshed?  I guess some people would just as well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
> Sigh. No. /usr/local is moving into many different things in the base and 
> ports. We should
> do it in a consistent way. What we have now is not consistent and somewhat 
> brittle.
> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and specifying
> exactly the include directories we need, and no others.  Cumbersome, but
> maybe for a good cause.
> That's the non-brittle solution here. An over-reliance on defaults makes it
> difficult to ensure other compilers will work, especially ones we don't
> tightly control the defaults for.
> Warner

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to