On Thu, Feb 19, 2015 at 05:19:30PM -0600, Jeff Epler wrote:
> * foomodule is a Python wrapper for libfoo, so it must be shipped
>as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
>it is not possible to build foomodule at all
>
>(The same goes for wrapping the library for
"Bernhard R. Link" writes:
> * Russ Allbery [150222 21:51]:
>> It won't with something more complex on all architectures. I think
>> there are architectures (i386, maybe?) where you can link non-PIC code
>> into a shared library with a performance penalty, and (as mentioned by
>> another) it do
* Russ Allbery [150222 21:51]:
> "Bernhard R. Link" writes:
>
> > This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
> > need to be PIC:
>
> > echo 'int foo(void) {return 17;}' > foo.c
> > echo 'int bar(void) {return foo();}' > bar.c
> > echo 'int main() {return bar();}' > main.c
* Simon Richter [150222 21:19]:
> Am 22.02.2015 um 20:18 schrieb Bernhard R. Link:
>
> > echo 'int foo(void) {return 17;}' > foo.c
>
> This code just happens to not generate any data references, so none of
> the forbidden reloc types are emitted.
You can add references here. As I do not merge i
* Ian Jackson [150223 20:09]:
> Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
> code?"):
> > Jeff Epler [150220 00:19]:
> > > * libbar has a stable API, so it should be shipped as a .so,
> > >but if it links libfoo.a, and libfoo.a is not -fPIC, then
> > >lib
-20150223/002086.html
Other applications need packaging, do not hesitate to get in touch with
the team if you want to help, I’ll post some RFPs later if nobody beats
me to it (and will be happy to sponsor any of the ownCloud related
packages from people without upload rights).
Regards
David
Ian Jackson writes ("Re: Should .a library contains non-reallocatable code?"):
> Jeff is correct.
...
> That not usually a problem. Providing that only the relevant symbols
> are exported from the .so, the executable simply results in multiple
> completely independent copies of the static library.
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Jeff Epler [150220 00:19]:
> > * libbar has a stable API, so it should be shipped as a .so,
> >but if it links libfoo.a, and libfoo.a is not -fPIC, then
> >libbar has to be shipped as a a static library
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: labltk
Version : 8.06.0
Upstream Author : Inria
* URL : https://forge.ocamlcore.org/projects/labltk/
* License : LGPL
Programming Lang: C, OCaml
Description : OCaml bindings to Tc
On Sun, Feb 22, 2015 at 11:59:17PM +0100, Adam Borowski wrote:
> On Sun, Feb 22, 2015 at 05:00:30PM +, Colin Watson wrote:
> > the simplest procedure I've found involves going via 7.8 (yes, really).
> > But I bootstrapped ghc successfully that way on arm64 and ppc64el, and I
> > can probably r
Hi,
On Sun, Feb 22, 2015 at 03:56:20AM +0100, Adam Borowski wrote:
> * no libreoffice: java toolchain has JNI issues
There's --without-java. Might work or not, doubt many people use it
these days. (As long as baseline is 1.5 I can still use gcj...)
But I'd be surprised if it worked even then, yo
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libwww-shorten-simple-perl
Version : 0.01
Upstream Author : Tatsuhiko Miyagawa
* URL : https://metacpan.org/release/WWW-Sh
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libdist-zilla-plugin-twitter-perl
Version : 0.026
Upstream Author : David Golden , Mike Doherty
* URL : https://metacpan.
Package: wnpp
Severity: wishlist
Owner: Alexandre Mestiashvili
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org
* Package name: subread
Version : 1.4.6-p1
Upstream Author : shi at wehi dot edu dot au
* URL : http://subread.sourceforge.net/
* Li
14 matches
Mail list logo
