Haiku build system using system libstdc++.so on Haiku

[leavengood]

I'm on a pure GCC4 Haiku. I'm not sure if that affects this issue though. The revision is hrev41768.

My Haiku source is completely up-to-date though, at hrev43193.

I compiled and installed the latest GCC4 (4.5.3), where I had previously had 4.4.4. I set 4.5.3 as the current GCC. I reconfigured my Haiku source directory to make sure it was using the latest GCC.

When building the notification_server, I received this error:

Link /Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/notification_server 
/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/NotificationView.o: In function `NotificationView::SetText(float)':
NotificationView.cpp:(.text+0x114a): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
NotificationView.cpp:(.text+0x135d): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
collect2: ld returned 1 exit status

rm -f "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/notification_server"
gcc -fno-strict-aliasing -fno-tree-vrp -Xlinker --no-undefined -Xlinker -soname=_APP_ -nostdlib -Xlinker --no-undefined -o "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/notification_server"  "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/system/glue/arch/x86/crti.o" "/boot/develop/abi/x86/gcc4/tools/gcc-4.5.3-haiku-111101/lib/gcc/i586-pc-haiku/4.5.3/crtbegin.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/system/glue/start_dyn.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/system/glue/init_term_dyn.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/AppGroupView.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/NotificationServer.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/NotificationView.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/NotificationWindow.o" \
"/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/kits/libbe.so" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/debug_1/kits/translation/libtranslation.so" "/boot/system/lib/libstdc++.so" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/libnotification.a" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/kits/locale/liblocale.so" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/kits/locale/liblocalestub.a" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/system/libroot/libroot.so"  "/boot/develop/abi/x86/gcc4/tools/gcc-4.5.3-haiku-111101/lib/gcc/i586-pc-haiku/4.5.3/crtend.o" "/Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/system/glue/arch/x86/crtn.o" \


...failed Link /Data/develop/haiku_svn/trunk/generated-gcc4/objects/haiku/x86/release/servers/notification/notification_server ...

BUILD FAILURE:
...failed updating 1 target(s)...
...updated 4 target(s)...

Searching Google showed me someone else had run into this issue with GCC 4.5 (​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882), and in his case it was due to compiling with GCC 4.5 but linking against a system libstdc++.so. If you look at the link line above, you can see it is using /boot/system/lib/libstdc++.so.

So it seems we have the same problem. When I updated my system libstdc++.so with the one from GCC 4.5.3, the code linked fine.

Now maybe my situation is unusual but it seems like the build system should make use of the libstdc++.so from the GCC it is building with, not from the system. Even if the system is Haiku.

[siarzhuk]

JFYI: #7792 #7824

[bonefish]

Depending where (on Haiku?) and how (with gcc 4?) you built your gcc 4.5.3, this is indeed a duplicate of the tickets siarzhuk mentioned. Please close in that case.

[leavengood]

I followed the method described in the build tools document just like siarzhuk did here: ​http://dev.haiku-os.org/ticket/7792#comment:22

In my case there was a libstdc++.so on the system, it was just the 4.4.4 version.

I don't understand all the problems you had in #7824, when the method described in the build tools document works so well, excluding this aspect of it.

But I will close this as a duplicate.

[bonefish]

Replying to leavengood:

I followed the method described in the build tools document just like siarzhuk did here: ​http://dev.haiku-os.org/ticket/7792#comment:22

In my case there was a libstdc++.so on the system, it was just the 4.4.4 version.

I don't understand all the problems you had in #7824, when the method described in the build tools document works so well, excluding this aspect of it.

The build system strictly separates host and target platform (which is why cross-compiling works at all). A compiler is needed for both platforms. In case of Haiku as the host platform the build system, as a convenience hack, allows to use the host compiler as the target compiler. This works fine (though I wouldn't propose it as a method to build official images) as long as the target doesn't change in a way that also requires compiler changes which aren't compatible with the host system (the multi-byte character related changes Oliver has worked on during the BeGeistert coding sprint might be such an example).

Anyway, in this case the problem was actually that you just didn't install the new native gcc correctly. The STL headers and the installed runtime libsupc++ and libstdc++ need to match. Otherwise code compiled for the host system might not run on it.

[leavengood]

Replying to bonefish:

The build system strictly separates host and target platform (which is why cross-compiling works at all). A compiler is needed for both platforms. In case of Haiku as the host platform the build system, as a convenience hack, allows to use the host compiler as the target compiler. This works fine (though I wouldn't propose it as a method to build official images) as long as the target doesn't change in a way that also requires compiler changes which aren't compatible with the host system (the multi-byte character related changes Oliver has worked on during the BeGeistert coding sprint might be such an example).

Yeah, I get all that. I did cross compiling of Haiku and even WebKit for a long time.

Anyway, in this case the problem was actually that you just didn't install the new native gcc correctly.

I followed the instructions in buildtools/INSTALL-gcc4-from-source-Haiku exactly, if those don't produce a correct installation then they should be adjusted or removed.

The STL headers and the installed runtime libsupc++ and libstdc++ need to match. Otherwise code compiled for the host system might not run on it.

I'm OK with programs I compile with the new GCC not necessarily being able to run on the host system (at least not without putting some libraries in a lib subdirectory for whatever I'm trying to run.) This happens a lot with Haiku anyhow, when the kernel, libroot or libbe (or other system libraries) change a lot. But if I change the compiler things should build at least.

Of course things like a major compiler change should not happen too often. But it should be possible to upgrade that from within an existing Haiku, without needing another system or completely reinstalling Haiku.

But maybe this is something that can wait for now. Maybe package management will help, I don't know.

[bonefish]

Replying to leavengood:

Replying to bonefish:

Anyway, in this case the problem was actually that you just didn't install the new native gcc correctly.

I followed the instructions in buildtools/INSTALL-gcc4-from-source-Haiku exactly, if those don't produce a correct installation then they should be adjusted or removed.

Yep, feel to do so.

The STL headers and the installed runtime libsupc++ and libstdc++ need to match. Otherwise code compiled for the host system might not run on it.

I'm OK with programs I compile with the new GCC not necessarily being able to run on the host system (at least not without putting some libraries in a lib subdirectory for whatever I'm trying to run.) This happens a lot with Haiku anyhow, when the kernel, libroot or libbe (or other system libraries) change a lot. But if I change the compiler things should build at least.

Well, normally the stuff built with the target compiler doesn't need to run on the the host platform. If host and target compiler are the same, they need to, though. So whichever way you look at it, when you built on Haiku with the native compiler, it must work correctly.

Of course things like a major compiler change should not happen too often. But it should be possible to upgrade that from within an existing Haiku, without needing another system or completely reinstalling Haiku.

That's why I filed #7824. It should at least possible to actually cross-built a new Haiku. Whether it will be possible to use the result to update the system in-place is different question.

But maybe this is something that can wait for now. Maybe package management will help, I don't know.

PM will definitely support system upgrades, if that's what you're referring to. We will also improve the whole binutils-gcc-libstdc++ situation, because eventually libstdc++ will be split off into a separate package. It will be possible to update it without updating gcc and vice versa.