Thanks for the replies
Well it was some problem on my end.. and a simple reboot worked. Probably I
did some config changes which required a reboot.
Right now I am using just -lcurl which works fine though the /usr/local/lib
path is present in the /etc/ld.so.conf file.

On Wed, Jul 2, 2008 at 3:08 AM, Tor Arntsen <tor_at_spacetec.no> wrote:

> On Wed, Jul 2, 2008 at 11:46 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> > It is a debian thing (and a very recent debian change too): they started
> to
> > make their builds with a custom LDFLAGS settup.
> >
> > Possibly the curl way to have pkg-config and curl-config output LDFLAGS
> when
> > you ask for --libs is not very wise though, and the Debian fix for the
> issue
> > you mention seem to be to cut out LDFLAGS from the output of those two...
> >
> > I'm not yet 100% convinced that at least the curl-config change isn't
> going
> > to hurt someone.
> >
> > ... and besides (nudge nudge), we haven't seen the Debian guys submit any
> > patches for this our way...
>
> Hm.. I see a problem that I can't immediately see a way out of:
> Certainly just linking an application with -lcurl will work OK on
> Debian, as libcurl itself is linked with all those necessary
> libraries. But it won't work for our application, we create a
> dynamically loadable module (an .so) for a plugin-application. This
> module uses libcurl. When creating it with just the output from
> curl-config --libs it will fail, because for this case what works for
> applications won't work: We get missing symbols (from ssl symbols
> etc.). So right now I'm using --static-libs, but that's not optimal
> either because it uses libcurl.a, which is not something we need or
> want.
> pkg-config --libs libcurl is no help either. So right now there
> doesn't seem to be a simple way out of this, save for manually putting
> together the library list.. not optimal.
>
> If the Debian maintainer is reading this and could follow up it would be
> great..
>
> -Tor
>
Received on 2008-07-02