You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here are my results from running plutil from a recent official 5.2 snapshot for Ubuntu, which is reproducible with the trunk snapshot too: > ./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil -help ./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil: error while loading shared libraries: libicuucswift.so.65: cannot open shared object file: No such file or directory > readelf -d swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil | ag runpath 0x000000000000001d (RUNPATH) Library runpath: [/home/buildnode/jenkins/workspace/oss-swift-5.2-package-linux-ubuntu-18_04/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux] > LD_LIBRARY_PATH=./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/lib/swift/linux ./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil -help plutil: [command_option] [other_options] file... The file '-' means stdin Command options are (-lint is the default): -help show this message and exit ...
I'm fairly certain that this RPATH pull broke it, as that relative RPATH isn't there in plutil anymore. However, I don't know what magic combination of symbols to use to escape the $ sign in $ORIGIN, as it keeps screwing with the RPATH when I tried reverting, as I noted in a comment on that pull.
The text was updated successfully, but these errors were encountered:
An update: this is still broken but not for the same reason. After CMake was updated to 3.19.6 in Swift PR 37517, the right relative RPATH is now added but plutil now fails because it can't find libicudata: > ./swift-DEVELOPMENT-SNAPSHOT-2021-05-26-a-centos8/usr/bin/plutil -h ./swift-DEVELOPMENT-SNAPSHOT-2021-05-26-a-centos8/usr/bin/plutil: error while loading shared libraries: libicudataswift.so.65: cannot open shared object file: No such file or directory
The relative RPATH is now there so that's not the issue anymore:
The issue now is that the libicui18n and libicuuc libraries that ship with Swift on linux don't have $ORIGIN in their RPATH, as adding it to them with patchelf gets plutil working again. This probably doesn't normally hit with Swift executables on Linux because they have the absolute path to these Swift libraries added to their rpath, which is then applied to libicu to find their dependencies too, but plutil can't know the absolute path where it will be installed so it breaks.
$ORIGIN will need to be added to the RPATH of the shipped libicu to finally fix this.
Environment
Arch Linux x86_64, kernel 5.5.4-arch1-1
Additional Detail from JIRA
md5: d68017bba292055ec763fd88bfafbf07
Issue Description:
Here are my results from running plutil from a recent official 5.2 snapshot for Ubuntu, which is reproducible with the trunk snapshot too:
> ./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil -help
./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil: error while loading shared libraries: libicuucswift.so.65: cannot open shared object file: No such file or directory
> readelf -d swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil | ag runpath
0x000000000000001d (RUNPATH) Library runpath: [/home/buildnode/jenkins/workspace/oss-swift-5.2-package-linux-ubuntu-18_04/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux]
> LD_LIBRARY_PATH=./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/lib/swift/linux ./swift-5.2-DEVELOPMENT-SNAPSHOT-2020-03-19-a-ubuntu18.04/usr/bin/plutil -help
plutil: [command_option] [other_options] file...
The file '-' means stdin
Command options are (-lint is the default):
-help show this message and exit
...
I'm fairly certain that this RPATH pull broke it, as that relative RPATH isn't there in plutil anymore. However, I don't know what magic combination of symbols to use to escape the $ sign in $ORIGIN, as it keeps screwing with the RPATH when I tried reverting, as I noted in a comment on that pull.
The text was updated successfully, but these errors were encountered: