broken symbolic link

[andrey86]

Hello,

I've tried to compile simple test.cpp using /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/g++:

int main() {

int * x=new int(); return 0;

}

Compiler reports the following error: ...libstdc++.a: undefined reference to _Unwind_Resume

This error has occurred because of the broken symbolic link /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/lib/libstdc++.so pointed to file /boot/system/lib/libstdc++.so that isn't exist.

I've corrected symbolic link by the command:

ln -fs /boot/system/lib/gcc4/libstdc++.so /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/lib/libstdc++.so

... and test.cpp has been compiled correctly.

So, I suppose it is a bug in the Haiku and the command mentioned above is a bugfix/patch.

[stippi]

I can only guess this is a regression from recent messing with the build scripts. Do you install the ICU-devel optional package?

[andrey86]

Replying to stippi:

I can only guess this is a regression from recent messing with the build scripts. Do you install the ICU-devel optional package?

I haven't installed anything to the system. The bug reproduced on the native system.

[bonefish]

Please always give the revision number of the Haiku installation and how you built/where you got it.

[bonefish]

Forgot to add: The exact command line to reproduce the problem is mighty helpful.

[andrey86]

1. I have got it on the page ​http://www.haiku-os.org/get-haiku by first link ​http://haiku.it.su.se/haiku/releases/r1alpha1/haiku-r1alpha1-iso.zip
2. I have installed it on the VirtualBox-3.1.4
3. Command line:

ls -l readlink /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/lib/libstdc++.so

[andrey86]

ls -l `readlink /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/lib/libstdc++.so`

[bonefish]

I meant the failing compilation command line, but never mind. The symlink is part of the optional package archive, which it shouldn't be, since it must be different for gcc2 hybrid and gcc4 builds. It should rather be created by the OptionalPackages section.

[andrey86]

The failing command line for compilation is very simple:

/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/g++ test.cpp

[axeld]

It seems to be a problem of GCC4 expecting a native GCC4 build, and thus expects libstdc++.so in /system/lib, while it's in /system/lib/gcc4 on a GCC2 based hybrid.

[bonefish]

Replying to axeld:

It seems to be a problem of GCC4 expecting a native GCC4 build, and thus expects libstdc++.so in /system/lib, while it's in /system/lib/gcc4 on a GCC2 based hybrid.

Well, as written in 8 it's not gcc that is expecting the libraries there, only the symlinks in the archive are incorrect. They should be created in OptionalPackages depending on whether the package is installed in a gcc 4 native or gcc 2 hybrid image.

That aside, the main problem here is a user error. It is necessary to do a setgcc gcc4 in a hybrid build, before gcc 4 can be used (then it can just be invoked as g++, without the full path).

I don't have a gcc 2 hybrid build at hand ATM, but on a gcc 4 build a g++ -print-search-dirs results in:

install: /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/
programs: =/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../libexec/gcc/i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../libexec/gcc/:/usr/libexec/gcc/i586-pc-haiku/4.3.3/:/usr/libexec/gcc/i586-pc-haiku/:/usr/lib/gcc/i586-pc-haiku/4.3.3/:/usr/lib/gcc/i586-pc-haiku/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../../i586-pc-haiku/bin/i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../../i586-pc-haiku/bin/:/usr/ccs/bin/i586-pc-haiku/4.3.3/:/usr/ccs/bin/
libraries: =/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/:/boot/develop/abi/current/library-paths/common/i586-pc-haiku/4.3.3/:/boot/develop/abi/current/library-paths/common/:/boot/develop/lib/x86/i586-pc-haiku/4.3.3/:/boot/develop/lib/x86/:/usr/lib/gcc/i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../../i586-pc-haiku/lib/i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../../i586-pc-haiku/lib/:/usr/ccs/lib/i586-pc-haiku/4.3.3/:/usr/ccs/lib/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../i586-pc-haiku/4.3.3/:/boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../:/lib/i586-pc-haiku/4.3.3/:/lib/:/usr/lib/i586-pc-haiku/4.3.3/:/usr/lib/

As we see there's a lot of bogus in the library path, but the problematic paths are /boot/develop/abi/current/library-paths/common/* /boot/develop/lib/x86/*. Those only work only after a setgcc gcc4. They originate from the BELIBRARIES environmental variable. The only option I see ATM is to make BELIBRARIES empty and code the paths into the compiler.

The fact that there's also /boot/develop/abi/x86/gcc4/tools/gcc-4.3.3-haiku-090629/bin/../lib/gcc/i586-pc-haiku/4.3.3/../../../ makes the compilation of the simple test work after fixing the symlink, but the usage is still wrong and building more complex programs (e.g. using libbe.so) would fail.

[mmadia]

needs additional testing

[mmadia]

The above patch should be working. To test, I repackaged my local copy of /generated/x86gcc2/download/gcc-4.3.3-r1a1-x86-gcc4-2009-06-29.zip , removing the broken symlinks in /generated/x86gcc2/download/arst/develop/abi/x86/gcc4/tools/current/lib

However when building a gcc2hybrid, the image fails to build :

Extracting /generated/x86gcc2/download/gcc-2.95.3-r1a1-x86-gcc2-2009-08-26.zip ...
Extracting /generated/x86gcc2/download/gcc-4.3.3-r1a1-x86-gcc4-2009-06-29.zip ...
Error: Failed to remove `/myfs/./develop/abi/x86/gcc4/tools/current'
Error: Command failed: Is a directory
Error: Command was:
  cp -f -r :/generated/x86gcc2/tmp/extract//. /myfs/.

export imagePath="/generated/x86gcc2/haiku-nightly.image"
export isImage="1"
export isVMwareImage=""
/haiku-src/haiku/build/scripts/build_haiku_image /generated/x86gcc2/haiku.image-init-vars /generated/x86gcc2/haiku.image-make-dirs /generated/x86gcc2/haiku.image-copy-files /generated/x86gcc2/haiku.image-extract-files

...failed BuildHaikuImage1 /generated/x86gcc2/haiku-nightly.image ...

[bonefish]

The "current" in the patch is not correct. It should be the name of the actual tool directory, since otherwise the "current" is created as a directory, which is exactly the reason for the above error.

Also, without having checked closer, the AddSymlinkToHaikuHybridImage invocations don't look correct. The whole point of this rule is to insert the "gcc2"/"gcc4" in the path as needed in order to save the caller to add separate cases for gcc2 and gcc4.

Finally, when repackaging the archive please rename it, so it will be automatically re-downloaded by the build system.

[zooey]

Fixed in hrev35746 - one invocation of AddSymlinkToHaikuHybridImage per lib is enough (the 'true' as 4th param asks to insert 'gcc4' as sub-path for the alternative container image).

Works with gcc4 and gcc2-hybrid, haven't checked with gcc4-hybrid, though.

I suppose this has to be applied to all optional packages that provide libraries, ...