#4003 closed bug (fixed)
GCC4 build break when building at -O1
Reported by: | jprostko | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Build System | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
With trying to build Haiku with -O1 (set via BuildSetup) with GCC 4.3.3, the Bluetooth kit fails to compile with the following error:
C++ /boot/home/haiku/trunk/generated-gcc-4.3.3/objects/haiku/x86/release/kits/bluetooth/ConnectionIncoming.o Link /boot/home/haiku/trunk/generated-gcc-4.3.3/objects/haiku/x86/release/kits/bluetooth/libbluetooth.so /boot/home/haiku/trunk/generated-gcc-4.3.3/objects/haiku/x86/release/kits/bluetooth/ConnectionIncoming.o: In function `static_initialization_and_destruction_0(int, int)': ConnectionIncoming.cpp:(.text+0x3c): undefined reference to `std::ios_base::Init::Init()' ConnectionIncoming.cpp:(.text+0x5c): undefined reference to `std::ios_base::Init::~Init()' collect2: ld returned 1 exit status
This is remedied by adding a $(TARGET_LIBSTDC++) to the src/kits/bluetooth/Jamfile.
I initially found this out, as the native Haiku GCC 4.4 I am working with encountered the same problem, but at -O2.
The GCC 4.4 port encounters similar issues at -O1 in two more files.
These are src/bin/locale/Jamfile and src/apps/cdplayer/Jamfile . They both need $(TARGET_LIBSTDC++) added to them as well.
Those could probably be ignored for now, but there's no harm fixing those files now as far as I can tell. Actually, on the haiku-commits' list, there was an issue raised about hrev30573 and there needing to be a $(TARGET_LIBSTDC++) added to the locale Jamfile. I am pretty sure this wasn't a mere coincidence to the break I noted on my 4.4 Haiku build.
By the way, GCC 2.95.3 has none of these issues, as I tested it as well. Also, if it was relevant, the last time I attempted this was at hrev30953 of Haiku.
Attached is one file that addresses all issues. I realize we may not want to touch the locale and cdplayer jamfiles until we actually use 4.4 officially (I'll see about getting that in the tree when 4.4.1 comes out later this month, if everyone's cool with that), so proceed as you see fit. It'd be good to at least get the bluetooth Jamfile fix applied though, as it is relevant to GCC 4.3.3.
By the way, I saw quite a few Jamfiles in the tree that exceed 80 characters across, but I edited these to make sure they are only 80 across. I'm not sure if the coding guidelines apply to the Jamfiles or not, but I assumed they did.
Attachments (1)
Change History (3)
by , 16 years ago
Attachment: | jamfiles.diff added |
---|
comment:1 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Applied in hrev30979. Thanks a lot!
comment:2 by , 16 years ago
Forgot to mention... yes, it's definitely correct to fix Jamfiles for the chars/line limit, too! Thanks!
Diff to fix optimization-related build-breakage