Bug 10710 – shared phobos library doesn't work on all linux distributions

The problem is that the currently distributed libphobos2.so is linked against a GnuTLS version of libcurl (libcurl-gnutls.so.4) but Fedora only ships with an OpenSSL version of that library. ---- ldd -r /usr/lib64/libphobos2.so ---- ldd: warning: you do not have execution permission for `/usr/lib64/libphobos2.so' linux-vdso.so.1 => (0x00007fffbcd30000) libcurl-gnutls.so.4 => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6cfdf75000) libm.so.6 => /lib64/libm.so.6 (0x00007f6cfdc74000) librt.so.1 => /lib64/librt.so.1 (0x00007f6cfda6c000) libc.so.6 => /lib64/libc.so.6 (0x00007f6cfd6b3000) /lib64/ld-linux-x86-64.so.2 (0x0000003dc8c00000) undefined symbol: _Dmain (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_setopt, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_slist_append, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_slist_free_all, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_global_cleanup, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_strerror, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_init, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_cleanup, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_duphandle, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_perform, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_easy_pause, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) undefined symbol: curl_global_init, version CURL_GNUTLS_3 (/usr/lib64/libphobos2.so) ----

Yes, this is the issue Jordi Sayol has been talking about. We couldn't find an acceptable solution (Jordi suggested making a custom build of libcurl on Ubuntu, while that works, I regard that as impractical for 3rd parties wanting to fork/build phobos from the repository).

Why do we want to link to the GnuTLS version? Can't we link with the system default or something like that? I find this page describing some differences between the SSL libraries supported by libcurl. http://curl.haxx.se/docs/ssl-compared.html

It assumed that GnuTLS is default version on Debian but this page suggest it's not. http://packages.debian.org/search?keywords=libcurl3 So we need to find out why we're linking against the wrong library.

Problem does not exist on Arch Linux as it does not use .zip and uses git tag instead.

libcurl4-dev is a virtual package provided by libcurl4-openssl-dev libcurl4-nss-dev libcurl4-gnutls-dev So this issue can be solved by installing replacing libcurl4-gnutls-dev with libcurl4-openssl-dev on the build machine.

This is a known issue. On Debian, Ubuntu, etc., all curl libraries has "versioned symbols", which are not properly handled by others Linux systems like Fedora, OpenSUSE, etc., where their curl libraries do not have any versioned symbol. libphobos linked on Debian includes libcurl versioned symbols which will not work on Fedora, but libphobos linked on Fedora will work on Debian. So there are two possible solutions: - Link libphobos on a system like Fedora (libcurl without versioned symbols). - Install a non versioned symbols curl libraries on Debian, and resulting phobos library will work on almost every Linux system. I just offered Walter a personalized deb package which installs Fedora's curl libraries (non versioned symbols) on Ubuntu (until now Linux building process was done on Ubuntu). These libraries will only be used to link libphobos, and resulting libraries will works on almost all Linux systems. This deb package will NEVER be publicly offered because is NOT needed by any user. Someone knows another way to fix this? Removing the lubcurl dependency on libphobos in not an option, at least by the moment.

(In reply to comment #4) > Problem does not exist on Arch Linux as it does not use .zip and uses git tag > instead. This is correct because Arch packages links its own libphobos on Arch, and don't use the libphobos from release zip archive. In other words, libphobos compiled/linked in an Specific Linux system will always work on this specific Linux system.

(In reply to comment #5) > libcurl4-dev is a virtual package provided by > libcurl4-openssl-dev > libcurl4-nss-dev > libcurl4-gnutls-dev > > So this issue can be solved by installing replacing libcurl4-gnutls-dev with > libcurl4-openssl-dev on the build machine. This is not correct. All curl libraries on Debian like systems has versioned symbols, source of this problem.

(In reply to comment #7) This is correct because Arch packages links its own libphobos on Arch, and > don't use the libphobos from release zip archive. > > In other words, libphobos compiled/linked in an Specific Linux system will > always work on this specific Linux system. That is exactly what I have meant. Why do we insist on using the same .zip archive built on Debian-like system everywhere? Native packaging does avoid this problem and scales much better.

(In reply to comment #9) > (In reply to comment #7) > This is correct because Arch packages links its own libphobos on Arch, and > > don't use the libphobos from release zip archive. > > > > In other words, libphobos compiled/linked in an Specific Linux system will > > always work on this specific Linux system. > > That is exactly what I have meant. Why do we insist on using the same .zip > archive built on Debian-like system everywhere? Native packaging does avoid > this problem and scales much better. We have used the same zip until now with great results. I prefer to have one single libphobos library that properly runs on almost all Linux systems than many different ones compiled phobos libraries, dmd command, etc., but if this is not possible we have to change the way we have done until now. I don't think that this is the case however.

(In reply to comment #8) > This is not correct. All curl libraries on Debian like systems has versioned > symbols, source of this problem. I didn't saw any versioned symbols but maybe nm doesn't show them or I made a mistake. > We have used the same zip until now with great results. I prefer to have one > single libphobos library that properly runs on almost all Linux systems than > many different ones compiled phobos libraries, dmd command, etc., but if this > is not possible we have to change the way we have done until now. I don't think > that this is the case however. So what do you suggest then, building libcurl from source?

Also, is there any usage info for .zip archive on Linux platforms? In other words, is it actually worth any considerable efforts?

(In reply to comment #11) > (In reply to comment #8) > > This is not correct. All curl libraries on Debian like systems has versioned > > symbols, source of this problem. > > I didn't saw any versioned symbols but maybe nm doesn't show them or I made a > mistake. The command: $ objdump -x libphobos2.so.0.64.0 | grep curl_easy returns different symbols depending on which development curl library is installed when linked: with "libcurl4-openssl-dev": 0000000000000000 F *UND* 0000000000000000 curl_easy_cleanup@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_strerror@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_setopt@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_duphandle@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_init@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_pause@@CURL_OPENSSL_3 0000000000000000 F *UND* 0000000000000000 curl_easy_perform@@CURL_OPENSSL_3 With "libcurl4-gnutls-dev": 0000000000000000 F *UND* 0000000000000000 curl_easy_setopt@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_strerror@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_init@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_cleanup@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_duphandle@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_perform@@CURL_GNUTLS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_pause@@CURL_GNUTLS_3 With "libcurl4-nss-dev": 0000000000000000 F *UND* 0000000000000000 curl_easy_perform@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_duphandle@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_pause@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_setopt@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_cleanup@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_strerror@@CURL_NSS_3 0000000000000000 F *UND* 0000000000000000 curl_easy_init@@CURL_NSS_3 And with Fedora curl development library: 0000000000000000 F *UND* 0000000000000000 curl_easy_setopt 0000000000000000 F *UND* 0000000000000000 curl_easy_init 0000000000000000 F *UND* 0000000000000000 curl_easy_pause 0000000000000000 F *UND* 0000000000000000 curl_easy_duphandle 0000000000000000 F *UND* 0000000000000000 curl_easy_perform 0000000000000000 F *UND* 0000000000000000 curl_easy_cleanup 0000000000000000 F *UND* 0000000000000000 curl_easy_strerror > > > We have used the same zip until now with great results. I prefer to have one > > single libphobos library that properly runs on almost all Linux systems than > > many different ones compiled phobos libraries, dmd command, etc., but if this > > is not possible we have to change the way we have done until now. I don't think > > that this is the case however. > > So what do you suggest then, building libcurl from source? As I said, I suggest two solutions: - Compile/link libphobos on system where libcurl has not versioned symbols, like Fedora. - Compile/link into Ubuntu with a libcurl without versioned symbols, this requires an specific package not available on default repositories. This option do not mean in any way that these libraries should be given with libphobos, this curl library is just used to properly link libphobos, even do not care if the functions in it has some bug because these libraries will never be used at run-time.

(In reply to comment #1) > Yes, this is the issue Jordi Sayol has been talking about. We couldn't find an > acceptable solution (Jordi suggested making a custom build of libcurl on > Ubuntu, while that works, I regard that as impractical for 3rd parties wanting > to fork/build phobos from the repository). I think we can achieve two things on Linux: - make that binaries/libraries generated on an specific Linux system correctly run on that specific Linux system. - binaries/libraries included on release zip archive should properly run on almost every Linux system. I think that we cannot pretend that every binary/library generated by every user run on every Linux system, as a binary copy of the ones included on zip archive.

(In reply to comment #14) > - binaries/libraries included on release zip archive should properly run on > almost every Linux system. > I think that's the better approach for now because it still allows to build all packages on one system so we don't have to change the whole release process. > I think that we cannot pretend that every binary/library generated by every > user run on every Linux system, as a binary copy of the ones included on zip > archive. That's the reason for this bug report, right?

(In reply to comment #15) > (In reply to comment #14) > > - binaries/libraries included on release zip archive should properly run on > > almost every Linux system. > > > > I think that's the better approach for now because it still allows to build all > packages on one system so we don't have to change the whole release process. Me too, the problem is that the current building platform is Ubuntu, where all its curl libraries has versioned symbols, source of this problem. > > > I think that we cannot pretend that every binary/library generated by every > > user run on every Linux system, as a binary copy of the ones included on zip > > archive. > > That's the reason for this bug report, right? I don't think so. The problem here is that the shared library included on release zip file is "only" usable on Debian-like systems, and fails on Fedora, OpenSUSE, etc.

One possibility is by loading dynamically whichever curl is available on the OS.

(In reply to comment #17) > One possibility is by loading dynamically whichever curl is available on the > OS. True, but it seems wrong to solve a distribution problem with such a workaround.

I marked this as blocker, we need to fix this for the upcoming 2.064 beta. > One possibility is by loading dynamically whichever curl is available on the OS. Dynamic loading had the benefit to only require libcurl if it was actually used but most linux distributions already ship with libcurl so it might not be worth it.

I think the solution to this is dead simple. Stop cross compiling packages for other distributions and build them from source instead. That would require updated installer scripts / makefiles and some machines to build on. We should update the wiki to contain detailed information on how to set up the Ubuntu/Debian/Fedora/Suse box or maybe we can simply host virtualbox images somewhere.

There is another solution. Place libcurl dependencies from phobos to deimos, This is probably the most correct.

(In reply to comment #21) > There is another solution. Place libcurl dependencies from phobos to deimos, > This is probably the most correct. How? Removing std.net.curl is not an option.

(In reply to comment #22) > (In reply to comment #21) > > There is another solution. Place libcurl dependencies from phobos to deimos, > > This is probably the most correct. > > How? Removing std.net.curl is not an option. why not?

(In reply to comment #23) > > How? Removing std.net.curl is not an option. > > why not? Not in the near term. I don't know what the general sentiment about this is, but anyways we couldn't remove a module without deprecation.

(In reply to comment #24) > (In reply to comment #23) > > > How? Removing std.net.curl is not an option. > > > > why not? > > Not in the near term. I don't know what the general sentiment about this is, > but anyways we couldn't remove a module without deprecation. I'm agree with you. Is there a way to know the general sentiment about this?

(In reply to comment #1) > Yes, this is the issue Jordi Sayol has been talking about. We couldn't find an > acceptable solution (Jordi suggested making a custom build of libcurl on > Ubuntu, while that works, I regard that as impractical for 3rd parties wanting > to fork/build phobos from the repository). Walter, the solution is very simple - build the Fedora RPM on Fedora. Simple as that. We can ask Alex to give us access to his Fedora box (I think it is a virtual machine) and build the RPM there. The best option, and I personally like this one the most, is to submit DMD to Fedora, and make it in the official Fedora repository. I can volunteer to do this, although it will take some time because I do not have any Fedora RPMs submitted so Fedora people may be skeptical about my RPM skills at first... Another option is to change the SPEC file and make it explicitly depend on the gnutls RPM (there is gnutls RPM in Fedora!). This will indirectly force user to install curl that is linked against gnutls. curl RPM package from Fedora repository can be re-built with gnutls as default TLS library.

(In reply to comment #26) > The best option, and I personally like this one the most, is to submit DMD to > Fedora, and make it in the official Fedora repository. I have suggested some time ago to completely remove from the archive binaries for distros that have DMD in core repositories. AFAIR it was rejected as not user-friendly (ironically). It was some time ago though, can't remember the details.

(In reply to comment #27) > (In reply to comment #26) > > The best option, and I personally like this one the most, is to submit DMD to > > Fedora, and make it in the official Fedora repository. > > I have suggested some time ago to completely remove from the archive binaries > for distros that have DMD in core repositories. AFAIR it was rejected as not > user-friendly (ironically). It was some time ago though, can't remember the > details. DMD is not in the Fedora repository. Well, not yet, but I will start working on it...

(In reply to comment #26) > Walter, the solution is very simple - build the Fedora RPM on Fedora. Simple as > that. We can ask Alex to give us access to his Fedora box (I think it is a > virtual machine) and build the RPM there. > > The best option, and I personally like this one the most, is to submit DMD to > Fedora, and make it in the official Fedora repository. I can volunteer to do > this, although it will take some time because I do not have any Fedora RPMs > submitted so Fedora people may be skeptical about my RPM skills at first... > These two require the same action, overhauling the build mechanism. As discussed here http://forum.dlang.org/post/[email protected] we likely won't get there until 2.065. > Another option is to change the SPEC file and make it explicitly depend on the > gnutls RPM (there is gnutls RPM in Fedora!). This will indirectly force user to > install curl that is linked against gnutls. curl RPM package from Fedora > repository can be re-built with gnutls as default TLS library. This sounds like the way to go for this release. I'll take care of this.

(In reply to comment #29) > > Another option is to change the SPEC file and make it explicitly depend on the > > gnutls RPM (there is gnutls RPM in Fedora!). This will indirectly force user to > > install curl that is linked against gnutls. curl RPM package from Fedora > > repository can be re-built with gnutls as default TLS library. > > This sounds like the way to go for this release. I'll take care of this. Bad luck, there is not libcurl-gnutls in Fedora. I remember that I already looked for that earlier. I tried to patch the libphobos.so ELF to depend on libcurl.so.4 instead of libcurl-gnutls.so.4 but that won't work because of the versioned symbols (curl_easy_setup@CURL_GNUTLS_3). So again I'm out of ideas other than to build on a fedora machine. I'll have a look at the makefiles and see how easily we can fix this. We can also delay releasing the fedora package.

DMD v2.064 beta2 still with curl versioned symbols: $ objdump -x linux/lib32/libphobos2.so | grep " curl" | awk '{print $NF}' curl_easy_cleanup@@CURL_OPENSSL_3 curl_easy_strerror@@CURL_OPENSSL_3 curl_easy_setopt@@CURL_OPENSSL_3 curl_easy_duphandle@@CURL_OPENSSL_3 curl_global_cleanup@@CURL_OPENSSL_3 curl_easy_init@@CURL_OPENSSL_3 curl_global_init@@CURL_OPENSSL_3 curl_easy_pause@@CURL_OPENSSL_3 curl_slist_append@@CURL_OPENSSL_3 curl_slist_free_all@@CURL_OPENSSL_3 curl_easy_perform@@CURL_OPENSSL_3 $ objdump -x linux/lib64/libphobos2.so | grep " curl" | awk '{print $NF}' curl_easy_setopt@@CURL_GNUTLS_3 curl_slist_append@@CURL_GNUTLS_3 curl_slist_free_all@@CURL_GNUTLS_3 curl_global_cleanup@@CURL_GNUTLS_3 curl_easy_strerror@@CURL_GNUTLS_3 curl_easy_init@@CURL_GNUTLS_3 curl_easy_cleanup@@CURL_GNUTLS_3 curl_easy_duphandle@@CURL_GNUTLS_3 curl_easy_perform@@CURL_GNUTLS_3 curl_easy_pause@@CURL_GNUTLS_3 curl_global_init@@CURL_GNUTLS_3

(In reply to comment #13) > - Compile/link into Ubuntu with a libcurl without versioned symbols, this > requires an specific package not available on default repositories. I have an idea for an intermediate solution to this. We add a libcurl_stub.c to phobos that contains all functions used by phobos. void curl_global_init() {} void curl_easy_setop() {} ... We build a libcurl.so from the stubs and use it when linking phobos.

Is there no library without the @@ suffix that we can link with?

Or using dynamic linking as Andrei suggested. Wouldn't this allow to link to any version of libcurl? Then the user can choose to have libcurl4-openssl-dev, libcurl4-nss-dev or libcurl4-gnutls-dev.

(In reply to comment #33) > Is there no library without the @@ suffix that we can link with? No. All curl libraries on Debian based OS systems have versioned symbols.

(In reply to comment #32) > (In reply to comment #13) > > - Compile/link into Ubuntu with a libcurl without versioned symbols, this > > requires an specific package not available on default repositories. > > I have an idea for an intermediate solution to this. > We add a libcurl_stub.c to phobos that contains all functions used by phobos. > > void curl_global_init() {} > void curl_easy_setop() {} > ... > > We build a libcurl.so from the stubs and use it when linking phobos. For me it is fine, as long as it is a temporary measure.

(In reply to comment #36) > For me it is fine, as long as it is a temporary measure. Well the replacement is setting up real build scripts for the different distributions. Hopefully we'll get there for the next release. https://github.com/D-Programming-Language/phobos/pull/1661

(In reply to comment #37) > (In reply to comment #36) > > For me it is fine, as long as it is a temporary measure. > > Well the replacement is setting up real build scripts for the different > distributions. > Hopefully we'll get there for the next release. > > https://github.com/D-Programming-Language/phobos/pull/1661 With this patch we should install the new "libcurl_stub.so" too. Its SONAME is the linking name "libcurl.so", so this will make the new Linux dmd/phobos packages incompatible with all other curl development libraries packages (cannot be installed together). For me this is not a problem. If accepted, I need a new beta to fix all these new things (set dependencies, conflicts, include the new library, symlinks, etc.)

(In reply to comment #37) > (In reply to comment #36) > > For me it is fine, as long as it is a temporary measure. > > Well the replacement is setting up real build scripts for the different > distributions. > Hopefully we'll get there for the next release. > > https://github.com/D-Programming-Language/phobos/pull/1661 Sorry, I misunderstood you :-/ This new "libcurl_stub.so" library is for linking purposes only, and not for run-time, right? Then the SONAME should be "libcurl.so.4" because this is the library name that "libphobos2.so.x.xx.x" will find on Linux systems. With "libcurl.so" SONAME, we will force final users to install libcurl development packages to run dmd/phobos programs. Anyway, development phobos will still depending on libcurl development packages, which cannot be installed 32-bit and 64-bit together on multi-arch systems.

I already have a working dmd.spec file which builds on Fedora, and produces proper set of RPMs. Phobos is linked against the system libcurl, and everything works nicely. I am testing it, and was planning to put everything on a well-known page so Fedora users can have proper DMD packages. Long term plan is to have DMD in the Fedora repository, but I doubt that will happen soon because of the backend license... We'll see how it goes. If Fedora people do not want to have it in Fedora repository because of the backend license, we will put DMD on RpmFusion. Not bad anyway because typical Fedora user uses RpmFusion. Kind regards

Speaking about the license... I was just checking the backend license, and unfortunately I do not see a legal way to provide RPMs for users. The only legal ways are 1) to get a source code and build it, without distributing further 2) have packages distributed by copyright holders. So my question is - is dlang.org a legal place to put the packages? From the license: "<...> The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license, please contact Digital Mars." So, if I understand the text, DMD packages should only be distributed by DigitalMars. If community from dlang.org and other places wants to distribute DMD, that is, as far as I understand this license, ILLEGAL.

As far as I understand, explicit redistribution permission from Walter is enough.

(In reply to comment #40) > I already have a working dmd.spec file which builds on Fedora, and produces > proper set of RPMs. Phobos is linked against the system libcurl, and everything > works nicely. I am testing it, and was planning to put everything on a > well-known page so Fedora users can have proper DMD packages. > > Long term plan is to have DMD in the Fedora repository, but I doubt that will > happen soon because of the backend license... We'll see how it goes. If Fedora > people do not want to have it in Fedora repository because of the backend > license, we will put DMD on RpmFusion. Not bad anyway because typical Fedora > user uses RpmFusion. > > Kind regards Did you test these rpm packages on OpenSUSE?

(In reply to comment #43) > > Did you test these rpm packages on OpenSUSE? Yes, I have latest openSuSE dev machine at work as well, but my primary targets are CentOS and Fedora. You can find me on IRC if you wish to take the conversation off-line. PS. the SPEC file is at: https://www.gitorious.org/dejan-fedora/dejan-fedora . I did not push the latest code there though... :)

(In reply to comment #40) > I already have a working dmd.spec file which builds on Fedora, and produces > proper set of RPMs. Phobos is linked against the system libcurl, and everything > works nicely. I am testing it, and was planning to put everything on a > well-known page so Fedora users can have proper DMD packages. > This is great news. I added some comments in your repo. How about creating a pull request with this spec file for htpp://github.com/D-Programming-Language/installer repo. This would allow us to build fedora releases from source and simplify maintenance of the spec file.

(In reply to comment #24) > (In reply to comment #23) > > > How? Removing std.net.curl is not an option. > > > > why not? > > Not in the near term. I don't know what the general sentiment about this is, > but anyways we couldn't remove a module without deprecation. While the pull request is accepted or not, I think it would be important to determine the sentiment of the people about maintaining curl on phobos, and take a decision based on this result. How can we know that sentiment?

> While the pull request is accepted or not, I think it would be important to > determine the sentiment of the people about maintaining curl on phobos, and > take a decision based on this result. > How can we know that sentiment? Several of the main devs (including Walter) have stated that having std.net.curl was a mistake given all of the problems that we've had with it on Windows, and at least some of them have a expressed a desire for it to be removed. We should probably bring it up for discussion in the main newsgroup. I expect that there's a good chance that it can and will be removed from Phobos if brought up for discussion. Certainly, I think that it's clear that we will not add any further external dependencies like curl, because curl has proven to be a big problem. It's very desirable to have bindings and wrappers for C libraries - but putting them in the standard library when it's not guaranteed that the appropriate library is on the system by default has proven to be too problematic, so they should be left to external projects.

(In reply to comment #47) > Several of the main devs (including Walter) have stated that having > std.net.curl was a mistake given all of the problems that we've had with it on > Windows, and at least some of them have a expressed a desire for it to be > removed. We should probably bring it up for discussion in the main newsgroup. I > expect that there's a good chance that it can and will be removed from Phobos > if brought up for discussion. > > Certainly, I think that it's clear that we will not add any further external > dependencies like curl, because curl has proven to be a big problem. It's very > desirable to have bindings and wrappers for C libraries - but putting them in > the standard library when it's not guaranteed that the appropriate library is > on the system by default has proven to be too problematic, so they should be > left to external projects. Totally agree. Can you reissue this post to the main newsgroup in order to open this discussion please? Thank you.

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d0e51e109fe50270109423ef267765b79067b22c fix Issue 10710 - phobos depends on versioned libcurl - create a libcurl_stub.so for linking - set it's soname to libcurl.so.4 so that phobos gets a DT_NEEDED libcurl.so.4 entry - the runtime linker will load libcurl.so and resolve all undefined references - disable pragma(lib, "curl") because it doesn't work for archives anyways and additionally links against the real libcurl (dmd appends -L-lcurl when building phobos). https://github.com/D-Programming-Language/phobos/commit/1fcfe2c35c062798d9e0c805d4cf611a6096b16a Merge pull request #1772 from MartinNowak/fix10710 fix Issue 10710 - phobos depends on versioned libcurl

Commit pushed to 2.065 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e7cb5f7838e45f71910b6b6fbe4abebc84f42dba Merge pull request #1772 from MartinNowak/fix10710 fix Issue 10710 - phobos depends on versioned libcurl Conflicts: posix.mak

This is now fixed provisionally. The outstanding solution is to build release for each distribution individually. Should we still close this issue?

Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e7cb5f7838e45f71910b6b6fbe4abebc84f42dba Merge pull request #1772 from MartinNowak/fix10710

fine with closing, thanks