error when compiling Haiku with gcc 4.5.3

[diger]

hrev42345 gcc4

I cant build last revision on gcc4.5.3 with error:

.......
.......
Link generated/objects/haiku_host/x86/release/tools/bfs_shell/bfs_shell 
generated/objects/haiku_host/x86/release/tools/fs_shell/fs_shell.a(fs_shell_kernel.o): In function `FSShell::add_file_restriction(char const*, long long, long long)':
(.text+0x9786): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
collect2: ld returned 1 exit status
......
......
generated/objects/haiku_host/x86/release/tools/rc/librdef.a(compile.o): In function `alloc_mem(unsigned long)':
compile.cpp:(.text+0x307): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
generated/objects/haiku_host/x86/release/tools/rc/librdef.a(compile.o): In function `std::list<void*, std::allocator<void*> >::remove(void* const&)':
compile.cpp:(.text._ZNSt4listIPvSaIS0_EE6removeERKS0_[std::list<void*, std::allocator<void*> >::remove(void* const&)]+0x47): undefined reference to `std::_List_node_base::_M_unhook()'
.........
.........

[korli]

Is it the full build log? There definitely should be the command involved in linking bfs_shell. What is the command used to build?

Also, is hrev42345 gcc4 a self built image or one downloaded from haiku-files.org?

[diger]

Replying to korli:

Is it the full build log? There definitely should be the command involved in linking bfs_shell. What is the command used to build?

Also, is hrev42345 gcc4 a self built image or one downloaded from haiku-files.org?

Yes, i am using hrev42345 gcc4 a self built image

Similar errors occur when building the program Qbittorent or EiscaltDC++:

qbtsession.o: In function `QBtSession::generateFilePriorityResumeData(boost::intrusive_ptr<libtorrent::torrent_info>&, std::vector<int, std::allocator<int> > const&)':
qbtsession.cpp:(.text+0xe53a): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
qbtsession.cpp:(.text+0xe6a4): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
.....
.....

On gcc 4.4.4 all build fine.

C-compile the following test case:

#include <list>

int main(int, char**)
{
std::list<int> l;
l.psuh_back(1);
l.push_back(2);
l.push_back(3);

std::list<int>::iterator i = l.begin();
for (; i != l.end(); i++){
  std:cout << *i << std::endl();
}

return 0;
}

[anevilyak]

I looked into this, and oddly enough both the cross compiled libstdc++ from my FreeBSD build as well as the one from Haiku's 4.5.3 optional package have that symbol defined here. I'm wondering what's different.

Edit: I'm silly and didn't realize the one in the dev tools package was just a symlink to the system one. In any case, that still begs the question of why they differ.

[zooey]

Diger: since you build your own Haiku image, libstdc++.so is built from the cross-compiler's libstdc++.a. So in order to be compatible to binaries created by the gcc-4.5.3 optional package that is used to build stuff on Haiku, the cross-compiler used by the host must match it (i.e. must be gcc-4.5.3).

The problem you're describing may indicate that your local 'buildtools' repository checkout is not up-to-date. Please try updating that, then configure (which should build a new cross-compiler) and rebuild haiku.

[siarzhuk]

Replying to zooey:

The problem you're describing may indicate that your local 'buildtools' repository checkout is not up-to-date. Please try updating that, then configure (which should build a new cross-compiler) and rebuild haiku.

It is not cross-compilation - the host system is Haiku. May be just replace libstdc++ in system libs with one from 4.5.3 tools?

[korli]

Replying to siarzhuk:

It is not cross-compilation - the host system is Haiku. May be just replace libstdc++ in system libs with one from 4.5.3 tools?

I tested with an up to date build tools and haiku trunk. The resulting gcc4 image can correctly link the provided sample. Dunno what might happen on Diger's environment.

[siarzhuk]

Replying to korli:

Replying to siarzhuk:

It is not cross-compilation - the host system is Haiku. May be just replace libstdc++ in system libs with one from 4.5.3 tools?

I tested with an up to date build tools and haiku trunk. The resulting gcc4 image can correctly link the provided sample. Dunno what might happen on Diger's environment.

We are using usually following schema:

There are 3 partitions: /Haiku1 /Haiku2 /Source

Haiku1 is used as base system to build, develop and test. The trunk lives on Sources partition. Haiku2 is a temporary target to check the building of the trunk version and used sometime as base system to update the Haiku1. So we updating Haiku1 from the Haiku2 and vice versa.

It works perfectly until the host system modules are compatible with the gcc tools.

Currently there is only one copy of the /boot/system/lib/libstdc++.so on the systems (modification date 24 Sep 2010). The /boot/develop/abi/x86/gcc4/tools/gcc-4.5.3-haiku-110620/lib/libstdc++.so is the symlink to /boot/system/lib/libstdc++.

[siarzhuk]

siarzhuk:

We are using usually following schema:

There are 3 partitions: /Haiku1 /Haiku2

By the way both of them are gcc4/2 hybrid systems.

[korli]

gcc-4.5.3-haiku-110620 is meant to be used with r1a3 or newer. How do you come with a Sep 2010 libstdc++.so ?

[siarzhuk]

Replying to korli:

gcc-4.5.3-haiku-110620 is meant to be used with r1a3 or newer. How do you come with a Sep 2010 libstdc++.so ?

Both /Haiku1 and /Haiku2 are trunk version - they are updated such way for years. And they have received the gcc-4.5.3, naturally with the svn update. ;-)

[korli]

Replying to siarzhuk:

Both /Haiku1 and /Haiku2 are trunk version - they are updated such way for years. And they have received the gcc-4.5.3, naturally with the svn update. ;-)

Sure. That doesn't explain the Sep 2010 libstdc++.so though.

[zooey]

Replying to siarzhuk:

Replying to zooey:

The problem you're describing may indicate that your local 'buildtools' repository checkout is not up-to-date. Please try updating that, then configure (which should build a new cross-compiler) and rebuild haiku.

It is not cross-compilation - the host system is Haiku. May be just replace libstdc++ in system libs with one from 4.5.3 tools?

You can't, since the gcc-4.5.3 optional package doesn't contain libstd++.so. That is a bug, since the respective headers are included in that package and the mismatch between headers and shared library causes the problem in the first place.

Never mind cross-compilation, an even worse problem exists with a Haiku host: when building Haiku on Haiku, libstdc++.so is apparently never being built at all, the one found on the host system is instead copied to the target. That's why the library is never being updated.

[bonefish]

Replying to zooey:

Replying to siarzhuk:

It is not cross-compilation - the host system is Haiku. May be just replace libstdc++ in system libs with one from 4.5.3 tools?

You can't, since the gcc-4.5.3 optional package doesn't contain libstd++.so. That is a bug, since the respective headers are included in that package and the mismatch between headers and shared library causes the problem in the first place.

I wouldn't say that this is a bug. The gcc-4.5.3 optional package only works on a Haiku system built with that compiler. Installing it on a mismatching Haiku is a user error.

Whether the status quo is desirable is another question. We include the C++ runtime and STL in the base system, since it is needed by many base system components. We might want to pull it out of both the base system and the compiler package.

Never mind cross-compilation, an even worse problem exists with a Haiku host: when building Haiku on Haiku, libstdc++.so is apparently never being built at all, the one found on the host system is instead copied to the target. That's why the library is never being updated.

It's actually the compiler's libstdc++, which, when using the compiler from the optional package, symlinks to the one in the system (which, given that compiler and system should match, is correct). When cross-compiling (from Haiku) -- which one has to do when desiring to build Haiku with a different compiler -- the cross-compiled library will be used.

Closing as invalid (user error).

[siarzhuk]

Replying to bonefish:

I wouldn't say that this is a bug. The gcc-4.5.3 optional package only works on a Haiku system built with that compiler. Installing it on a mismatching Haiku is a user error.

User has not installed the new compiler - he has only updated the source tree. The compiler was changed silently and that change costs a bit of time to understand the problem and write this long [and futile!] discussion in the Trac. May be some gcc version check should be introduced in build scripts to prevent entering this "gray area" again in the future?

[bonefish]

Replying to siarzhuk:

Replying to bonefish:

I wouldn't say that this is a bug. The gcc-4.5.3 optional package only works on a Haiku system built with that compiler. Installing it on a mismatching Haiku is a user error.

User has not installed the new compiler - he has only updated the source tree. The compiler was changed silently

Updating the source tree does certainly not change the installed compiler. Nor does anything you can do with the build system, save for actually installing a new Haiku over your old one.

and that change costs a bit of time to understand the problem and write this long [and futile!] discussion in the Trac. May be some gcc version check should be introduced in build scripts to prevent entering this "gray area" again in the future?

We do have a version check for gcc 2. It was intentionally omitted for the experimental gcc 4 to avoid annoying developers unnecessarily. We could maybe make that a warning. Anyway, it wouldn't have helped in this case though, since installing a compiler not matching the OS (however that was done) simply results in a broken compiler. That doesn't really have anything to do Haiku's build system.

[siarzhuk]

Replying to bonefish:

Replying to siarzhuk:

Replying to bonefish:

I wouldn't say that this is a bug. The gcc-4.5.3 optional package only works on a Haiku system built with that compiler. Installing it on a mismatching Haiku is a user error.

User has not installed the new compiler - he has only updated the source tree. The compiler was changed silently

Updating the source tree does certainly not change the installed compiler. Nor does anything you can do with the build system, save for actually installing a new Haiku over your old one.

It doesn't look like self-hosting system then.

By the way, today morning the Haiku that was built on Haiku host couldn't load the app_server because the /boot/system/lib/libstdc++.so is just a symlink:

/boot/system/lib/libstdc++.so -> /system/lib/libstdc++.so

So the system has no real binary of libstdc++.so at all.

[bonefish]

Replying to siarzhuk:

Replying to bonefish:

Updating the source tree does certainly not change the installed compiler. Nor does anything you can do with the build system, save for actually installing a new Haiku over your old one.

It doesn't look like self-hosting system then.

Huh?

By the way, today morning the Haiku that was built on Haiku host couldn't load the app_server because the /boot/system/lib/libstdc++.so is just a symlink:

/boot/system/lib/libstdc++.so -> /system/lib/libstdc++.so

So the system has no real binary of libstdc++.so at all.

You'll have to provide a few more information for anyone to be able to analyze this problem:

• The version of host system (revision, compilers/hybrid (exact compiler versions)).
• The state of host /system/lib/libstdc++.so and what it refers to.
• The revision of the Haiku sources.
• The generated/build/BuildConfig file.
• The method of building (target/build profile type).

[siarzhuk]

Replying to bonefish:

Replying to siarzhuk:

Replying to bonefish:

Updating the source tree does certainly not change the installed compiler. Nor does anything you can do with the build system, save for actually installing a new Haiku over your old one.

It doesn't look like self-hosting system then.

Huh?

As described above Haiku has [potential] problems reproducing itself with upcoming versions of gcc. And, if I understand correctly, I have to bother with cross-compiling to update the system - in other words I cannot update the system without involving 3rd party toolchains.

You'll have to provide a few more information for anyone to be able to analyze this problem:

• The version of host system (revision, compilers/hybrid (exact compiler versions)).
• The state of host /system/lib/libstdc++.so and what it refers to.
• The revision of the Haiku sources.
• The generated/build/BuildConfig file.
• The method of building (target/build profile type).

1) We use two Haiku hybrid 4/2 builds (Haiku1 and Haiku2) updating each other (first Haiku1 updates Haiku2 than Haiku2 updates Haiku1). They are updated by compiling "install-haiku" target with corresponding HAIKU_INSTALL_DIR environment variable set;
2) Because this sources tree is used for years and libstdc++.so and libsupc++.so are not updated during building on Haiku hosts it is impossible to say now where they come from - either from cross-build on FreeBSD or from some nightly build. The date was 24 Sep 2010 as I have already said. That is the only info about them;
3) The revision of Haiku sources is irrelevant to this problem - once it trapped in this catch - neither updating nor complete removing of generated folder with reconfiguring it can help. About a some years ago I have already the same problem with "symlinks to itself" with libstdc++.so and libsupc++.so. Probably it was related to gcc version upgrade too. Unfortunately I don't remember how I have workarounded it previous time - may be it was clean install of the host system from the image;
4) Trying to workaround the problem described in this ticket I have compiled the libstdc++.so with cross compiling on FreeBSD and replace with it corresponding file on the host system. This helps to solve the problem but building "install-haiku" target produces the system without libstdc++.so and libsupc++.so binaries - they are symlinked to itself on the target system. Note that building "haiku-image" target on the same sources puts the whole binaries into image;
5) Corresponding BuildConfig will be attached soon.

[siarzhuk]

To #comment:19 BuildConfig prodicing "libstdc++.so symlinked to itself" on "install-haiku" target.

[bonefish]

Replying to siarzhuk:

As described above Haiku has [potential] problems reproducing itself with upcoming versions of gcc. And, if I understand correctly, I have to bother with cross-compiling to update the system - in other words I cannot update the system without involving 3rd party toolchains.

There's a misconception on your side. When you build an operating system from the scratch -- which is what Haiku's build system does -- you always cross-compile (for the new version of the OS). As long as the compiler version matches, for building on Haiku that means you can use the installed compiler as a cross-compiler. That is a convenience shortcut the build system supports. It mostly also works for minor compiler changes, though that is not encouraged. Similarly under Linux/FreeBSD one has to rebuild the cross-compiler when the compiler version changes.

Anyway, when the compiler version changes, you'll have to use a compiler built from the sources (just as on Linux/FreeBSD). That has nothing to do with Haiku not being self-hosting. It's just the way how Haiku needs to be built -- with the correct cross-compiler.

1) We use two Haiku hybrid 4/2 builds (Haiku1 and Haiku2) updating each other (first Haiku1 updates Haiku2 than Haiku2 updates Haiku1). They are updated by compiling "install-haiku" target with corresponding HAIKU_INSTALL_DIR environment variable set;

Please note that the install-haiku target (or install build profile action) was not designed to update a system. While that might work most of the time, it was intended only for installation in a clean directory. So, to be on the safe side, you should wipe the target directory first.

2) Because this sources tree is used for years and libstdc++.so and libsupc++.so are not updated during building on Haiku hosts it is impossible to say now where they come from - either from cross-build on FreeBSD or from some nightly build. The date was 24 Sep 2010 as I have already said. That is the only info about them;

Well, there isn't much surprise there. If you always use the installed gcc 4 for cross-compilation, it is always the installed libraries that will copied to the new system.

4) Trying to workaround the problem described in this ticket I have compiled the libstdc++.so with cross compiling on FreeBSD and replace with it corresponding file on the host system. This helps to solve the problem but building "install-haiku" target produces the system without libstdc++.so and libsupc++.so binaries - they are symlinked to itself on the target system. Note that building "haiku-image" target on the same sources puts the whole binaries into image;

The image build and install build use commands with slightly differing semantics. The former uses the FS shell command cp -f (resolving symlinks) while the latter uses copyattr -d (not resolving symlinks). That probably should be made more consistent. The main issue is, however, that configure has not resolved libstdc++ to the actual file (the reason probably being the botched state of the installed gcc):

HAIKU_SHARED_LIBSTDC++      ?= /boot/develop/abi/x86/gcc4/lib/libstdc++.so ;

Hence the symlink is copied to <install dir>/system/lib/.

To sum this up, AFAICT the problems resulted from Haiku not being built correctly. Haiku has to be built with the correct compiler, i.e. if necessary a cross-compiler has to be built from the sources, just as on systems other than Haiku. If the wrong compiler is used, the resulting Haiku will possibly be broken. That is probably something that should be clarified in the ReadMe.

[siarzhuk]

Replying to bonefish:

To sum this up, AFAICT the problems resulted from Haiku not being built correctly. Haiku has to be built with the correct compiler, i.e. if necessary a cross-compiler has to be built from the sources, just as on systems other than Haiku. If the wrong compiler is used, the resulting Haiku will possibly be broken. That is probably something that should be clarified in the ReadMe.

Yes, the ReadMe "Updating" clause will prevent users from such mistakes. Thank you for the detailed explanation and patience. ;-)

[siarzhuk]

I have checked out current buildtools tree and use the "INSTALL-gcc4-from-source-Haiku" document as guide to build cross (???) compiler. Note that the version of libstdc++.so produced in this build was about 4 Mbytes of size and there were only static versions of libsupc++ in the corresponding lib folder under /boot/develop... No shared version of libsupc++.so at all.

After this I have tried to reconfigure the hybrid build from scratch (with wiped out "generated" folders, of course) and started compiling "install-haiku" target. The build have failed on unresolved links to libstdc++. Note that build/BuildConfig is refering to /boot/system/lib/ versions of libstdc++.so and libsupc++.so - so that fail is not surprise.

Building of non-hybrid gcc4 configuration has also failed. Corresponding BuildConfig is attached.

So the question is: How can I build the correct version of gcc 4.5.3 cross-compiler on Haiku host (with gcc 4.4.4)? Using the guide from "ReadMe.cross-compiling" document doesn't help - "configure" finishes with message about "non cross configuration" and creates no Jamfile.

[siarzhuk]

to #comment:22

[bonefish]

Replying to siarzhuk:

So the question is: How can I build the correct version of gcc 4.5.3 cross-compiler on Haiku host (with gcc 4.4.4)? Using the guide from "ReadMe.cross-compiling" document doesn't help - "configure" finishes with message about "non cross configuration" and creates no Jamfile.

Mmh, that's the method that should be used. I wonder where the message comes from. I'll try and have a look. I'm a bit handicapped with respect to Haiku partitions I can use ATM, so I'll have to try with a gcc 2 package management Haiku. Will see what happens...

[bonefish]

I failed with my package management Haiku, since some packages need to be rebuilt to work correctly. I built a fresh regular gcc 4.4.4 Haiku and ran into the issue you mentioned, which I would consider a bug in gcc's build system. I tried to work around it, but encountered another issue. I created ticket #7824 to track it. It's assigned to me, but I don't think I'll work on it anytime soon. I marked it a blocker, since it essentially means, that ATM it is not possible to correctly build Haiku on Haiku. I haven't even tried cross-compiling gcc 2. It might have the same problems.