Bug #2442
closed
Possible bmake regression link_elf_obj_obj: symbol atomic_cmpset_int undefined
0%
Description
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 about 12 years ago
The problem persists despite full
make -j7 buildworld buildkernel
or
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 about 12 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 about 12 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 about 12 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 about 12 years ago
On Tue, 30 Oct 2012 08:23:04 +0100, Francois Tigeot via Redmine
<bugtracker-admin@leaf.dragonflybsd.org> 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.
Sascha
Updated by marino about 12 years ago
I got a post-processed version of atomic.c:
http://leaf.dragonflybsd.org/~marino/atomic.processed.txt
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 about 12 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, kern.fwd.mk
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9c9078b1c22ba5b3b33389aecc1b70d4706c4002
A full buildkernel is required to fix symptoms.