Ticket #618 (closed defect: wontfix)
Opened 3 years ago
Last modified 23 months ago
icu-4.8.1 destroys haiku
| Reported by: | cipri | Owned by: | scottmc |
|---|---|---|---|
| Priority: | highest | Milestone: | haikuporter version 2.0 |
| Component: | dev-libs/icu | Version: | |
| Severity: | critical | Keywords: | icu |
| Cc: |
Description
i tried to install icu 4.8.1 because it's needed by boost. I was running the command haikuporter -i icu-4.8.1 and after a lot periode of working it started to fail, the binary "rm" failed, and others... a lot of failings, and crashes, till it then stopped unsuccessfully.
I think I even saw that it tried to delete some system librabries.
In any case, after a reboot, the system didnt start, even not in safe mode. I thought that it's just a bad conincidance, that it didnt boot anymore. So I was reinstalling the latest nightly, and doing the whole thing again. With exactly the same behaviour. It seems installing icu-4.8.1 really damages haiku.
Perhaps somebody tries to solve it, or to contact the one who ported icu to haiku?.
Attachments
Change History
comment:1 Changed 3 years ago by scottmc
comment:2 Changed 3 years ago by cipri
yes, but it stills needs a fix, it's not possible that it can really harm your system that much. Any user who doesnt know about that problem, can loose his data. I had a lot of stuff compiled and installed when it first happened, and i lost them, and so i have to spend many hours again, to have my system in the same state again.
comment:3 Changed 3 years ago by zooey
I tried to reproduce the problem, but failed - ICU-4.8.1 just builds and installs fine for me.
Could you provide some more info please, like which gcc version you have used and what exactly happens when things start to go wrong (anything interesting in syslog for instance?).
I find it hard to imagine why haikuporter would start to delete system libraries when ICU is being installed to /boot/common ...
comment:4 Changed 3 years ago by cipri
i use gcc4 on one of the latest gcc2hybrid nightly.
It starts when the script (bep file) pop-ups a little window, and informing that "/.../rm" failed, or something like that, or that it crashed, or that it could not delete. Aftert that other windows like that appear too. One has a text that looks like a "regexpression" would have failed.
After that I have tried to compile one of my own programs, and it didnt work, complaining that stdc++.so is missing.
building with -c -d , and the unzipping works without problems. But direct installation with -i option, seems not to work for me.
It seems that everything starts when rm is not able to delete a certain file.
in the next days (after i finish my work) i will try again and provide then more information , with screenshots if somebody else desnt confirm it till then.
comment:5 Changed 3 years ago by oco
I have the rm problem too while building icu 4.8.1 using gcc4 on hrev44066 or hrev44528 (gcc2hybrid nightly).
rm crash with a segmentation violation with this call stack :
0x00104b0f in topological_sort () from /boot/system/runtime_loader (gdb) bt #0 0x00104b0f in topological_sort () from /boot/system/runtime_loader #1 0x00104b18 in topological_sort () from /boot/system/runtime_loader #2 0x001058c4 in get_sorted_image_list () from /boot/system/runtime_loader #3 0x00101aa0 in terminate_program () from /boot/system/runtime_loader #4 0x0029933c in exit () from /boot/system/lib/libroot.so #5 0x00203501 in main ()
The problem show up when the build system add the studata directory in LIBRARY_PATH (at the beginning). You should be able to reproduce using :
/boot/common/develop/haikuports/dev-libs/icu/work/icu/source/lib> export LIBRARY_PATH=../stubdata:../tools/ctestfw:../lib:$LIBRARY_PATH /boot/common/develop/haikuports/dev-libs/icu/work/icu/source/lib> rm -f libicudata.so.48 && ln -s libicudata.so.48.1 libicudata.so.48
rm load libicudata.so.48 from the stubdata directory instead of the system one (see trace file attached) because it is the first one in the LIBRARY_PATH and despite the fact that the two binaries are compiled with different gcc (gcc2 for rm and gcc4 for libicudata.48.1).
Could it be the reason for the crash ?
Changed 3 years ago by oco
comment:6 Changed 3 years ago by oco
On the same machine, recompiling icu-4.8.1 using gcc2 works.
haikuporter -c icu-4.8.1
comment:7 Changed 2 years ago by scottmc
- Milestone changed from haikuporter version 1.0 to haikuporter version 2.0
comment:8 Changed 23 months ago by scottmc
- Resolution set to wontfix
- Status changed from new to closed
This may or may not be fixed using the new haikuporter on haikuPM:
http://bb.haikuports.org/haikuports/src/6e94889851506e766b07d62b3e96b5a795b8f7ae/dev-libs/icu/icu-4.8.1.1.recipe?at=package-management
If it still fails when trying to build with gcc4 on HaikuPM then please open a new issue on the new haikuports.org site. Closing this one out as it probably won't be fixed for the old haikuporter.

perhaps just build using -c -d and then when it's done building, unzip the resulting zip to /boot.