* Ian Jackson ijack...@chiark.greenend.org.uk [150227 16:39]:
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
No-one is proposing
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
No-one is proposing that shared libraries should not be built, and
used, when possible. We
* Ian Jackson ijack...@chiark.greenend.org.uk [150224 18:51]:
Right. I think that the right answer to this, in these cases, is
either to use an explicit symbol export file or to adjust the link
command lines.
adjust the link command lines ? That's like saying the mine field
is safe because
Simon Richter writes (Re: Should .a library contains non-reallocatable code?):
Am 24.02.2015 um 11:01 schrieb Alastair McKinstry:
I agree with this; are there any cases where only a static library _is_
provided, and if so why? why not provide a .so?
In libvxi-dev I provide a -fPIC
Hi,
On 25.02.2015 15:35, Ian Jackson wrote:
In libvxi-dev I provide a -fPIC .a library only, mainly for size reasons
(the library consists of RPC proxy/stub code for the VXI-11 protocol,
and is completely generated with rpcgen).
Do many other packages use that library ?
No, just one.
If
Simon Richter writes (Re: Should .a library contains non-reallocatable code?):
On 25.02.2015 15:35, Ian Jackson wrote:
In libvxi-dev I provide a -fPIC .a library only, mainly for size reasons
(the library consists of RPC proxy/stub code for the VXI-11 protocol,
and is completely generated
On 23/02/2015 19:17, Ian Jackson wrote:
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
On 2015-02-24 11:01, Alastair McKinstry wrote:
I agree with this; are there any cases where only a static library _is_
provided, and if so why? why not provide a .so?
One use case that was described to me was about libraries with APIs that
were not yet considered stable enough to be (properly)
Jeff Epler writes (Re: Should .a library contains non-reallocatable code?):
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
(I have reordered Bernard's mail and my responses to try to produce a
coherent whole.)
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
[examples not involving -Bsymbolic]
My view is that when trying to build a shared library that depends on
a static library
* Ian Jackson ijack...@chiark.greenend.org.uk [150224 15:50]:
You still pollute the ABI with the details of the internals:
if you try to change main.c to:
#include stdio.h
#include foo1.h
#include bar2.h
int main() {
double rr1;
foo(rr1);
int r1 = rr1;
int r2 =
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Ian Jackson ijack...@chiark.greenend.org.uk [150224 15:50]:
+ gcc -Wall main.c -L. -lbar1 -lbar2
You forgot to change that line as I said to change it.
Ah yes, sorry. I can reproduce the problem that way
Hi,
Am 24.02.2015 um 11:01 schrieb Alastair McKinstry:
I agree with this; are there any cases where only a static library _is_
provided, and if so why? why not provide a .so?
In libvxi-dev I provide a -fPIC .a library only, mainly for size reasons
(the library consists of RPC proxy/stub code
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.
I
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Jeff Epler jep...@unpythonic.net [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
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 brl...@debian.org writes:
* Russ Allbery r...@debian.org [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
* Ian Jackson ijack...@chiark.greenend.org.uk [150223 20:09]:
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Jeff Epler jep...@unpythonic.net [150220 00:19]:
* libbar has a stable API, so it should be shipped as a .so,
but if it links libfoo.a
* Simon Richter s...@debian.org [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
* Russ Allbery r...@debian.org [150222 21:51]:
Bernhard R. Link brl...@debian.org 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
On Sun, Feb 22, 2015 at 08:18:33PM +0100, Bernhard R. Link wrote:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable:
* 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
Hi,
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.
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
Bernhard R. Link brl...@debian.org 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
gcc -c -Wall foo.c
ar rs libfoo.a
* Jeff Epler jep...@unpythonic.net [150220 00:19]:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable:
* 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
* Jeff Epler jep...@unpythonic.net, 2015-02-19, 17:19:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable:
* 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
On 20/02/2015 12:06, Simon McVittie wrote:
On 19/02/15 23:19, Jeff Epler wrote:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable
...
I wonder whether these scenarios were considered when the Policy was
written.
Conversely, when that part of the policy
On 19/02/15 23:19, Jeff Epler wrote:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable
...
I wonder whether these scenarios were considered when the Policy was
written.
Conversely, when that part of the policy was written, 32-bit x86 was the
major
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am 20.02.2015 um 13:36 schrieb Jakub Wilk:
IMO the policy is overly strict and it should be relaxed.
Speaking of relaxing things: could this be solved with linker relaxations?
The compiler would need to generate both PIC and non-PIC code in
* Dmitry Katsubo dm...@mail.ru, 2015-02-14, 13:31:
I wonder what is the current state-of-art concerning the code in .a
library (archive for static linking). Should it contain PIC code?
This is what Debian Policy (§10.2) currently says:
“As to the static libraries, the common case is not to
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable:
* 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 too
* foomodule is a Python
Hi,
On 14.02.2015 13:31, Dmitry Katsubo wrote:
I wonder what is the current state-of-art concerning the code in .a
library (archive for static linking). Should it contain PIC code?
Normally, no.
Situation: Dynamic (.so) library needs to be linked against such (.a)
library.
That is
Dear Debian Developers,
I wonder what is the current state-of-art concerning the code in .a
library (archive for static linking). Should it contain PIC code?
Situation: Dynamic (.so) library needs to be linked against such (.a)
library.
Thank you for any advises and your opinion in advance.
On
32 matches
Mail list logo
