Re: static linking and opportunistic dynamic linking problem

2006-12-16 Thread Steve Langasek
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

Re: static linking and opportunistic dynamic linking problem

2006-12-15 Thread Alastair McKinstry
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? >

Re: static linking and opportunistic dynamic linking problem

2006-12-15 Thread Goswin von Brederlow
[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

Re: static linking and opportunistic dynamic linking problem

2006-12-14 Thread Josselin Mouette
Le jeudi 14 décembre 2006 à 11:56 +, Alastair McKinstry a écrit : > partimage depends on libnewt, which I maintain. libnewt-dev ships libnewt.a. > libnewt opportunistically links to libfribidi if it is present; it uses > dlopen() to do so. > > However the partimage build fails when done with '

Re: static linking and opportunistic dynamic linking problem

2006-12-14 Thread Marco d'Itri
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

static linking and opportunistic dynamic linking problem

2006-12-14 Thread Alastair McKinstry
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

Re: linking problem

1998-04-13 Thread jdassen
On Mon, Apr 13, 1998 at 09:32:12AM -0400, Alex Yukhimets wrote: > I also had a very similar problem with -lXt, the only difference is that I > used altgcc for compilation. Btw, what is the prefered way to use it? I don't think there's just one right way to use it. Personally, I'd try something li

Re: linking problem

1998-04-13 Thread Alex Yukhimets
> > if i replace -lXpm by /usr/X11R6/lib/libXpm.so.4 the program links > > fine. does anybody have any idea what's going on here? > > "ld" only looks for libXpm.so, not for libXpm.so.version. In Debian, > libfoo.so is part of the libfoo-dev package, not of the libfoo package, as > you need the hea

Re: linking problem

1998-04-13 Thread jdassen
On Sun, Apr 12, 1998 at 11:07:02PM -0500, Alex Romosan wrote: > and the error: > > /usr/bin/ld: cannot open -lXpm: No such file or directory > collect2: ld returned 1 exit status > > but the library exists: > > ls -l /usr/X11R6/lib/libXpm.so.4* >0 lrwxrwxrwx 1 root root 1

linking problem

1998-04-13 Thread Alex Romosan
i've run into a really strange problem, and i can't seem to figure it out. i am attempting to link a program against Xpm and the linker tells me it can't find it. this is the command: g77 evtdsp_main.o xencode.o ../e815_analysis/dst/ftio.o getolevent.o \ getoesevent.o getofsevent.o sigonline.