| Summary: | --disable-rpath does not work | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Serge van den Boom <svdb+sdl-bugs> |
| Component: | build | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | icculus |
| Version: | HG 1.2 | Keywords: | target-1.2.14 |
| Hardware: | All | ||
| OS: | All | ||
Ignore the last part of my report. The libtool problem is unrelated; libtool expands the paths regardless of rpath usage. The --disable-rpath option affects the output of sdl-config. Should it also affect the flags passed to libtool? Why is passing -rpath to libtool a problem? I supply --disable-rpath when I don't want runtime paths to be hardcoded in my executable/library. It rather defeats the point if I'm still tied to fixed locations for SDL's dependencies, even though SDL itself can be placed anywhere. Using hardcoded runtime paths is rather controversion; Google for "rpath evil" for more the details. I personally like the freedom to move around my libraries and leave it to ldconfig to specify which ones should be used. (I have a very non-standard directory layout.) I'm not even sure it is a good idea to have rpath info in sdl-config at all, even without --disable-rpath; shouldn't it be up to the program using SDL to decide if it wants the location of SDL to be hardcoded? Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14. Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla). --ryan. Taking bug. --ryan. Fixed in svn revision #4880. --ryan. Whoops, this broke Mac OS X, so reopening the bug. --ryan. libtool relies on the -rpath parameter to know that it's building an installable library. Apparently newer versions of libtool have this requirement fixed, and we'll investigate that for SDL 1.3. I just upgraded SDL 1.2 to libtool 2.2.6a, and -rpath is still the way you tell libtool that the library is going to be installed. It won't generate an installable library if you don't pass it that option. However, upgrading libtool may have fixed your issue anyway, can you check the latest SDL snapshot? http://www.libsdl.org/tmp/SDL-1.2.zip No response from the customer, I'm closing this for now. Please re-open for SDL 1.3 if it's still an issue there. I just compiled SDL from SVN (SDL-1.2 branch), and the issue seems to be solved. Thanks Great, thanks! |
Even with --disable-rpath, RPATH information is included in the final library. This is because Makefile.in contains the line LT_LDFLAGS = -no-undefined -rpath $(DESTDIR)$(libdir) -release $(LT_RELEASE) -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) On a Solaris machine with both 32-bits and 64-bits libs, libSDL would not even build like this. (I suspect this is due to a libtool bug; when -rpath is supplied to libtool, it expands the -liconv to a full path (to the wrong lib), for whatever demonic reason)