: BSD-2
Programming Lang: OCaml
Description : Semantic model for aspects of ELF static linking and DWARF
debug information
Linksem is a formalisation of substantial parts of ELF linking and DWARF debug
information. It contains:
A formalisation of the core ELF file format, the de facto
. Then that director departed the company and
FreeBSD was out the window--back to Linux.[1]
Worse, when any of these disruptions happens to the origin of a module
that employs static linking, it can take an indefinite amount of time to
_find out_ that such has even taken place. So its user community
On Tue, 2016-11-01 at 22:54 +0200, Adrian Bunk wrote:
> I do not see any reason for waiting instead of sending the binNMU
> request right now.
I didn't see any movement on the dpkg front so I went ahead and did so:
#843139.
Thanks,
Ian.
On Tue, Nov 01, 2016 at 10:54:33PM +0200, Adrian Bunk wrote:
> LUA
The language is named "Lua", which means "moon" in Portuguese.
https://www.lua.org/about.html#name
LUA is an acronym for "Lua Uppercase Accident" ;-).
Peter
On Mon, Oct 31, 2016 at 03:23:51PM +0100, Bálint Réczey wrote:
> Hi Ian,
>
> 2016-10-31 14:19 GMT+01:00 Ian Campbell :
> > On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> >> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> >> > If possible I'd also prefer a solution which fixed qcontrol-stati
Hi Ian,
2016-10-31 14:19 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
>> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
>> > If possible I'd also prefer a solution which fixed qcontrol-static
>> > without opting out for the normal dynamic/non-udeb binary.
>>
>> I r
On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> > If possible I'd also prefer a solution which fixed qcontrol-static
> > without opting out for the normal dynamic/non-udeb binary.
>
> I ran the build tests on amd64, this is why I have not caugh
2016-10-31 12:52 GMT+01:00 Henrique de Moraes Holschuh :
> On Mon, 31 Oct 2016, Ian Campbell wrote:
>> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> > ?
>>
>> Thanks, but that doesn't appear to help, I think the issue is to do
>> w
On Mon, 31 Oct 2016, Ian Campbell wrote:
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> > ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening setting
Hi Ian,
2016-10-31 10:38 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening
On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> ?
Thanks, but that doesn't appear to help, I think the issue is to do
with the changed default in gcc rather than the hardening settings
injected into the build by dpkg-buildpackage/dpkg-b
export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
?
2016-10-31 10:21 GMT+01:00 Ian Campbell :
> Hi,
>
> I maintain qcontrol[0] which builds on armel and armhf only (it's a
> tool specific to certain NAS machines). It links a version against
> liblua statically for use in a udeb (the resulting
Hi,
I maintain qcontrol[0] which builds on armel and armhf only (it's a
tool specific to certain NAS machines). It links a version against
liblua statically for use in a udeb (the resulting binary is dynamic,
it is only liblua5.1 which is linked statically).
It seems that on armhf my latest uploa
* Jonas Smedegaard (d...@jones.dk) wrote:
> Quoting Eric Dorland (2015-05-19 21:44:50)
> > What's the current thinking on embedded libraries in source code? One
> > of my packages has an embedded (and slightly modified) version of
> > libevent that it links statically. It doesn't seem like Built-
Quoting Eric Dorland (2015-05-19 21:44:50)
> What's the current thinking on embedded libraries in source code? One
> of my packages has an embedded (and slightly modified) version of
> libevent that it links statically. It doesn't seem like Built-Using is
> the right thing to use in this situati
On 19/05/2015 07:43, Bastien Roucaries wrote:
>
> Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise a écrit :
>> Hi all,
>>
>> I have prepared a short document on static linking and Debian, with the
>> aim to reduce existing static linking, document unavoidable stat
* Paul Wise (p...@debian.org) wrote:
> Hi all,
>
> I have prepared a short document on static linking and Debian, with the
> aim to reduce existing static linking, document unavoidable static
> linking and find ways to mitigate unavoidable static linking.
>
> ht
Hi!
On Tue, 2015-05-19 at 18:21:40 +0100, Rebecca N. Palmer wrote:
> What's the preferred way to set Built-Using:
> http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82
This one is wrong in two ways, it's missing the exact version, and the
field does not belon
thout-dependency-information check appears to catch only
_totally_ static linking, while my (few) packages suggest "dynamically
link common libraries such as libc, statically link (or embed) more
unusual libraries" is the more common problem. (E.g. upstream beignet
defaults to dynamic lib
❦ 19 mai 2015 09:30 +0800, Paul Wise :
> I have prepared a short document on static linking and Debian, with the
> aim to reduce existing static linking, document unavoidable static
> linking and find ways to mitigate unavoidable static linking.
>
> https://wiki.debian.org/Static
Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise a écrit :
>Hi all,
>
>I have prepared a short document on static linking and Debian, with the
>aim to reduce existing static linking, document unavoidable static
>linking and find ways to mitigate unavoidable static li
Hi all,
I have prepared a short document on static linking and Debian, with the
aim to reduce existing static linking, document unavoidable static
linking and find ways to mitigate unavoidable static linking.
https://wiki.debian.org/StaticLinking
I'm hoping folks on this list will help e
the nsswitch mechanism (specifically the hosts configuration), which is
> >> inherently dynamic and doesn't support static linking.
> >
> > It nevertheless is expected to work when the corresponding NSS modules are
> > present. It's not truly static, but the
Hi,
Julian Taylor:
> this is already the case with regular static linking, you don't need LTO
> to remove unused code, the compiler only uses those objects from that
> archive that are required to resolve all symbols.
>
… remove _some_ unused code. Lots of code the linker pulls
d be
> stripped out of the resulting binaries.
>
this is already the case with regular static linking, you don't need LTO
to remove unused code, the compiler only uses those objects from that
archive that are required to resolve all symbols.
--
To UNSUBSCRIBE, email to debian-devel-re
On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:
> apps becomes huge in size
I wonder if LTO would help with the size issues, theoretically all the
code from the static glibc that isn't used by busybox-static would be
stripped out of the resulting binaries.
--
bye,
pabs
https://wiki.debi
hich is
>> inherently dynamic and doesn't support static linking.
>
> It nevertheless is expected to work when the corresponding NSS modules are
> present. It's not truly static, but the dynamic loading from static libc is
> supported.
When a statically linked app calls
by* APIs from the static glibc intentional?
> Yes. It's the nsswitch problem. The behavior of those APIs is controlled
> by the nsswitch mechanism (specifically the hosts configuration), which is
> inherently dynamic and doesn't support static linking.
It nevertheless is expecte
the hosts configuration), which is
inherently dynamic and doesn't support static linking.
> Perhaps glibc upstream would be willing to restore them?
It would be nice, but I doubt you'll make much progress. Lots of people
have complained about this over the years.
--
Russ Allbery (r
On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
> But with jessie, for one, all network name resolution (gethostby* etc APIs)
> don't work anymore, because glibc does not provide them instatic libraries.
> So usual network utilities in busybox does not anymore, they just return
> `host not
Hello.
For a very long time, we had a busybox variant which is linked statically,
for rescue or other similar purposes (for those who don't know, busybox
provides minimal implementations of varios system utilities so can be used
almost alone as a replacement for whole (minimal) system).
But with
rary has an unstable ABI, dynamic linking is still slightly
preferable for packaged applications, but static linking is preferable
for unpackaged applications. I think.
[...]
> - Static linking is a security nightmare, as are embedded copies
> of libraries. It creates additional work and it
y.
- I don't see how dynamic linking negates versioning issues. In
fact I think because we have dynamic linking people actually
care about the ABI and so we have less problems.
- I can't see how libxml wouldn't be a core package. Maybe he
should check how many copies of
On Thu, Aug 28, 2014 at 5:38 PM, Salvo Tomaselli wrote:
> Hello,
>
> I've recently packaged subsurface 4.2 for experimental, because it depends on
> libgit2 which is in experimental…
>
> I think you might want to read these posts:
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.
Hello,
I've recently packaged subsurface 4.2 for experimental, because it depends on
libgit2 which is in experimental…
I think you might want to read these posts:
http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.html
http://lists.hohndel.org/pipermail/subsurface/2014-August/01452
from libtool *.la files or not ship
> them at all, making them useless for static linking information.
Gentoo is also in process of getting rid of .la files.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de
]] Simon McVittie
| On Sat, 20 Nov 2010 at 21:58:56 +0100, Tollef Fog Heen wrote:
| > | Upstreams are only meant to change the .pc filename when they make an
| > | incompatible change to the API
| >
| > This seems to be the trend, but there's nothing in pkg-config's policies
| > or best practice
Dmitry Katsubo writes:
> Russ, thank you for comments. To answer your question I quote only one
> important section from the document I've referred:
> === quote ===
> 3.2.4 pkg-config File
> Many libraries deliver a .pc file for use by the pkg-config helper
> utility, which aids other libraries
On Mon, 22 Nov 2010 at 16:18:52 +0100, Dmitry Katsubo wrote:
> On 19.11.2010 22:51, Russ Allbery wrote:
> > Dmitry Katsubo writes:
> >> * Some libraries (e.g.) do not follow the agreement for .NET/CLI
> >> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file)
> >> whic
On 19.11.2010 22:51, Russ Allbery wrote:
> Dmitry Katsubo writes:
>
>> The first problem I faced is that it is difficult to explore what should
>> be the list of libraries for static linking (as I have to provide the
>> list of libraries which are direct dependencies
On Sat, 20 Nov 2010 at 21:58:56 +0100, Tollef Fog Heen wrote:
> | Upstreams are only meant to change the .pc filename when they make an
> | incompatible change to the API
>
> This seems to be the trend, but there's nothing in pkg-config's policies
> or best practices guide that specifies this. I'
]] Simon McVittie
| Upstreams are only meant to change the .pc filename when they make an
| incompatible change to the API - if XFCE 4 is still compatible with the API
| (but not necessarily the ABI) of the earliest version that had xfprint-1.0.pc,
| then it shouldn't be renamed.
This seems to b
On Fri, 19 Nov 2010 at 22:30:09 +0100, Dmitry Katsubo wrote:
> * Some libraries (e.g. GraphicsMagick) does not provide the list of
> libraries for statis linking via .pc (compare 'pkg-config --static
> --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should
> it be fired as a bug for
Dmitry Katsubo writes:
> The first problem I faced is that it is difficult to explore what should
> be the list of libraries for static linking (as I have to provide the
> list of libraries which are direct dependencies as well as indirect). I
> know this problem is solved with li
libraries for static linking (as I have to provide the
list of libraries which are direct dependencies as well as indirect). I
know this problem is solved with libtool (which consumes the information
from *.la) and with pkg-config (which consumes the information from
*.pc). The problems I faced
Le mercredi 05 mai 2010 à 12:18 +0200, Simon Richter a écrit :
> Gtk would also need to include the SONAME from glib into their own,
> given that ABI breaks in glib also implicitly break their own ABI.
The GTK+ ABI stability guarantees are the same as the GLib ones. The
SONAMEs can only be changed
Hi,
On Wed, May 05, 2010 at 11:51:09AM +0200, Samuel Thibault wrote:
> A lot of gtk headers use GObjectClass types, macros and such, which are
> from Glib. You thus need both glib headers and libraries.
Gtk would also need to include the SONAME from glib into their own,
given that ABI breaks in
Hendrik Sattler, le Wed 05 May 2010 10:47:24 +0200, a écrit :
> Zitat von Josselin Mouette :
>
> >Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
> >>Sorry I don't know what you're talking about. If you can explain it
> >> I'll try to
> >>look at the problem.
> >
> >It’s not
Zitat von Josselin Mouette :
Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
Sorry I don't know what you're talking about. If you can explain it
I'll try to
look at the problem.
It’s not a problem, it’s a disagreement over a design choice.
When you do that:
#i
Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
> Sorry I don't know what you're talking about. If you can explain it I'll try
> to
> look at the problem.
It’s not a problem, it’s a disagreement over a design choice.
When you do that:
#include
you’re able to use g
]] Paul Wise
| On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen wrote:
|
| > | And GNOME developers insistance (so applications developers may
| > | blindly include gtk+2.0.pc and get all the stack).
| >
| > Yes, historical baggage, basically.
|
| So this is being fixed for GTK+ 3.0?
I don't b
On 03/05/10 10:46, Tollef Fog Heen wrote:
> ]] Mikhail Gusarov
> | And GNOME developers insistance (so applications developers may
> | blindly include gtk+2.0.pc and get all the stack).
>
> Yes, historical baggage, basically.
Sorry I don't know what you're talking about. If you can explain it I'
On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen wrote:
> | And GNOME developers insistance (so applications developers may
> | blindly include gtk+2.0.pc and get all the stack).
>
> Yes, historical baggage, basically.
So this is being fixed for GTK+ 3.0?
--
bye,
pabs
http://wiki.debian.org/Pa
]] Mikhail Gusarov
| Twas brillig at 23:54:02 02.05.2010 UTC+04 when yo...@debian.org did gyre and
gimble:
|
| >> For #includes that your library may do for its API (e.g. gobject).
|
| NVY> But libetpan's public headers do not include any headers of those
dependent
| NVY> packages, so it
Josselin Mouette writes:
> Le dimanche 02 mai 2010 à 11:57 -0500, Steve M. Robbins a écrit :
>> One example is scientific users that need to ensure reproducibility of
>> computer experiments [1] over many years: one technique used is to
>> statically link the code and quarantine it so that it
Le dimanche 02 mai 2010 à 11:57 -0500, Steve M. Robbins a écrit :
> One example is scientific users that need to ensure reproducibility of
> computer experiments [1] over many years: one technique used is to
> statically link the code and quarantine it so that it isn't disturbed
> by system librar
Twas brillig at 23:54:02 02.05.2010 UTC+04 when yo...@debian.org did gyre and
gimble:
>> For #includes that your library may do for its API (e.g. gobject).
NVY> But libetpan's public headers do not include any headers of those
dependent
NVY> packages, so it is not the case.
NVY> Any othe
Nikita V. Youshchenko, le Sun 02 May 2010 23:54:02 +0400, a écrit :
> > > > > > Static linking is resolved by providing a foo.pc file so that
> > > > > > "pkg-config --static --libs foo" is all that's needed to find
> > > > > > t
> > > > > Static linking is resolved by providing a foo.pc file so that
> > > > > "pkg-config --static --libs foo" is all that's needed to find
> > > > > the right libs.
> > > >
> > > > This does not clarify the qu
; > > > > at all. Hence, is it worth wasting archive space on the inevitably
> > > > > much larger .a files?)
> > > >
> > > > Static linking is resolved by providing a foo.pc file so that
> > > > "pkg-config --static --libs foo&quo
luded by any public libetpan
header.
In this case, dependences on those -dev packages are only because of (1)
dependemcy_libs in .la file, and (2) support for static linking.
signature.asc
Description: This is a digitally signed message part.
the dependency_libs field) largely amounts to
> > > > reconstructing the information that was in the .la originally.
> > > > That should be sufficient disincentive to try to statically link
> > > > at all. Hence, is it worth wasting archive space on the inevitably
> > > &g
I'm a little alarmed at the attitude that "no one cares about static
linking" so that it's okay to drop the .a files. Likely relatively
few people care, but there are some that do.
One example is scientific users that need to ensure reproducibility of
computer experiments
Neil Williams wrote:
> But does any package in Debian actually do the static linking?
A few udebs use static linking to avoid the need for separate udebs for
certain libraries. It also helps to reduce memory usage as only needed
symbols are linked in.
It's only used in a few specif
mounts to reconstructing
> > > the information that was in the .la originally. That should be
> > > sufficient disincentive to try to statically link at all. Hence, is it
> > > worth wasting archive space on the inevitably much larger .a files?)
> >
> > Stat
* Nikita V. Youshchenko [100502 11:27]:
> (3) looks like plain inconsistency: package will provide .a file, but not
> ensure things required for using .a file into system.
I think (3) is the best you can do if you assume the .a file is usefull
to anyone. If someone wants to link to the .a file, t
. That should be
> > sufficient disincentive to try to statically link at all. Hence, is it
> > worth wasting archive space on the inevitably much larger .a files?)
>
> Static linking is resolved by providing a foo.pc file so that
> "pkg-config --static --libs foo" is all
ufficient disincentive to try to statically link at all. Hence, is it
> worth wasting archive space on the inevitably much larger .a files?)
>
Static linking is resolved by providing a foo.pc file so that "pkg-config
--static --libs foo" is all that's needed to find the
ghty I just need to
> remove .la file from -dev package
>
> However I'm confused with how this interfers with static linking
> support. I've seen talks on this in list archives, but no
> project-scope resolution.
In the discussion that led to the release goal:
"It mi
d to remove .la
file from -dev package
However I'm confused with how this interfers with static linking support.
I've seen talks on this in list archives, but no project-scope resolution.
libetpan-dev depends on several other -dev packages because libraries from
those are mentione
Russ Allbery wrote:
[... explanation of the tradeoffs snipped ...]
> Note, btw, that for some algorithms, you might gain significant speed,
> more than the PIC difference, by being able to compile for more capable
> processors (enabling SSE2 can make a huge difference, for instance).
> Shared libr
On 10/12/2007 Simon Richter wrote:
> Hi,
>
> Jonas Meurer schrieb:
>
> >what do you think? should we ask libgcrypt11 and ligpg-error0 maintainers
> >to move the libraries to /lib, or is it better to stay with static linked
> >libraries?
>
> Moving libgpg-error to /lib should not be a problem at
Hi,
Jonas Meurer schrieb:
what do you think? should we ask libgcrypt11 and ligpg-error0 maintainers
to move the libraries to /lib, or is it better to stay with static linked
libraries?
Moving libgpg-error to /lib should not be a problem at all -- it's
pretty small. libgcrypt, on the other h
Hey,
in the cryptsetup package we currently link statically against libgcrypt11
and libgpg-error0. cryptdisks is run before mountall.sh, thus we cannot
depend on libraries which are are located in /usr/lib. in many systems
/usr is a seperate partition.
static linking has been a good solution in
On Fri, Dec 15, 2006 at 02:23:26PM +, Alastair McKinstry wrote:
> It looks like providing .la and pkg-config files to explain how to build
> it statically
> looks like necessary. newt doesn't ordinarily use libtool, so I need to
> generate a .la
> file and include it in the libnewt-dev. Current
Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
>
>
>> On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
>>
>>
>>> So where do people think the bug lies?
>>> - Should libdl be compiled into libnewt.a ?
>>>
>> Yes.
>>
>
> Is there even a libdl.a?
>
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
>
>> So where do people think the bug lies?
>> - Should libdl be compiled into libnewt.a ?
> Yes.
Is there even a libdl.a?
And what if I have libfoo.a libbar.a libblub.a all using dlopen?
Should
ribidi, or remove the
feature.
> - Is the bug in partimage?
The bug is trying to use static linking, which is anyway fundamentally
broken on glibc-based systems.
--
Josselin Mouette /\./\
pouet
pouet
« Sans puissance, la maîtrise n'est rien. »
On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
> So where do people think the bug lies?
> - Should libdl be compiled into libnewt.a ?
Yes.
> - Should the static version of libnewt be built differently so as to
> not call dlopen()?
Maybe.
> - if so, any recommendations on how?
Rem
Hi,
I've an interesting bug scenario sent to me by someone trying to build
partimage statically.
The partimage build is being done to make a small minimal-environment
binary (sort of boot-cd, etc.).
partimage depends on libnewt, which I maintain. libnewt-dev ships libnewt.a.
libnewt opportunistic
hello,
I want to create a static linking with qt application on linux ...so i
need some help during creation process as i dn't know about static
linking that how to create it and how appears libqt.a and libqt -mt.a
files in a lib library...
so i hope u 'll concerm my problem asap and &#
[Jason Lunz]
> I just figured out a way to do this for the ssh binary. Maybe this would
> work for you?
As others have pointed out, there is -Wl,-Bstatic and -Wl,-Bdynamic -
but even absent those, you can just refer to the .a files directly if
you wish. So instead of -Lopenbsd-compat/ -lopenbsd-
[EMAIL PROTECTED] said:
> -Wl,-static ... -Wl,-dy are equivalent and shorter :-)
Not for me, even though the ld manual claims they're the same. I have no
idea why. But the reason I went looking for a more elaborate solution
was the above not working in the first place.
Jason
--
To UNSUBSCRIBE,
Kevin B. McCarty wrote:
> Josselin Mouette wrote:
>
> > Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit :
> >> I appreciate the clarification. What is desirable, then, is for the
> >> developer
> >> to be able to statically link his or her own libraries, and third
> >> party librari
Josselin Mouette wrote:
> Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit :
>> I appreciate the clarification. What is desirable, then, is for the developer
>> to be able to statically link his or her own libraries, and third
>> party libraries,
>> but to dynamically pick up "system"
On Wed, 09 Mar 2005 21:35:56 +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit :
> > I appreciate the clarification. What is desirable, then, is for the
> > developer
> > to be able to statically link his or her own libraries, and th
On Wed, 9 Mar 2005 19:57:00 + (UTC), Jason Lunz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] said:
>
> I just figured out a way to do this for the ssh binary. Maybe this would
> work for you?
>
> Here's what I did:
>
> $ apt-get source ssh
> $ cd openssh-3.8.1p1
> $ debian/rules build
I a
Le mercredi 09 mars 2005 Ã 11:23 -0800, Blunt Jackson a Ãcrit :
> I appreciate the clarification. What is desirable, then, is for the developer
> to be able to statically link his or her own libraries, and third
> party libraries,
> but to dynamically pick up "system" libraries, of which I would nu
[EMAIL PROTECTED] said:
> I appreciate the clarification. What is desirable, then, is for the
> developer to be able to statically link his or her own libraries, and
> third party libraries, but to dynamically pick up "system" libraries,
> of which I would number libpthread. That would be adequate
will only work if
> the target system has a very similar version of libc to the one the app
> was linked with. Or they'll be ABI-incompatible and your program will
> crash. Kind of defeats the purpose of static linking.
Ah. I understand. That makes sense.
> I know this is not dire
c to the one the app
was linked with. Or they'll be ABI-incompatible and your program will
crash. Kind of defeats the purpose of static linking.
I know this is not directly related your question, but you displayed
what seemed to be a misunderstanding of the static + NSS problem, so.
signature
On Tue, 08 Mar 2005 23:55:15 +0200, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> ti, 2005-03-08 kello 13:00 -0800, Blunt Jackson kirjoitti:
> > Does anyone know if this is an intentional decision on the part of the
> > glibc/nptl crew to refuse to support static linking of the
ti, 2005-03-08 kello 13:00 -0800, Blunt Jackson kirjoitti:
> Does anyone know if this is an intentional decision on the part of the
> glibc/nptl crew to refuse to support static linking of the pthreads
> library (perhaps due to ongoing development)?
I don't know the answer to your
default... that's your only option!
Does anyone know if this is an intentional decision on the part of the
glibc/nptl crew to refuse to support static linking of the pthreads
library (perhaps due to ongoing development)? If it is a debian
decision, apparently we're in good company. Som
Yves Arrouye writes:
> I'm building a .so file for a package, which uses a library I would like
> to link statically in the .so file. I currently use something like
>
> cc -shared *.o /usr/lib/libsomelib.a -o name.so
>
> Is there a shorter way? If I use -static -lsomelib it does not work.
Hello,
I'm building a .so file for a package, which uses a library I would like
to link statically in the .so file. I currently use something like
cc -shared *.o /usr/lib/libsomelib.a -o name.so
Is there a shorter way? If I use -static -lsomelib it does not work...
On the other hand, wh
96 matches
Mail list logo
