Bug#1067819: ITP: linksem -- Semantic model for aspects of ELF static linking and DWARF debug information

: 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

static linking, modularity, and community (was: Proposal for how to deal with Go/Rust/etc security bugs)

e 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 may lose time while it politely waits for their upstream to check

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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.

Lua [Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)]

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

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

Re: static linking

❦ 19 mai 2015 09:30 +0800, Paul Wise p...@debian.org : 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

Re: static linking

Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise p...@debian.org 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 linking. https

Re: static linking

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 belong

Re: static linking

* 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. https://wiki.debian.org/StaticLinking

Re: static linking

* 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-Using

Re: static linking

On 19/05/2015 07:43, Bastien Roucaries wrote: Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise p...@debian.org 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

Re: static linking

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 situation

Re: static linking

-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 libc/libdrm/libx11

static linking

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 extend

Re: Bug#757941: static linking: alternatives for glibc?

), 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 dynamic loading from static libc is supported. When a statically linked app calls getaddrinfo

Re: Bug#757941: static linking: alternatives for glibc?

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

Re: Bug#757941: static linking: alternatives for glibc?

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-requ...@lists.debian.org with a subject

Re: Bug#757941: static linking: alternatives for glibc?

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 in from gcc

static linking: alternatives for glibc?

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

Re: static linking: alternatives for glibc?

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

Re: static linking: alternatives for glibc?

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...@debian.org) http://www.eyrie.org

Re: static linking: alternatives for glibc?

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 expected to work when the corresponding NSS modules are present. It's not truly static

Re: Bug#757941: static linking: alternatives for glibc?

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 getaddrinfo() (it is getnameinfo not gethostbyname), the call

Re: raising an issue about static linking policy

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's not clear which applications are all

raising an issue about static linking policy

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

Re: raising an issue about static linking policy

On Thu, Aug 28, 2014 at 5:38 PM, Salvo Tomaselli tipos...@tiscali.it 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:

Re: raising an issue about static linking policy

. Maybe he should check how many copies of that he has open. - Static linking is a security nightmare, as are embedded copies of libraries. It creates additional work and it's not clear which applications are all affected. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ

Re: Static linking: pkgconfig vs libtool

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

Re: Static linking: pkgconfig vs libtool

On 19.11.2010 22:51, Russ Allbery wrote: Dmitry Katsubo dm...@mail.ru 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

Re: Static linking: pkgconfig vs libtool

On Mon, 22 Nov 2010 at 16:18:52 +0100, Dmitry Katsubo wrote: On 19.11.2010 22:51, Russ Allbery wrote: Dmitry Katsubo dm...@mail.ru 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)

Re: Static linking: pkgconfig vs libtool

Dmitry Katsubo dm...@mail.ru 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

Re: Static linking: pkgconfig vs libtool

]] 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 practices

Re: Static linking: pkgconfig vs libtool

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'm a

Re: Static linking: pkgconfig vs libtool

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

Re: Static linking: pkgconfig vs libtool

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

Static linking: pkgconfig vs libtool

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 libtool (which consumes the information from *.la) and with pkg-config (which consumes the information from *.pc). The problems I faced

Re: Static linking: pkgconfig vs libtool

Dmitry Katsubo dm...@mail.ru 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 libtool

Re: Confused by .la file removal vs static linking support

Zitat von Josselin Mouette j...@debian.org: 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

Re: Confused by .la file removal vs static linking support

Hendrik Sattler, le Wed 05 May 2010 10:47:24 +0200, a écrit : Zitat von Josselin Mouette j...@debian.org: 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

Re: Confused by .la file removal vs static linking support

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

Re: Confused by .la file removal vs static linking support

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

Re: Confused by .la file removal vs static linking support

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'll

Re: Confused by .la file removal vs static linking support

]] Paul Wise | On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen tfh...@err.no 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?

Re: Confused by .la file removal vs static linking support

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 gtk/gtk.h you’re able

Re: Confused by .la file removal vs static linking support

Josselin Mouette j...@debian.org 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

Re: Confused by .la file removal vs static linking support

]] 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 is

Re: Confused by .la file removal vs static linking support

On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen tfh...@err.no 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

Confused by .la file removal vs static linking support

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 mentioned in dependency_libs

Re: Confused by .la file removal vs static linking support

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 might happen that we come to the conclusion that we need to keep a few la

Re: Confused by .la file removal vs static linking support

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 right libs. Cheers, Julien signature.asc Description

Re: Confused by .la file removal vs static linking support

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 right libs. This does not clarify the question

Re: Confused by .la file removal vs static linking support

* Nikita V. Youshchenko yo...@debian.org [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

Re: Confused by .la file removal vs static linking support

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?) Static linking is resolved by providing a foo.pc file so that pkg-config --static --libs foo is all

Re: Confused by .la file removal vs static linking support

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 specific cases

Re: Confused by .la file removal vs static linking support

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 [1] over many years: one

Re: Confused by .la file removal vs static linking support

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?) Static linking is resolved by providing a foo.pc file so that pkg-config --static

Re: Confused by .la file removal vs static linking support

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

Re: Confused by .la file removal vs static linking support

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 much larger .a files?) Static

Re: Confused by .la file removal vs static linking support

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 question about dependences. It does, because foo.pc won't work without its dependencies installed

Re: Confused by .la file removal vs static linking support

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 the right libs. This does not clarify the question about dependences

Re: Confused by .la file removal vs static linking support

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 other

Re: Confused by .la file removal vs static linking support

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 library

Tradeoffs of static linking (Re: Changes in dpkg Pre-Depends)

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

Re: libgpg-error0 and libgcrypt11: static linking or move from /usr/lib to /lib?

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

Re: libgpg-error0 and libgcrypt11: static linking or move from /usr/lib to /lib?

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

Re: static linking and opportunistic dynamic linking problem

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

Re: static linking and opportunistic dynamic linking problem

[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 they all

Re: static linking and opportunistic dynamic linking problem

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? Yes, but its fairly

static linking and opportunistic dynamic linking problem

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

Re: static linking and opportunistic dynamic linking problem

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

Re: static linking and opportunistic dynamic linking problem

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

problem(static linking)

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 'll reply me

Re: NPTL and static linking

[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/

Re: NPTL and static linking

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

Re: NPTL and static linking

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 libraries, but to

Re: NPTL and static linking

[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,

Re: NPTL and static linking

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.asc Description: Digital

Re: NPTL and static linking

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 directly related your question, but you displayed

Re: NPTL and static linking

[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 for

Re: NPTL and static linking

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 number

Re: NPTL and static linking

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 appreciate

Re: NPTL and static linking

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 third

NPTL and static linking

by 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. Some research

Re: NPTL and static linking

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 exact question

Re: NPTL and static linking

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 pthreads library (perhaps

How to force static linking of some libs when using -shared?

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,

Re: How to force static linking of some libs when using -shared?

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