Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
If I install Swift for Linux on different systems in different directories I can’t run the same binary.
The swift linux shared objects path ist hardcoded.
objdump -p Hello
Dynamic Section
NEEDED libswiftCore.so
...
RPATH /opt/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10/usr/lib/swift/linux
...
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions. We also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
That said, we would welcome concrete proposals for how to improve the support for portable or distributable binaries. Those proposals should take into account whatever is happening with regard to system Swift packages.
- Daniel
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de> wrote:
If I install Swift for Linux on different systems in different directories I can’t run the same binary.
The swift linux shared objects path ist hardcoded.
objdump -p Hello
Dynamic Section
NEEDED libswiftCore.so
...
RPATH /opt/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10/usr/lib/swift/linux
...
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
In a previous thread, someone asked about statically linking in libswiftCore. That seems like a reasonable configuration to support on Linux to get easily-deployable independent binaries.
-Joe
On Dec 4, 2015, at 8:49 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de> wrote:
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions. We also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
That said, we would welcome concrete proposals for how to improve the support for portable or distributable binaries. Those proposals should take into account whatever is happening with regard to system Swift packages.
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions. We also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
That said, we would welcome concrete proposals for how to improve the support for portable or distributable binaries. Those proposals should take into account whatever is happening with regard to system Swift packages.
In a previous thread, someone asked about statically linking in libswiftCore. That seems like a reasonable configuration to support on Linux to get easily-deployable independent binaries.
+1
- Daniel
On Dec 5, 2015, at 7:13 AM, Joe Groff <jgroff@apple.com> wrote:
On Dec 4, 2015, at 8:49 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de> wrote:
-Joe
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions.
Will this be a solution to install Swift easy and on an appropriate directory?
$ wget -O - https://swift.org/install-ubuntu14.04.sh | bash
We also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
An other solution would be, to offer `.deb` packages for `libswiftCore.so` ...
So other packages can have `libswiftCore.so` ... as package dependency.
In addition to this the Swift compiler can be offered as `.deb` package, too.
On OS X it is also enough to run the `swift-[...]-osx.pkg` installer.
That said, we would welcome concrete proposals for how to improve the support for portable or distributable binaries. Those proposals should take into account whatever is happening with regard to system Swift packages.
In a previous thread, someone asked about statically linking in libswiftCore. That seems like a reasonable configuration to support on Linux to get easily-deployable independent binaries.
I have read the thread: "building static binaries / reducing library dependencies?" <https://lists.swift.org/pipermail/swift-users/2015-December/000008.html>
I don’t know if static linking can lead to license problems.
For example, if I want to publish something with the GPL License.
P.S. I apologize for my English. I am a German student.
– Ugo
On 05.12.2015, at 16:13, Joe Groff <jgroff@apple.com> wrote:
On Dec 4, 2015, at 8:49 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de> wrote:
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions.
Will this be a solution to install Swift easy and on an appropriate directory?
$ wget -O - https://swift.org/install-ubuntu14.04.sh | bash
There was a pull request to this effect; you might weigh in on the issue there. Some people have security concerns about piping to sh, for better or worse.
We also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
An other solution would be, to offer `.deb` packages for `libswiftCore.so` ...
So other packages can have `libswiftCore.so` ... as package dependency.
In addition to this the Swift compiler can be offered as `.deb` package, too.On OS X it is also enough to run the `swift-[...]-osx.pkg` installer.
That said, we would welcome concrete proposals for how to improve the support for portable or distributable binaries. Those proposals should take into account whatever is happening with regard to system Swift packages.
In a previous thread, someone asked about statically linking in libswiftCore. That seems like a reasonable configuration to support on Linux to get easily-deployable independent binaries.
I have read the thread: "building static binaries / reducing library dependencies?" <https://lists.swift.org/pipermail/swift-users/2015-December/000008.html>
I don’t know if static linking can lead to license problems.
For example, if I want to publish something with the GPL License.
Swift is licensed under Apache with the runtime exception, which should be GPL compatible.
P.S. I apologize for my English. I am a German student.
No worries, your English is fine!
-Joe
On Dec 10, 2015, at 1:43 AM, Ugo Arangino <swift@ua94.de> wrote:
On 05.12.2015, at 16:13, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Dec 4, 2015, at 8:49 PM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de <mailto:swift@ua94.de>> wrote:
Unfortunately, the core team does not have bandwidth for system-specific
packaging, but the community is welcome to provide the packages and
repositories: [SR-91] Provide an APT repository for easier installation · Issue #42713 · apple/swift · GitHub
Dmiti
On Thu, Dec 10, 2015 at 1:43 AM, Ugo Arangino via swift-users < swift-users@swift.org> wrote:
An other solution would be, to offer `.deb` packages for `libswiftCore.so`
...
So other packages can have `libswiftCore.so` ... as package dependency.
In addition to this the Swift compiler can be offered as `.deb` package,
too.
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
Ready-to-install packages would be awesome, though it would require someone to implement and maintain that package, and there's still configuration complexity for users who need to install that package, and potentially maintain different versions as Swift's ABI converges. Static linking would avoid all that. The ease of deployment of static libraries seems to be one of the killer features that leads people to suffer programming in Go.
-Joe
On Dec 10, 2015, at 1:43 AM, Ugo Arangino <swift@ua94.de> wrote:
On 05.12.2015, at 16:13, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Dec 4, 2015, at 8:49 PM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
On Dec 4, 2015, at 6:37 PM, Ugo Arangino <swift@ua94.de <mailto:swift@ua94.de>> wrote:
Why is the Dynamic linker DT_RPATH set, instead of configure it like this `/etc/ld.so.conf.d/swift.conf` or copying the libraries to a appropriate place?
For the initial release, we felt it was more important for things to work locally (and simply) for people downloading our snapshots than to support this and have more complicated installation instructions.
Will this be a solution to install Swift easy and on an appropriate directory?
$ wget -O - https://swift.org/install-ubuntu14.04.sh | bashWe also suspected that people would quickly try things like building Docker images with Swift, and this problem doesn't show up for users who are building their projects that way.
An other solution would be, to offer `.deb` packages for `libswiftCore.so` ...
So other packages can have `libswiftCore.so` ... as package dependency.
In addition to this the Swift compiler can be offered as `.deb` package, too.On OS X it is also enough to run the `swift-[...]-osx.pkg` installer.