Native gcc2 needs rebuilding since tree changes

[haiqu]

Native gcc2 (i.e. the one that's used on Haiku, not the cross-compiler) needs to rebuilt now that the directory structure has changed. It can't find libraries any more.

[haiqu]

Suggestion: The next version of the native compiler should be a cross-compiler capable of emitting BeOS code from within Haiku. I figure a lot of people will want that capability.

[anevilyak]

That would have to be a separate toolchain for a number of reasons. As to a lot of people wanting that capability, I honestly completely fail to see why.

[umccullough]

I know I would not care for it... And would even discourage it - even being one of the few people who still maintains a couple BeOS boxes here. I just have absolutely no desire to compile BeOS-targetted software on Haiku - I'll just use BeOS for that if I need to.

And anyhow, as Rene points out, the right strategy would be to compile the BeOS gcc2 compiler on a Haiku host, not make the Haiku compiler generate BeOS-compatible code - that would be a step backward in my opinion, and not worth the effort by any stretch.

It was an intentional choice to break the Haiku compiler away from the BeOS compiler because they're simply different OSes.

[haiqu]

Fair enough. I can always maintain a BeOS installation with the current cross-compiler installed. The main reason was to generate builds of various packages I used to maintain (and several I'm working on) for BeOS as well as Haiku. But yeah, easy enough to unplug a HDD from the cradle and install another one.

Re: The original issue - my workaround is currently to create a soft link between /boot/system/lib and /boot/beos/lib and this may even be a long-term solution considering all the other stuff now living under /boot/beos

[umccullough]

Strangely enough, I haven't yet run into issues compiling recently with the native compilers and the new folder structure...

Perhaps only certain situations are having issue?

[haiqu]

Nope. Linking between /boot/system/lib and /boot/beos/system/lib didn't work. The native compiler is looking for libraries in /boot/develop/lib/x86 and all the links to /boot/system/lib have vanished. To build Haiku I had to add links to libbe.so and libroot.so but there may be others, it hasn't finished yet.

You may have remnant links from previous builds, this system was rebuilt only about 24 hours ago.

[axeld]

This is not a GCC issue, but would be a build system issue. Optional packages are not updated when you only update an installation - you would have to do a clean install in order to get the right links into /boot/develop/lib/x86.

[haiqu]

I just did a clean build, and it still isn't right as at hrev30226. What's needed in the scripts is:

link from boot/system/lib/libbe.so -> boot/develop/lib/x86/libbe.so
link from boot/system/lib/libroot.so -> boot/develop/lib/x86/libroot.so
link from boot/system/lib/libstdc++.r4.so -> boot/develop/tools/gnupro/lib/libstdc++.r4.so

Then it's all good and the Haiku sources build with the native compiler, as long as ./configure is done correctly.

[umccullough]

I believe what axel says is true, because I have absolutely no problems linking to any of those three libraries from my cleanly-built GCC2 or GCC4 Haiku partitions

Note: these partitions were created and installed from my linux host, so there was no BFS on them prior - I'm using the "disk" type BuildProfile - perhaps that is why mine works? What build profile type are you using there?

[haiqu]

Yeah, he's right. With the rapid changes in the source tree I must have done a partial build, gone to get some sleep and then done an `svn up' and rebuilt the next morning or something. These late nights are killing me ... heh. I'm too old for this shit. :)

The report was definitely right when it was made, but the problem got fixed in the meanwhile.