Opened 9 years ago

Closed 9 years ago

#5744 closed bug (fixed)

install-haiku target copies libstdc++.so and libsupc++.so as symlinks

Reported by: andreasf Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/Development
Keywords: Cc: PulkoMandy
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

When building on Haiku, at hrev36100 and still with us at hrev36336, the HaikuImage Jamfile places $(HAIKU_SHARED_LIBSTDC++) and $(HAIKU_SHARED_LIBSUPC++) into system/lib/ and copies the symlinks instead of the target files, so that system/lib/libstdc++.so points to /boot/system/lib/libstdc++.so.

This leads to the resulting volume stalling at boot during the rocket icon with the following messages in serial debug output:

runtime_loader: Cannot open file libstdc++.so: No such file or directory
runtime_loader: Cannot open file libsupc++.so: No such file or directory

Attachments (1)

libstdc++-readlink.patch (872 bytes ) - added by andreasf 9 years ago.
workaround

Download all attachments as: .zip

Change History (4)

by andreasf, 9 years ago

Attachment: libstdc++-readlink.patch added

workaround

comment:1 by andreasf, 9 years ago

The attached patch works around this by post-processing the obtained $(HAIKU_SHARED_LIBxxxC++) values with readlink. The libraries are then copied correctly.

The original values are read from gcc -print-file-name=libstdc++.so.

comment:2 by korli, 9 years ago

What's your build platform version ?

comment:3 by bonefish, 9 years ago

Resolution: fixed
Status: newclosed

Added a similar solution in hrev36355. The actual problem is that copyattr (which is used for copying for "install" profiles) does not resolve symlinks by default and doesn't even have a switch to do that. I guess the work-around is OK for the time being.

Note: See TracTickets for help on using tickets.