gnustep/tools-make
0
0
Fork 0
mirror of https://github.com/gnustep/tools-make.git synced 2025-04-23 22:33:28 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Added comments on DYLD_FRAMEWORK_PATH support under Darwin

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/trunk@19916 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Quentin Mathe 2004-08-24 16:46:08 +00:00
parent b9af85c3c4
commit 6eda8c8c9e
3 changed files with 51 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
ChangeLog
View file

@ -1,3 +1,11 @@
2004-08-24 Quentin Mathe <qmathe@club-internet.fr>
* ld_lib_path.sh:
* ld_lib_path.csh:
Added comments to explain why we set DYLD_FRAMEWORK_PATH on Darwin with
any library combo and not just apple-apple-apple (it is a temporary
solution).
2004-08-24 Adam Fedor <fedor@gnu.org>
* GNUstep.sh.in: Add newline at end of file (avoids bug in Solaris

21
ld_lib_path.csh
View file

@ -83,6 +83,27 @@ switch ( "${host_os}" )
setenv DYLD_LIBRARY_PATH="${additional}${DYLD_LIBRARY_PATH}"
endif
endif
# The code below has been temporarily removed, because...
# With GNUstep -make on any platform, when you compile a
# framework, it is supported by creating a link like
# Librairies/libMyFramework.dylib ->
# Frameworks/MyFramework.framework/Versions/Current/libMyFramework.dylib, to
# mitigate the fact that FSF GCC supports to link frameworks with the -frameworks
# flag only on Darwin .
# Well concerning library GNUstep -make on Darwin, the problem lies in the fact
# the Darwin linker seems to be unable to link the library when you pass the
# flag -lMyFramework to compile an application which depends on it, strangely it
# links the framework directly. You can see that with otool -L
# Whatever/MyApplication.app/MyApplication which will output
# MyFramework.framework/MyFramework and not libMyFramework.dylib .
# So because a framework is linked when it is present even when you want to
# link the equivalent library, the application will not find the framework when
# you launch it with DYLD_FRAMEWORK_PATH empty. To correct that, we must
# set DYLD_FRAMEWORK_PATH in any cases until the Darwin linker behaves correctly.
#
#    if ( ( "${LIBRARY_COMBO}" == "apple-apple-apple" ) \ 
#         || ( "${LIBRARY_COMBO}" == "apple") ) then
unset additional

22
ld_lib_path.sh
View file

@ -131,6 +131,28 @@ case "$host_os" in
fi
fi
export DYLD_LIBRARY_PATH
# The code below has been temporarily removed, because...
# With GNUstep -make on any platform, when you compile a
# framework, it is supported by creating a link like
# Librairies/libMyFramework.dylib ->
# Frameworks/MyFramework.framework/Versions/Current/libMyFramework.dylib, to
# mitigate the fact that FSF GCC supports to link frameworks with the -frameworks
# flag only on Darwin .
# Well concerning library GNUstep -make on Darwin, the problem lies in the fact
# the Darwin linker seems to be unable to link the library when you pass the
# flag -lMyFramework to compile an application which depends on it, strangely it
# links the framework directly. You can see that with otool -L
# Whatever/MyApplication.app/MyApplication which will output
# MyFramework.framework/MyFramework and not libMyFramework.dylib .
# So because a framework is linked when it is present even when you want to
# link the equivalent library, the application will not find the framework when
# you launch it with DYLD_FRAMEWORK_PATH empty. To correct that, we must
# set DYLD_FRAMEWORK_PATH in any cases until the Darwin linker behaves correctly.
#
# if [ "$LIBRARY_COMBO" = "apple-apple-apple" -o \
#      "$LIBRARY_COMBO" = "apple" ]; then
if [ -z "$DYLD_FRAMEWORK_PATH" ]; then
DYLD_FRAMEWORK_PATH="$fw_paths"
else