Opened 8 years ago

Closed 8 years ago

#8098 closed bug (fixed)

gcc4 ICU-devel package b0rks install

Reported by: luroh Owned by: zooey
Priority: normal Milestone: R1
Component: Build System Version: R1/Development
Keywords: Cc: zooey
Blocked By: Blocking:
Has a Patch: no Platform: All


hrev43203, gcc4 cross-compiled to disk from Linux

Including the ICU-devel package in UserBuildConfig breaks the Development package, example:

/boot/develop/headers/cpp (broken link)

Another example: /boot/develop/abi/current/lib/ is full of broken links

Change History (7)

comment:1 by luroh, 8 years ago

Component: - GeneralBuild System
Owner: changed from nobody to bonefish

comment:2 by bonefish, 8 years ago

Cc: zooey added

The package contains a develop/abi/current/lib/ directory with libraries. I guess this somehow clashes with the develop/abi/current in the image being a symlink and the mechanism how the build_haiku_image script installs the optional packages (unzip then copy). Did this ever work?

comment:3 by anevilyak, 8 years ago

Not that I know of. This problem would theoretically be solved if the build sys extracted packages in dependency order though, i.e. ICU-devel is marked as depending on DevelopmentBase, and the latter sets up the current link, so if the latter were extracted first, ICU-devel should just drop its files in the right place. My jam-fu's not currently sufficient to figure out how to coax the build system into doing things that way though.

comment:4 by bonefish, 8 years ago

I don't think the order is an issue. The "current" link should be created before the zip files are extracted, since the zip files are extracted after all the "regular" operations (copying files and creating directories and symlinks) are done. I believe the problem has to do with how the contents of a package is transferred to the Haiku installation/image. In case of a directory installation cp -r is used and fails when encountering the current entry (just did a dry test copying the package contents to a directory with a symlink in the way). The bfs_shell cp -r semantics apparently differs. Working on the build system ATM (nothing builds), I can't quickly verify it. In either case one could consider the package the issue (hence my question whether it ever worked). The easiest fix would be providing a gcc 2 and gcc 4 package.

comment:5 by zooey, 8 years ago

Owner: changed from bonefish to zooey
Status: newin-progress

comment:6 by zooey, 8 years ago

To answer the question: no, apparently it never worked.

Fixed in hrev43535.

comment:7 by zooey, 8 years ago

Resolution: fixed
Status: in-progressclosed
Note: See TracTickets for help on using tickets.