How to replace clang with lang/gcc-48 in base?

[Chris_H]

Greetings,

While this is on an 11-CURRENT, I can easily compare my experience(s) with many RELENG_9 installs I currently maintain.

That said, I just performed an 11 install on bare metal. I went through the usual routine of customizing a kernel, and building/installing world/kernel. I always follow this routine, by a make delete-old. I have never experienced any troubles in this regard, and always carefully examine the actions intended to be performed, before committing to those actions. My last experiences with this (including a previous 11) were only the elimination of Clang (3.4.1). Which never resulted in any further issues on those systems. But strangely, on this new install. I continue to experience a great many complaints building ports, with the error:

...
xmmintrin.h' file not found
# include <xmmintrin.h>
...

I've spent the last two full days trying to track this down. I know it is a header included with Clang. But I have since installed lang/gcc-48, which also includes this header file, and asking GCC(48) to provide it's current environment indicates that the path the header is in, is exported/used. But none of the ports that look for it, ask gcc48.

What to do? Or perhaps more specifically; how do I get gcc48 in base? I get the idea cmake(1) may be of help/the solution here. But I wanted to ask here, before (potentially) making things more difficult than they already appear to be.

Thank you for all your time, and consideration.

--Chris

 

[Chris_H]

Well. Knowing that clang is the default toolchain for building world/kernel on 10+ it shouldn't have surprised me that even though make delete-old removed much of clang it shouldn't remove the binary files located in /usr/bin. Which is what was ultimately causing me grief. Simply modifying make.conf(5) to reflect the following:

CC=gcc48
Cxx=c++48
CPP=cpp48

gave me the environment I needed. I should have realized all this immediately. But because FreeBSD has always "done the right thing", all these years. I'm afraid I've gotten a bit spoiled (see; lazy).

All the best.

--Chris

 

[fonz]

Thanks for reporting back. I already saw your message on the freebsd-ports@ mailing list and started wondering (and investigating) what could be wrong. Both GCC and Clang come with that include file and both are supposed to be able to find it without C_INCLUDE_PATH or -I... or whatever.

Do keep in mind, though, that if you put the lines that you posted into /etc/make.conf just like that, they are applied to pretty much everything from kernel and world to ports and userland applications. Perhaps you'll want to use a conditional of some kind, e.g.

.if ${.CURDIR:M/usr/ports*}
CC=gcc48
Cxx=c++48
CPP=cpp48
.endif

or something along those lines, depending on which compiler you wish to use for what. Of course, if you wish to use gcc48 for everything that should be fine too.

 

[Chris_H]

Thanks for reporting back. I already saw your message on the freebsd-ports@ mailing list and started wondering (and investigating) what could be wrong. Both GCC and Clang come with that include file and both are supposed to be able to find it without C_INCLUDE_PATH or -I... or whatever.

Do keep in mind, though, that if you put the lines that you posted into /etc/make.conf just like that, they are applied to pretty much everything from kernel and world to ports and userland applications. Perhaps you'll want to use a conditional of some kind, e.g.

.if ${.CURDIR:M/usr/ports*}
CC=gcc48
Cxx=c++48
CPP=cpp48
.endif

or something along those lines, depending on which compiler you wish to use for what. Of course, if you wish to use gcc48 for everything that should be fine too.

Thanks for the input fonz! Yes. I was concerned about the effects on building ports, kernel, world, ... What's a person to do? Frankly; it's been YEARS since I've had the need to set[]up a C{...} environment -- like nearly 25 years, and then, everything was from the terminal (as in no X, windo(s|wmanager). Shows how long *BSD has been spoiling me.

Anyway. Maybe I should UNsolved the title. I'd be very interested to find out how others are dealing with this kind of situation, these days. To complicate things even more, as I write this lang/gcc5 is building on that same box.

And what happens when I add lang/clang(4||5)? Whew! I'm getting dizzy just thinking about it. But it is a development box. So I can't think of a better environment to test in.

Thank you very much, again, fonz, for taking the time to share some thoughts on this.

--Chris

 

[Chris_H]

An addendum I should have posted in one of my earlier comments:

There are a couple of tricks that have been available since 8.2 (as memory serves) that were designed to help with regard to clang v gcc. It's designed as follows (make.conf(5))

# don't use lang/clang(33|34|35) for building anything
WITHOUT_CLANG=true
# use GNU C (gcc) for building things
FAVORITE_COMPILER=gcc

Using WITHOUT_CLANG=true in src.conf(5) will 1) prevent world/kernel from being built with Clang, and 2) cause (most) of Clang to be removed via make delete-old.

However, in the case of FAVORITE_COMPILER=gcc, I didn't get what one would expect, using it. Because (as I've already mentioned) Clang binary files were left in /usr/bin which precedes /usr/local/bin. Pity. As for the without Clang, and favorite compiler would (should) have been the perfect setup. No matter which version you use.

Well. Just thought I should mention it. For completeness.

--Chris

 

[Beeblebrox]

I have been on 11 for quite some time and I don't recall having run into that problem. I have no Clang restrictions in my /etc/src.conf. Then again, I build all my ports in Poudriere, which might make a difference for you as well, so worth a try.

The compiler to build with is obviously defined in each port's Makefile and you can globally override such settings of course. However, I'll offer my $0.02 here that such an override may not be the most healthy setting for a functioning system. You MAY run into odd errors while running your applications and end up having to do error tracing in the odd hours of the night.

Which port(s) are you seeing this error in?

 

[Chris_H]

I have been on 11 for quite some time and I don't recall having run into that problem. I have no Clang restrictions in my /etc/src.conf. Then again, I build all my ports in Poudriere, which might make a difference for you as well, so worth a try.

The compiler to build with is obviously defined in each port's Makefile and you can globally override such settings of course. However, I'll offer my $0.02 here that such an override may not be the most healthy setting for a functioning system. You MAY run into odd errors while running your applications and end up having to do error tracing in the odd hours of the night.

Which port(s) are you seeing this error in?

Thanks for your reply, Beeblebrox!

In case it's not already evident, I should probably indicate that this is a development box. I maintain current dump(8)s. So anything that should go wrong is easily overcome with restore(8). That said, I've experimented with ports-mgmt/poudriere. But I was unable to find enough documentation to provide the details I needed for my chosen application of it. That may have changed since then. But I've looked at other methods to accomplish my goals -- chroot(8), jail(8), or simply mounting external media (a USB3 connected platter, or SSD). I should also probably mention, that while I impose Clang restrictions. I have no real issue with using it. I develop nearly everything on Mac OS X with Clang/LLVM. I'm fine with it. All I guess I'd say about it, where FreeBSD is concerned, is that it isn't (yet?) as good, as it is on modern versions of OS X. I have every intention of installing all 3 versions from ports/lang. But the issue I do have, is the one I've mentioned already. I too have been developing on 11, for a while. This (the issue I have now) wasn't manifested in my earlier installs of 11. Now it is. My configuration (make.conf(5), src.conf(5)) has remained unchanged for ~6mos about six months. So it's (must be?) something in (fairly?) recent changes in src, and or ports. I have received a few responses from the lists, that indicate CC, C++, COMPILER, {...} are all dictated by the Makefiles/source of the ports. That has always been my understanding, as well. Yet these recent issues when building and ultimately failing the build, indicate, to me anyway, that there is more afoot. A diabolical, fascist plot to insist lang/clang or base/Clang are the only true way forward. So use it, or suffer the consequences? While intending to be tongue-and-cheek there is a fair amount of truth to that statement. The Foundation has made no secret about depreciating the GNU compiler(s). That may be just fine. But today, IMHO, that would be a bit premature. I also might add: porting over applications from elsewhere will be more difficult, as a result. Not everybody is up on, or has the resources to develop within, Clang/LLVM. While I digress a bit with all of this, it all does affect the situation I appear to be dealing with here. So I mentioned it. It wasn't my intention to "soap box" here. Sorry. Which applications/ports, you ask? Thus far, the only category I seem to have difficulty in is x11 -- a trip to x11/xorg-minimal, and make results in failures with a few of the supporting libraries, or applications. x11/nvidia-driver-304 failed, as well. Which is where I'm currently stuck.

Well. I appear to have rambled on a bit. I'd probably do well to end it here.

Thank you again, Beeblebrox, for taking the time to reply.

--Chris

 

[Beeblebrox]

I'm not sure how much help this will be, but the location of my xmmintrin.h is: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.3/include/xmmintrin.h.

Another idea is to look whether gcc -v gives a correct reply. I have had to do a link every time the gcc version is updated for this to work: # ln -s /usr/local/bin/gcc /usr/local/bin/gcc48

 

[Chris_H]

I'm not sure how much help this will be, but the location of my xmmintrin.h is: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.3/include/xmmintrin.h.

Another idea is to look whether gcc -v gives a correct reply. I have had to do a link every time the gcc version is updated for this to work: # ln -s /usr/local/bin/gcc /usr/local/bin/gcc48

Very good call, Beeblebrox.

I should have mentioned in the OP that /usr/bin/CC, cpp, c++,{...} -v all indicate "clang...".

Meaning (as you noted) everything is linked against the (base) install of clang, which was (largely) removed when make delete-old was performed, following the make installworld.

But what to do, when I install GNU C (gcc) versions 46, 47, 48, 49, and 5? This appears to be the situation where naming the version in make.conf(5) becomes the best choice.

Thanks for the reply, Beeblebrox.

--Chris