Rel. 11.3: Kernel doesn't compile anymore :(

[PMc]

Trying to compile my custom kernel in Rel. 11.3 results in this:

--- kernel.full ---
linking kernel.full
atomic.o: In function `atomic_add_64':
/usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of `atomic_add_64'
opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here
*** [kernel.full] Error code 1

Same config worked with 11.2

The offending feature is either
options ZFS
or
device dtrace
(Adding any of these to the GENERIC config gives the same error.)

This happens only when building for i386. Building amd64 with these options works.

 

[PMc]

This again boils down to a wonderful story:

Some things in the system, just as in ZFS, seem to need an "atomic_add_64" (which i386 does not do natively).
Therefore, the imported ZFS code contains some assembler routines to implement this function for i386 and some other platforms.
Furthermore, the ZFS compatibility code contains also some routines to implement atomic_add_64 for some platforms that cannot do it natively - but NOT for i386, because that one is already contained in the imported ZFS code.
Now with Rel 11.3 another atomic_add_64 for i386 has been added to the general kernel code (NOT related to ZFS), and removed from the ZFS compatibiity code (where it wasn't used before, either).

The result is that you cannot link the kernel and ZFS into one object, anymore. The problem seems now to figure out who might be responsible and willing to unravel the stuff.

 

[debguy]

#1 this is install question thread so i hope sir dice doesn't penalize me for answering.

If you have a fresh correct install and it does that I'd say a foreigner hacked the kernel intently to waste your time.

If not, then I'd say you have multiple ATOMIC operation headers (the wrong one is likely from linux and got installed with some linux app, it causes issues in linux too). atomic libs are very simple they just provide a counter.

You don't need it defined twice but it was defined twice. The problem (assuming your using "C" and not some bastard replacement) is not that it read the header file twice because "C" knows not to do that and never does (except on broken compilers). that's not your problem. I'd tell you which but there are like 100 tommy atomic libs and i don't know which kernel uses. but i know with 100 out there: one may have leaked into your base system or kernel headers that isn't supposed to be there.

-> You might have a problem that when you compile kernel it is seeing headers from UBUNTU (where most ux viruses come from)

-> You might have had a problem some "contributed gnu" (many are ubuntu hacked not old gnu) that when they installed they over-wrote system headers used in compiling kernel. Your problem will be that you may just as well get the whole "base system" source and clean everything ... assuming your not "too deep in" to do that. In this case: next time follow handbook and (do not compile gnu/ubuntu software as root, ever).

 

[debguy]

Basically (I hope) FreeBSD is designed only to see headers that are for (the kernel and perhaps the base system). When you build kernel no headers from ports/packages should be seen. You either have a header injected from ports in your system headers (as I said - a virus), or you have a hacked system header that added ports include/ to the "visible headers" list, or you have installed a ports library into base (which means it's your fault - don't do that). The header you have *somewhere* is a virus - it uses the same symbol, causes a freak problem, difficult to remove. Thing is no reasonable maintainer would have allowed a C program to install a header or library that uses kernel symbols: they wouldn't even want it anywhere in the distribution - especially if this "program" installed the header in (ie, /usr/include where other programs compiling would see it). But - that's exactly what happens when you build (Linux) software - you have nasties all over the place to "take care of" (nasties that try to over-write headers, inject headers with same symbols, and worse: inject a versional dependancy on a version of a header in a manner where meeting the depends is impossible). FreeBSD no - it should never happen. So you "have a problem", and it can be fixed easily (unless you are in deep in some project of custom kernel using linux headers - in that case my advice is you never needed that atomic lib to compile any app, apps use the system atomic, so un-install that lib. If your deep in such a knot and do need the lib still delete it, and alter code asking for the Linux lib by giving it one only visible in ports (by changing include paths for that build), or lastly, edit code for those apps force them to use FreeBSD's atomic).

Again all atomic are kind the same - just a counter. This is all about symbol naming and dependency - a waste of time that's been injected for you to deal with - perhaps by you intently - perhaps by a hacker who's trying to waste your time.

 

[debguy]

again: this is a "linux lockout" type issue that blows your time (excuse me i mean Linux OS lib - not linux kernel lib - linux kernel is, i think, clean and un-adulterated). it should never happen on freebsd: freebsd is designed much better.

 

[shkhln]

i hope sir dice doesn't penalize me for answering … when you compile kernel it is seeing headers from UBUNTU (where most ux viruses come from)

 

[debguy]

I forgot: if you compiled a "port / package" as root - it would over-write your system header. Don't compile anything that's not part of freebsd base system logged in as the root user and also don't yeild any "sudo" to such software. (except base system - but follow handbook as to which user to compile as there)

and really (perhaps impossible these days): it's better to compile and install software in a user account and only run it as that user unless that software actually is used by the base system / the OS. software should NOT rely on a "library" that it doesn't have ever (like ubuntu does) software should ship with all libs it needs and use it's own. Unfortunately most people think all software needs to be installed "into the system" and games should get the root password and google should be in the driver's seat providing the system which they profit from and everyone else "buys and contributes to". se la vie good news is your wasting time with unix but your wasting it well by using freebsd! You next find out to run a Steam game it wants 8GB of libs installed as root and to run xxx app it wants 8G of libs installed as root and what is going on? the "shared libs" can't really be shared so you end up with software needing a whole OS instead of just a (few) lib - that's what's going on. why is the apps have so many depends they don't work without the OS they were developed in they are all knotted in depends. the "opposite effect" occurs the saved space? turns into much abused space. but google is selling chinese phones and is in the seat in the end, that is what people shouldn't ignore is going on.

 

[debguy]

i'm quite aware there are now people from UBUNTU in the head of freebsd but that ubuntu still does not compile from source but that ubuntu is a friend of microsoft

you can give me the eyes if you like

the truth is it was called "the linux wars" and noted by many web sites, and freebsd at one time began uptaking the war in from the "contributor" section - and then by allowing ubuntu people into the staff of freebsd

do you hear me?

do you have my answers?

 

[debguy]

to be clear i DID say that original poster (OP) may have caused the issue. but the other warnings are valid - i can't and shouldn't assume OP caused the problem.

i don't know why opensolaris is in the fray - it could be OP has selected a kernel option he was told was not for his system it could be legitimate - but opensolaris label on a directory does NOT mean freebsd is a system with such a problem: freebsd base system is clean i know that i've built it. on the other hand. it could be OP was tricked into such a kernel option some time in the (far) past and now he has no idea where the short is (a virus who's source has complete deniability).

 

[SirDice]

#1 this is install question thread so i hope sir dice doesn't penalize me for answering.

No, but I am going to complain about the lack of proper capitalization on pretty much every post you make.

 

[debguy]

I hope I don't get capital punishment, then.

 

[debguy]

Another compile note: by design a C compiler, if you link to libc, doesn't complain if "int x" in your program is used and "int x" is used somewhere in libc. That's called visibility and it's handled during linking: object file symbols are not automatically "global" (except in linux where printf can become "printf with remote login allowed" by a backdoor replacement allowed by gcc). To get a already-defined problem in headers you have to include a system header and another "un-necessary" header both defining the same symbol. It's all about headers. You haven't seen a linker issue yet (you may, if you allow "stuffs" to creep into your kernel builds from "unknown sources").

 

[PMc]

#1 this is install question thread so i hope sir dice doesn't penalize me for answering.

If you have a fresh correct install and it does that I'd say a foreigner hacked the kernel intently to waste your time.

If not, then I'd say you have multiple ATOMIC operation headers (the wrong one is likely from linux

Might have had a difficult time to survive, as I dumped linux in 1995.

and got installed with some linux app, it causes issues in linux too). atomic libs are very simple they just provide a counter.

You don't need it defined twice but it was defined twice. The problem (assuming your using "C" and not some bastard replacement)

I suposse I'm using "some bastard repacement": it is called "assembler". (As might be noticed from post #1 mentioning a file with suffix *.S)

 

[PMc]

FreeBSD no - it should never happen. So you "have a problem", and it can be fixed easily (unless you are in deep in some project of custom kernel using linux headers - in that case my advice

I strongly suggest, before spreading Your advice, You go and download the vanilla FreeBSD 11.3 sources, compile the kernel with ZFS for i386, experience the very same fault as in #1, and then fix the issue to our common benefit. Good luck.

 

[PMc]

do you hear me?

do you have my answers?

Yeah I got it. Kutulu wgah'nagi fhtagn.

 

[ralphbsz]

To quote Master Yoda: The fail is strong in this thread. And I'm not talking about PMc. Quite a few statements about C and linking and compilers made above are non-sensical.

 

[sidetone]

I have a similar error for FreeBSD 12.0.

linking kernel.full
ld.lld: error: unknown -z value: common-page-size=4096
*** Error code 1

My world builds, but my kernel doesn't.

This happened after my computer kept shutting down (again), and messed up a few file systems, and even some configuration settings, that I had to go back and fix. It may have been high humidity, and I turned off overclocking that was on the default setting, so this problem stopped. Maybe it has to do with corrupt files, but I did a fresh install of /usr/src, and reinstalled the compiler from packages. I removed dtrace as done above. No matter what I remove, I get this same error, but after a different point of compiling.

I don't have the complier and linker in my base system, I use those from ports. A few weeks ago, my base system and kernel successfully compiled with these settings. I think it's the update in the linker, but if so, my problem is different, because in the base system, ld doesn't change.

I don't know what linking kernel.full is supposed to mean.

I wonder if it's a problem limited to the kernel configuration, and not the linker itself. It could be that from a custom buildworld, that the kernel built the first time with the libraries before they were removed, then was no longer able to build, as well.

opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here

If you removed CDDL from src.conf(5), it will remove zfs and ctf options for the build. ctf(5) is required for some necessary compact C code to compile, but usually in the ports tree. You also mentioned ZFS above. If you did remove it, you can try fiddling around in /usr/src/, then searching for ctf and zfs in the Makefiles, then build and install them from those directories. But the problem you explained has been 2 months ago, so maybe this is no longer an issue.

* Update - So, I compared my src.conf file to my custom build file, and so far I found one problem, and hopefully, that's the only one left.

 

[PMc]

I have a similar error for FreeBSD 12.0.

linking kernel.full
ld.lld: error: unknown -z value: common-page-size=4096
*** Error code 1

My world builds, but my kernel doesn't.

This happened after my computer kept shutting down (again), and messed up a few file systems, and even some configuration settings, that I had to go back and fix. It may have been high humidity, and I turned off overclocking that was on the default setting, so this problem stopped. Maybe it has to do with corrupt files, but I did a fresh install of /usr/src, and reinstalled the compiler from packages. I removed dtrace as done above. No matter what I remove, I get this same error, but after a different point of compiling.

I don't have the complier and linker in my base system, I use those from ports. A few weeks ago, my base system and kernel successfully compiled with these settings. I think it's the update in the linker, but if so, my problem is different, because in the base system, ld doesn't change.

I don't know what linking kernel.full is supposed to mean.

I suppose it is supposed to mean the linking step.

According to my ld(), common-page-size is an allowed -z value. So it appears that Your invoked linker is not compatible for kernel build.
Try to roll back Your local modifications on the build chain until this problem resolves.

Update: I just recognized, my ld manpage shows the gnu linker (which was installed as a prereq via some ports). That one knows the common-page-size feature. The LLVM linker does not know it!

If you removed CDDL from src.conf(5), it will remove zfs and ctf options for the build. ctf(5) is required for some necessary compact C code to compile, but usually in the ports tree. You also mentioned ZFS above. If you did remove it, you can try fiddling around in /usr/src/, then searching for ctf and zfs in the Makefiles, then build and install them from those directories. But the problem you explained has been 2 months ago, so maybe this is no longer an issue.

As stated above, the issue led to searching for somebody responsible - and probably ended at that point.
But it seems not related to Your issue.

 

[sidetone]

I left out in the update above, when I removed a setting from CUSTOM that was in src.conf, to match them, the error slightly changed to

kernel.full
ld.lld: error: unknown -z value: common-page-size=4096

, without "linking" before the "kernel.full".

I suppose it is supposed to mean the linking step.

According to my ld(), common-page-size is an allowed -z value. So it appears that Your invoked linker is not compatible for kernel build.
Try to roll back Your local modifications on the build chain until this problem resolves.

Update: I just recognized, my ld manpage shows the gnu linker (which was installed as a prereq via some ports). That one knows the common-page-size feature. The LLVM linker does not know it!



As stated above, the issue led to searching for somebody responsible - and probably ended at that point.
But it seems not related to Your issue.

I had already installed binutils from ports before seeing your message, and used that. I softlinked it to that manually, and it set it in make.conf. It worked.

So from what you said, it looks like a new bug, and not just my OS.

But if your ZFS in the kernel failed to compile, it could be because CDDL (as hinted in your error message) was set to be left out in src.conf. I just noticed that you already implied that you narrowed it down to ZFS and dtrace from your CUSTOM kernel file, and it worked. That part (the CDDL warning in your error message) looks related to your past issue (ZFS).

This happens only when building for i386. Building amd64 with these options works.

Mine is for amd64, so the z-linker problem specifically looks like the differences between different architectures, relating to as why some according to documentation some builds don't work consistently across platforms.

 

[PMc]

I had already installed binutils from ports before seeing your message, and used that. I softlinked it to that manually, and it set it in make.conf. It worked.

Well, I'm still using 11.3, and I won't unravel what You modified in the toolchain - but it is certainly related to differences in the various linkers.

But if your ZFS in the kernel failed to compile, it could be because CDDL was set to be left out in src.conf. My guess is that you already removed ZFS from your CUSTOM kernel file, and it worked. That part looks related to your past issue.

Nope. That one only concerns i386, and I did fully unravel it. It is related to 64bit instructions which are not present in i386, and which were emulated in ZFS, then again in porting ZFS, and then again in some other place of the kernel code, and that didn't really fit to each other. I'm now running with a local patch.

 

[debguy]

Are you still not able to upgrade? Dang.

Anyway I talked allot but I meant to steer you away from "add-ons / ports" (ie from ubuntu) that might interfere with your build - meaning to revert to the base and "more clean software".

I mean to say you have something on your system that got (from ports? from enabling unusual kernel "feature") in that shouldn't be in there.

You are a "well known member". I assume you know that 11.3 "make World" `works as released__' (meaning, without modifications). That it may be wise to, instead of upgrading, to install 11.3 fresh as a "1st time install" then restore any files from your home directory from backup.

Your problem now is if you did use a local patch that patch may cause failures when you up to 11.4 (you may have patched ZFS which would be the wrong software to patch - the "problemed software" may probably still be lurking waiting to be triggered again ?)

 

[debguy]

i have an 32bit 1.5GHz laptop i gave up on upgrading (happily!) when i install freebsd next it will be on a more modern pc box: but bad video drivers ... i might have to stick an old pci card in the modern machine ? but that is ok i already have done that. i have less and less time for 'nix: win10 free dev kit is free, apple free dev kit too - both highly developed, and a todo list longer than i'd ever finish besides all that! (as you can tell - i don't get paid for it, so)