Bug #2442

Possible bmake regression link_elf_obj_obj: symbol atomic_cmpset_int undefined

Added by davshao almost 9 years ago. Updated almost 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Something in master after (not inclusive)
commit 861cfd512d0fe6d53d680a10c0989a580290ef22 kernel/linprocfs: Add dependency on the linux module
and through (inclusive)
commit a3775bf244235f5b1b580b0aab954df19e770863 Update files for OpenSSH-6.1p1 import
has caused a regression such that in dmesg:

Mounting devfs
link_elf_obj_obj: symbol atomic_cmpset_int undefined
linker_load_file: Unsupported file type
KLD radeon.ko: depends on drm - not available or version mismatch
linker_load_file: Unsupported file type

It is therefore suspected that this is caused by something in the make to bmake transition.

The one system tested so far where this regression has been observed is an Asus M5A87 motherboard AMD64 x86_64, chipset AMD 870 / SB850, MSI R4350 Radeon graphics card.



Updated by davshao almost 9 years ago

The problem persists despite full
make -j7 buildworld buildkernel
make buildworld && make buildkernel

Also I believe some warning should be added to UPDATING that once the change to bmake is made, it is not trivial to even build a previous version.


Updated by masterblaster almost 9 years ago

After a full buildworld and kernel on x86_64 acpi.ko refuses to loads (ends in kernel panic) because of same missing symbol.


Updated by ftigeot almost 9 years ago

The new build infrastructure is apparently sensitive to .o/.So/.so/.po/.a files located in /usr/src

Can you check if your /usr/src directory is clean ?


Updated by marino almost 9 years ago

Also, try to grab a log and see if you see any references to stale depends. The presence of such a warning may be an indication of generated files in usr/src


Updated by swildner almost 9 years ago

On Tue, 30 Oct 2012 08:23:04 +0100, Francois Tigeot via Redmine
<> wrote:

Issue #2442 has been updated by Francois Tigeot.

The new build infrastructure is apparently sensitive to
.o/.So/.so/.po/.a files located in /usr/src

I don't think it's related to that.

Our snapshots have the same atomic* problem and their source is freshly
cloned and checked out upon every build.



Updated by marino almost 9 years ago

I got a post-processed version of atomic.c:

It seems that the second atomic.h inclusion is not happening, and that's where all these atomic_* symbols would be getting defined.

Ideas? I've sent an email to the author of bmake to see if he has an idea how bmake could be responsible for gcc actions.


Updated by marino almost 9 years ago

  • Status changed from New to Closed

Despite the crazy symptoms of the atomic.o build, this was ultimately caused by missing the update of a single mk file,

A full buildkernel is required to fix symptoms.

Also available in: Atom PDF