Re: Linking against a re-exported library
Re: Linking against a re-exported library
- Subject: Re: Linking against a re-exported library
- From: Kyle Sluder <email@hidden>
- Date: Tue, 31 Dec 2013 10:05:49 -0800
On Tue, Dec 31, 2013, at 01:30 AM, Ken Thomases wrote:
> On Dec 31, 2013, at 3:08 AM, Kyle Sluder wrote:
>
> > The install name for libpq.5.6.dylib is actually "libpq.5.dylib", and it
> > is configured to look for libssl and libcrypto in "@loader_path/../lib".
> > Since I can't seem to change libpq's install name, […]
>
> Why not?
…because I kept trying to use `install_name_tool -change` instead of
`install_name_tool -id`.
I presumed that the "shared library ID" referred to in the
install_name_tool(1) manpage was the library's UUID, _not_ its embedded
install name. Especially because the otool(1) man page says the -D
argument displays "just install name of a shared library."
But the quick help for `otool` and the manpage docs for the -L argument
imply that "library ID" is a synonym for "embedded install name", so I
used the `-id` argument to install_name_tool and it worked.
Now that I am no longer confused by terminology, I can theoretically
avoid re-exporting libpq.
It still feels kind of icky to do so; this would break any code that
expects _dyld_get_image_name() to return a string that begins with
"libpq". Not that I _expect_ there to be any such code, but I am
basically running with assumptions here.
>
> Why are you using @rpath-based references here? What is supplying the
> run path list at load time?
I'm not sure. It might either be the PostgreSQL.framework dylib's run
path stack, or it might be my model framework's. And the answer to this
question might be independent to the answer of what constitutes the
search path at link time.
I can't find documentation on either of these with respect to
re-exported libraries.
>
> Wouldn't @loader_path-based references work,
> since the relative path between PostgreSQL and libpq.5.6.dylib is
> constant?
You'd think, but I tried that first and that didn't work either. So I
peeked into GarageBand.app's Frameworks directory and saw they were
using @rpath, which should also work.
Armed with my improved knowledge of how install names work, I tried
using @loader_path again, and it still doesn't work:
# -- build script
EXECUTABLE_PATH="$TARGET_BUILD_DIR/$CONTENTS_FOLDER_PATH/$EXECUTABLE_NAME"
LIBPQ_PATH="$TARGET_BUILD_DIR/$CONTENTS_FOLDER_PATH/lib/libpq.5.6.dylib"
# libpq has an install name of "libpq.5.dylib" even though it is named
"libpq.5.6.dylib" and lives in the lib subdirectory of our app wrapper.
install_name_tool -id "@loader_path/../lib/libpq.5.6.dylib"
"$LIBPQ_PATH"
# Produce a wrapper dylib that re-exports libpq, with the name and
location clients of our framework expect.
ld -dylib -arch "$CURRENT_ARCH" -reexport_library "$LIBPQ_PATH" -o
"$EXECUTABLE_PATH" -install_name "$LD_DYLIB_INSTALL_NAME"
# Frameworks have a top-level symlink to the most recent version of
their executable. (Also add the lib directory, just like the Headers
directory).
ln -fs "Versions/Current/$EXECUTABLE_NAME"
"$TARGET_BUILD_DIR/$WRAPPER_NAME/$EXECUTABLE_NAME"
ln -fs "Versions/Current/lib" "$TARGET_BUILD_DIR/$WRAPPER_NAME/lib"
# -- verification
% cd PostgreSQL.framework
% otool -L PostgreSQL
PostgreSQL:
@rpath/PostgreSQL.framework/Versions/A/PostgreSQL (compatibility
version 0.0.0, current version 0.0.0)
@loader_path/../lib/libpq.5.6.dylib (compatibility version
5.0.0, current version 5.6.0)
% otool -D lib/libpq.5.6.dylib
lib/libpq.5.6.dylib:
@loader_path/../lib/libpq.5.6.dylib
# -- xcode build output from model framework target:
ld: file not found:
[...]/Build/Products/Debug/PostgreSQL.framework/../lib/libpq.5.6.dylib
for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
But this is (a little) progress, as it's not trying to find a file on
disk whose path contains "@rpath" or "@loader_path".
>
> Have you tried specifying an rpath for PostgreSQL? That is pass "-rpath
> @loader_path/../../.." to the earlier ld command for building PostgreSQL.
> Not sure if that will help, but it might.
Nope, it didn't.
--Kyle Sluder
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden