www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10710] New: shared phobos library doesn't work on all linux distributions

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710

           Summary: shared phobos library doesn't work on all linux
                    distributions
           Product: D
           Version: D2
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: installer
        AssignedTo: nobody puremagic.com
        ReportedBy: code dawg.eu



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)
----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



13:23:21 PDT ---
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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Jacob Carlborg <doob me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Dicebot <public dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public dicebot.lv



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Jordi Sayol <g.sayol yahoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |g.sayol yahoo.es



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710





 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710







  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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 - 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 - 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Andrei Alexandrescu <andrei erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei erdani.com



09:54:41 PDT ---
One possibility is by loading dynamically whichever curl is available on the
OS.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Dejan Lekic <dejan.lekic gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dejan.lekic gmail.com



PDT ---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




PDT ---




 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...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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/525B68A7.1090609 puremagic.com 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 - 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






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


No. All curl libraries on Debian based OS systems have versioned symbols.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 - 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull





 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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 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.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710








 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




PDT ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710




PDT ---


 
 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... :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10710






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 29 2013