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

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

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

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

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

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

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

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 14 Apr 12

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 header files

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