GCC vs. CLANG

rtwingfield

rtwingfield

I have two server platforms both running on FreeBSD 10.2-RELEASE-p7.
One platform is an old Compaq Proliant ML370 . . .yes, long in the tooth.

The other is a fresh install on Dell Power Edge 2950; CPUs: 8 x Intel(R) Xeon(R) CPU X5355 @ 2.66GHz; available memory is ~5.9GB. Also a fresh clean terabyte hard drive.

Regardless, I cannot successfully compile via portmaster, most complex applications. For example, attempts to build Apache24, with it's dependencies of course, fail, as in kernel panic, crashing the OS. Boom . . .down goes the system . . .no logged errors, rather than yet to be determined what could perhaps be gleaned from the procedures described in the https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html . I have to tell you . . .I get a headache just thinking of pursuing this route. Additionally, on the Proliant system, one such crash of several attempts of which the last damaged the kernel and I had to restore the kernel from the backup version.

I've thought surely the fresh install on the PE2950 would accommodate the systems, but apparently not.

I have read much discussion regarding the reportedly "buggy" CLANG compiler. Is portmaster always defaulting to using the CLANG compiller? I have read that instructions such as # cd /usr/ports/www/firefox/ && make USE_GCC=any install clean will override CLANG, but this seems not to invoke portmaster in the scheme. So, I assume that a directive included in /etc/make.conf could provide a global instruction that portmaster could/would recognize? Would that code simply consist of
Code: 
USE_GCC=any

Another disturbing scenario: consider the following list:

Code: 
/var/db/ports # ls -ls
total 56
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:42 archivers_zip
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:42 audio_alsa-lib
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:41 databases_db5
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:41 devel_apr1
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:41 devel_gettext-tools
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:41 devel_gmake
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:42 devel_libffi
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:43 devel_m4
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:42 java_openjdk8
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:43 lang_perl5.20
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:42 lang_python27
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:43 misc_help2man
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:22 ports-mgmt_portmaster
4 drwxr-xr-x  2 root  wheel  512 Feb  2 19:40 www_apache24

Notice that the only successfully installed port was ports-mgmt_portmaster itself at 19:22 hours. What I cannot understand is why portmaster "registered" the other ports as installed when in fact . . .they are not. No Perl, no Python, no Apache24, et al. Apparently, portmaster forges ahead with the assumption that . . ."OK, I'm told that I'm going to make application X, so I'll just go ahead and included it in my /var/db/ports list . . .but if in the process of making the ap, it crashes, then so what . . .I don't care; I'll just leave the erroneous entrie(s) there." Perhaps portmaster never got to an install step, but perhaps progressed to some point where a dependency make crashed the system and left the "successfully made" dependencies in limbo? I haven't tried any make installs on the listed applications . . .yet.

Does it look like to this audience, that the GCC needs to be used rather than the CLANG compiler?

I'm reluctant to try this again because if it crashes the OS again and this time damages the kernel, then in consideration that I'm working remotely via ssh, I'll probably have to drive out to the HQ and repair and restart the system. :mad:
 
clang(1) is the default compiler on FreeBSD, yes. It's the default compiler for ports as well unless the port specifies otherwise and out of the 25,000+ available ports, there isn't all that many that require gcc(1) or another compiler.

I really don't know what is going on here, but if this is a default install, it sounds suspiciously like it could possibly be bad hardware to me. I don't see how a kernel panic would happen on a RELEASE branch during a port compilation unless it was stressing hardware on the brink of failing. Sorry I can't offer any thing better.
 
rtwingfield said:
The other is a fresh install on Dell Power Edge 2950; CPUs: 8 x Intel(R) Xeon(R) CPU X5355 @ 2.66GHz; available memory is ~5.9GB. Also a fresh clean terabyte hard drive.
Click to expand...
That is ancient hardware and can't handle ZFS. It is very likely dying. You should not have any problem running UFS if it is not already dead. LLVM (Clang is just a front end). LLVM is a system compiler you can build ports with GCC if that is what you fancy or even better you should use binary packages and not built anything yourself.
 
Oko said:
That is ancient hardware and can't handle ZFS. It is very likely dying. You should not have any problem running UFS if it is not already dead. LLVM (Clang is just a front end). LLVM is a system compiler you can build ports with GCC if that is what you fancy or even better you should use binary packages and not built anything yourself.
Click to expand...
What an idiotic thing to say. Suppose that I'm a systems programmer analyst (over 35 years experience) and I write complex systems. What am I going to do? . . .download a package before I compile it?

And also, the PE2950 is just recently superseded with the Dell http://www.dell.com/us/business/p/poweredge-r730/pd family, et al. There is nothing unserviceable regarding the PE2950. FYI, here is a URL to a product sheet: https://www.dell.com/downloads/global/products/pedge/en/2950_specs.pdf

Also you seem enamored with the ZFS? See this: https://en.wikipedia.org/wiki/ZFS . The ZFS name is registered as a trademark of Oracle Corporation, and it's associated baggage. I don't use ZFS and don't plan to. ZFS is not the end-all to file systems. A Unix file system is perfectly suited for what we need. But BTW, a ZFS would be quite happy installed on a PE2950.


protocelt said:
I really don't know what is going on here, but if this is a default install, it sounds suspiciously like it could possibly be bad hardware to me. I don't see how a kernel panic would happen on a RELEASE branch during a port compilation unless it was stressing hardware on the brink of failing.
Click to expand...

Yes, the install was based on a fresh ISO download. Never-the-less, I can tell you that the same type of crashes occur on the old v10.2 FreeBSD Compaq ML370 and the later as on the newer Dell PE2950, and then only when compiling. As I mentioned before, I am suspect of the Clang compiler. I can tell you that I only experience the crashes when using the Clang compiler. I think it's "coloring outside the register lines".

So back to my original question, how do I instruct portmaster to use the GCC compiler? BTW, I ported and compiled it this afternoon. Also, sounds to me like the move from the GCC to CLANG was a legal licensing hurdle, rather than "lets pick something newer and better."


. . .and I'll also add that I didn't have these problems with FreeBSD v9+ and v10.1.

*** A Late Edit ***

Probably by now, you've see this post: https://forums.freebsd.org/threads/how-do-you-recompile-with-fpic.55008/ This type of compiler complaint is typical of problems that I've encountered. I suspect that ap. code written with some other compiler in mind, perhaps the GCC, does not "make nice" with Clang.
 
rtwingfield said:
Notice that the only successfully installed port was ports-mgmt_portmaster itself at 19:22 hours. What I cannot understand is why portmaster "registered" the other ports as installed when in fact . . .they are not. No Perl, no Python, no Apache24, et al. Apparently, portmaster forges ahead with the assumption that . . ."OK, I'm told that I'm going to make application X, so I'll just go ahead and included it in my /var/db/ports list . .
Click to expand...
You're misunderstanding the function of /var/db/ports/. That directory is used to store the selected build options, it does NOT store the registration of the installation. What's installed is registered in /var/db/pkg/local.sqlite by pkg-install(8) (more specifically, by pkg-register(8)). And no, it does not matter if you use ports. A port simply builds a package which is then installed. So there's no intrinsic difference between a package and a port once they're installed.

Does it look like to this audience, that the GCC needs to be used rather than the CLANG compiler?
Click to expand...
No, I wouldn't do that. Ports (and world for that matter) are guaranteed to work with the (automatically) selected compiler. Changing this can and will cause additional problems.

Also, sounds to me like the move from the GCC to CLANG was a legal licensing hurdle, rather than "lets pick something newer and better."
Click to expand...
It's a bit of both actually.
 
In your shoes I would take a look at the temperature readings in the box (when compiling), take a good load of compressed air to the dustbunnies in there and maybe check the power lines for spikes which will mess things up when the power supply is under higher load.

But bashing clang for a kernel panic when it is run? No. The same thing will happen when you use gcc or any other compiler you fancy. You may also want to check if some "creative person" has messed with the memory timings in the BIOS "for that extra bit of performance".
 
GCC and Clang may have slightly different runtime footprints with the same code compiled. It is possible that Clang puts a little bit more strain on the system and if there's anything wrong with the hardware such as faulty capacitor or fluctuating voltage cause by faulty power supply or overheating it could trigger a fault where GCC wouldn't do the same. As suggested, start looking at the hardware first.
 
If this helps for reference ... I am using clang with poudriere to keep roughly 2500 ports over 5 different sets of options (ie server ports have conservative options, workstation ports are highly tweaked/cpu optimized etc), updated nightly. 10.1-RELEASE-p25. I compile my own world+kernel with clang on an 8 core Xeon@3.4GHz, 16GB RAM (supermicro of some sort), 2 poudriere's spawn using 8 cores each. Never have problems with that setup. I recently cross-compiled about 700 ports for an i386 which took several hours. I just checked my logs and have a successful apache24 compiled.

So I'd say don't focus on the compiler at least. I'd try backing out to 10.1 myself, but then I'm conservative and like to run one release behind all the time. Having said that you may also have an option set in some dependent port that is trying to build a port in a way that's simply incompatible with FreeBSD. I know I've (in the distant past) set all kinds of options for a tree of ports and it would break. If possible try removing all the options and see if your build problems go away. That may help narrow down the problem.

Kernel panic though, yeah I'd try 10.1 first just to see .... I've had dodgy RAM that caused buildworld to panic but memtest never identified it, only pulling chips did. Good luck.
 
Lee, with thanks to you and Crivens, and kpa, actually the Dell PE2950 platform build was not experiencing kernel panics when compiling, although once did loose a ssh session . . .only the old Compaq Prolient ML370 crashed. BTW, both machines are well ventilated and in cool-room racks. As I've posted, https://forums.freebsd.org/threads/how-do-you-recompile-with-fpic.55008/#post-310865, I've had some success.

Regarding the ML370, we've actually got two of these (and a ML360 . . .?). Probably going to retire all once a second PE2950 is freshened up with new SATA drives, etc. (Also got three + PE2650's but these older platforms only have SCSI backplanes that cannot accept SATAu drives.) Don't laugh . . .The Civil Air Patrol is a volunteer service organization, and while actually an official auxiliary of the United States Air Force, we are on a tight budget and depend on a lot of hand-me-down stuff.

Time permitting, I may venture into this world, https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html . . .just for chuckles and grins :D

So . . .onward through the fog.
 
rtwingfield said:
these older platforms only have SCSI backplanes that cannot accept SATAu drives.) Don't laugh
Click to expand...
Oh I'm not laughing, I know that pain. I have a PE1850 that is the same way. Last time I ordered new drives for it, they were manufactured in 2009! I use it as a very basic router now, that is somewhat easily replaceable.
I recently ordered the "Design and Implementation of the FreeBSD OS" book, so may be able to help with that kernel debug in a couple of years ;). DTrace may also be of interest, I've just started reading about it.
 
You must log in or register to reply here.
Back
Top