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

Fix comment here as well

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/trunk@21112 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Adam Fedor 2005-04-15 22:50:11 +00:00
parent 149d63b6b1
commit 662c048e3e
2 changed files with 19 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
ChangeLog
View file

@ -1,7 +1,7 @@
2005-04-15 Adam Fedor <fedor@gnu.org>
* Instance/framework.make: Add top-level symlink for all darwin
* ld_lib_path.sh: Clarify framework comment.
* ld_lib_path.[c]sh: Clarify framework comment.
* Documentation/machines.texi: Update
* Documentation/README.NetBSD: Remove, obsolete.

36
ld_lib_path.csh
View file

@ -85,25 +85,25 @@ switch ( "${host_os}" )
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.
# Frameworks in GNUstep-make are supported by creating a link like
#
# Libraries/libMyFramework.dylib ->
# Frameworks/MyFramework.framework/Versions/Current/libMyFramework.dylib,
#
#    if ( ( "${LIBRARY_COMBO}" == "apple-apple-apple" ) \ 
#         || ( "${LIBRARY_COMBO}" == "apple") ) then
# to mitigate the fact that FSF GCC does not support a -framework flag.
#
# On Darwin, however, we partially emulate -framework by setting the
# "install_name" to the framework name during linking. The dynamic
# linker (dyld) is smart enough to find the framework under this name,
# but only if DYLD_FRAMEWORK_PATH is set (unless we set the
# "install_name" to an absolute path, which we don't). We'd really like
# to fully support -framework, though.
#
# Use otool -L MyApplication.app/MyApplication, for instance, to see
# how the shared libraries/frameworks are linked.
#
# if [ "$LIBRARY_COMBO" = "apple-apple-apple" -o \
# "$LIBRARY_COMBO" = "apple" ]; then
unset additional