[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/
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
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
[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,
[Blunt Jackson]
I am familiar with the nss issue, although that's not really relevant
to this question. The nss issue, and the related question in the FAQ
is that when statically linking to libc, there are still dynamic
loads required -- but libc handles this for the application.
(Presumably
On Wed, 9 Mar 2005 05:00:52 -0600, Peter Samuelson [EMAIL PROTECTED] wrote:
Yes, dlopen, but the problem is version skew. With a dynamic libc6,
libc and the NSS modules will always be compatible. With a static
libc6, NSS functions (gethostbyname, getpwuid, etc.) will only work if
the
[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
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
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
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
I discovered with some surprise that the 2.6 kernel does not come with
an archive version
of the NPTL pthreads library (ie., no libpthread.a). So, while
dynamically linked applications will link against NPTL by default,
building a statically linked application will not only link to
LinuxThreads by
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,
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
13 matches
Mail list logo
