Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
merge 444360 443150 tags 444360 + help tags 443150 + help thanks On Fri, Sep 28, 2007 at 02:10:06AM +0200, Frank Lichtenheld wrote: your package failed to build from source. Yep, thanks, was already reported. I'll look into this but I would appreciate help from some of the Apache guys, since apparently apxs is not invoking the compilers to build PIC code ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:12:35 +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 02:10:06AM +0200, Frank Lichtenheld wrote: your package failed to build from source. Yep, thanks, was already reported. I'll look into this but I would appreciate help from some of the Apache guys, since apparently apxs is not invoking the compilers to build PIC code ... The problem seems to be that you're trying to build the mod_netcgi_apache.so shared object while linking with -lcamlrun, but libcamlrun only exists as a static (non-PIC) library. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:48:50AM +0200, Julien Cristau wrote: The problem seems to be that you're trying to build the mod_netcgi_apache.so shared object while linking with -lcamlrun, but libcamlrun only exists as a static (non-PIC) library. Aaaarggh, right! IIRC that's an upstream issue for which exists a patch (by Richard Jones maybe ...), isn't it? What about applying it in the OCaml Debian package? Thanks for the pointer, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. [I meant to say -lcamlrun_shared here] I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... That would also need to go upstream before Fedora could accept it. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, 2007-09-28 at 14:26 +0100, Richard Jones wrote: On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. [I meant to say -lcamlrun_shared here] I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... That would also need to go upstream before Fedora could accept it. Why? I would have thought it is close to *policy* to provide libraries for both static and dynamic link. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Sat, Sep 29, 2007 at 12:58:12AM +1000, skaller wrote: On Fri, 2007-09-28 at 14:26 +0100, Richard Jones wrote: On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. [I meant to say -lcamlrun_shared here] I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... That would also need to go upstream before Fedora could accept it. Why? I would have thought it is close to *policy* to provide libraries for both static and dynamic link. Please don't get me wrong here: I want the patch in OCaml, I want Fedora to follow Debian's packaging decisions where possible, and I want to have mod_caml ocamlnet + Apache working. But this patch is a big potential change to the API and it can't go in to Fedora unless INRIA accept it upstream, and that concern overrides other issues. Hopefully INRIA will indicate that they want to accept this in which case it can go in to Fedora straightaway. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 12:59:20PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 09:59:45AM +0200, Stefano Zacchiroli wrote: Aaaarggh, right! IIRC that's an upstream issue for which exists a patch (by Richard Jones maybe ...), isn't it? What about applying it in the OCaml Debian package? Yep, that was the case, here is a link to the corresponding entry in the caml BTS: http://caml.inria.fr/mantis/view.php?id=3866 . Apparently upstream do not care a lot about this issue, but I think the final solution hinted by Richard is the right one: leave libcarmlrun.a as it is and additionally provide a libcamlrun_shared.so which we can use where PIC code is required. Any comments / objection to add something like that to the ocaml package in Debian? Richard: do you perhaps already have a patch for this in Red Hat? No I don't actually. It's strange because I didn't hit this bug at all when compiling ocamlnet for Fedora. Unfortunately Fedora policy stops me from incorporating this fix: http://caml.inria.fr/mantis/view.php?id=3866 into our OCaml. It would have to be accepted into upstream (INRIA's) OCaml first. But it's desperately needed, so please vote for INRIA to include it :-) Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:59:45AM +0200, Stefano Zacchiroli wrote: Aaaarggh, right! IIRC that's an upstream issue for which exists a patch (by Richard Jones maybe ...), isn't it? What about applying it in the OCaml Debian package? Yep, that was the case, here is a link to the corresponding entry in the caml BTS: http://caml.inria.fr/mantis/view.php?id=3866 . Apparently upstream do not care a lot about this issue, but I think the final solution hinted by Richard is the right one: leave libcarmlrun.a as it is and additionally provide a libcamlrun_shared.so which we can use where PIC code is required. Any comments / objection to add something like that to the ocaml package in Debian? Richard: do you perhaps already have a patch for this in Red Hat? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 01:17:00PM +0100, Richard Jones wrote: No I don't actually. It's strange because I didn't hit this bug at all when compiling ocamlnet for Fedora. Are you building the Apache connector? The bug manifests itself only if you're building that, and only on architecture in which PIC code is actually different than non-PIC code. Unfortunately Fedora policy stops me from incorporating this fix: http://caml.inria.fr/mantis/view.php?id=3866 into our OCaml. It would have to be accepted into upstream (INRIA's) OCaml first. Why? But it's desperately needed, so please vote for INRIA to include it :-) Well, nobody replied to the bug report, so I don't think pinging there will be useful. The only other possible step is to raise the problem on the caml mailing list, what do you think? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 02:32:16PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 01:17:00PM +0100, Richard Jones wrote: No I don't actually. It's strange because I didn't hit this bug at all when compiling ocamlnet for Fedora. Are you building the Apache connector? The bug manifests itself only if you're building that, and only on architecture in which PIC code is actually different than non-PIC code. I thought we were but I just checked the specfile and it turns out we aren't. Unfortunately Fedora policy stops me from incorporating this fix: http://caml.inria.fr/mantis/view.php?id=3866 into our OCaml. It would have to be accepted into upstream (INRIA's) OCaml first. Why? Because of our policy ... http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
Package: ocamlnet Version: 2.2.8.1-3 Severity: serious Hi, your package failed to build from source. | Automatic build of ocamlnet_2.2.8.1-3 on meitner by sbuild/hppa 98-farm | Build started at 20070927-2256 | ** | Checking available source versions... | Fetching source files... | Reading package lists... | Building dependency tree... | Reading state information... | Need to get 1891kB of source archives. | Get:1 http://ftp.de.debian.org experimental/main ocamlnet 2.2.8.1-3 (dsc) [1253B] | Get:2 http://ftp.de.debian.org experimental/main ocamlnet 2.2.8.1-3 (tar) [1877kB] | Get:3 http://ftp.de.debian.org experimental/main ocamlnet 2.2.8.1-3 (diff) [12.7kB] | Fetched 1891kB in 22s (85.8kB/s) | Download complete and in download only mode | ** Using build dependencies supplied by package: | Build-Depends: debhelper ( 5.0.0), dpatch, cdbs, ocaml-nox (= 3.10.0), camlp5 (= 4.08), ocaml-findlib, libpcre-ocaml-dev (= 5.11.1), liblablgtk2-ocaml-dev, libcryptgps-ocaml-dev, libssl-ocaml-dev, apache2-mpm-worker, apache2-prefork-dev | Checking for already installed source dependencies... [...] | /usr/bin/apxs2 -c -o mod_netcgi_apache.so wrappers.lo handler.lo apache.lo netcgi_apache_mod.lo -L/usr/lib/ocaml/3.10.0 -lcamlrun -ltermcap -lunix -lstr | /usr/share/apr-1.0/build/libtool --silent --mode=link --tag=disable-static hppa-linux-gnu-gcc -o mod_netcgi_apache.la -rpath /usr/lib/apache2/modules -module -avoid-versionwrappers.lo handler.lo apache.lo netcgi_apache_mod.lo -L/usr/lib/ocaml/3.10.0 -lcamlrun -ltermcap -lunix -lstr | /usr/bin/ld: /usr/lib/ocaml/3.10.0/libcamlrun.a(stacks.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC | /usr/lib/ocaml/3.10.0/libcamlrun.a: could not read symbols: Bad value | collect2: ld returned 1 exit status | apxs:Error: Command failed with rc=65536 | .. | make[2]: *** [mod_netcgi_apache.so] Error 1 | make[2]: Leaving directory `/build/buildd/ocamlnet-2.2.8.1/src/netcgi2-apache' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/build/buildd/ocamlnet-2.2.8.1' | make: *** [debian/stamp-makefile-build] Error 2 | ** | Build finished at 20070927-2326 | FAILED [dpkg-buildpackage died] Full build log(s): http://experimental.ftbfs.de/build.php?ver=2.2.8.1-3pkg=ocamlnetarch=hppa Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
