We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 531

Summary: sdl.pc should define Libs.private
Product: SDL Reporter: Mike Frysinger <vapier>
Component: buildAssignee: Mike Frysinger <vapier>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 1.2   
Hardware: x86   
OS: All   

Description Mike Frysinger 2007-12-29 16:50:46 UTC
after looking through the configure.in file, i think SDL_LIBS should just be straight up deleted

then sdl.pc.in should be written as:
Libs: -L${libdir} @SDL_RLD_FLAGS@ -lSDL
Libs.private: @EXTRA_LDFLAGS@

what this means is that when people want to do normal dynamic linking:
pkg-config sdl --libs
they'll get the normal -L/path/ and the -lSDL which is all they'd need

then when they want to do static linking:
pkg-config sdl --libs --static
they'd get the proper full list of all the libraries libsdl actually links against.  currently, you'll probably get a build failure as many of the libraries that libsdl uses do not get listed.
Comment 1 Sam Lantinga 2007-12-29 17:18:17 UTC
SDL_LIBS is everything that an application needs to link dynamically with SDL.
SDL_STATIC_LIBS is everything that an application needs to link statically with SDL.

... at least, in theory.

If you look at sdl-config.in, that's the way it's supposed to work.
Comment 2 Mike Frysinger 2007-12-30 00:18:02 UTC
on my system, -lpthread is added to SDL_LIBS ... not sure why, but when linking dynamically, it shouldnt be needed

also on my system, SDL_STATIC_LIBS lacks a lot of libraries that are in EXTRA_LDFLAGS ... for example, it does not have -lm -ldl -ldirectfb

is there ever a case where -lSDL would not be sufficient for dynamic linking ?  in other words, i dont think having SDL_LIBS built up in configure is needed ... just hardcode the value in the .pc/-config script

seems like EXTRA_LDFLAGS and SDL_STATIC_LIBS have duplicated meaning ... so perhaps they could just get unified ?
Comment 3 Sam Lantinga 2007-12-30 03:04:25 UTC
Yes, if you look at the cases where things are added to SDL_LIBS, they are always things that are needed by applications that are linking to SDL.

In the case of pthread, it is needed at ld.so shared object resolution because a multi-threaded program and a single-threaded program had slightly different object binding initialization.  This is probably no longer the case, but it was at one time, and doesn't hurt.

EXTRA_LDFLAGS and SDL_STATIC_LIBS may be redundant, but I think there are other things besides libraries in EXTRA_LDFLAGS that are used for linking the shared object.  I'd have to check.
Comment 4 Mike Frysinger 2007-12-30 10:16:11 UTC
does that mean you'll take care of fixing SDL_STATIC_LIBC and adding it to sdl.pc or do i need to post a patch ? :)
Comment 5 Sam Lantinga 2007-12-30 11:46:12 UTC
Go ahead and submit a patch, since I don't have any way of testing it at the moment.

Thanks!
Comment 6 Mike Frysinger 2008-01-01 05:19:25 UTC
when i look through configure.in, i dont see any flags added to EXTRA_LDFLAGS that shouldnt be added to the static lib list

grep EXTRA_LDFLAGS configure.in

for OS X at least, they're already adding EXTRA_LDFLAGS to SDL_STATIC_LIBS ...
Comment 7 Sam Lantinga 2008-01-01 07:25:27 UTC
Sounds fair to me.

This is fixed with revision 3511.  Thanks!