RE: install_name for libraries and frameworks on OS X

[Nicola Pero]

Hi Blake,

thanks for your interesting and useful comments - and good patch.  The 
patch is good, but it's a hot issue. ;-)

I'm not sure what the solution is.  I understand the obvious pros of your patch,
but there are also some cons - I'll mention some.  Ultimately we
probably just need to make it possible for each user to select their preferred
linking behaviour (probably at ./configure time), and otherwise use some 
default 
behaviour that is the least surprising / clearly warns of anything that might 
be 
surprising. :-)

Anyway, I'll throw in some food for discussion first.

--

The main problem is that the "Apple way" of hardcoding the full install path
of libraries and frameworks into the files themselves conflicts with the 
standard
way of operating of gnustep-make.  In particular, if we always do this on 
Apple, 
you get a different behaviour for gnustep-make between Apple and other 
platforms, 
which might be not be desirable ...

 1. you then have to specify the installation domain when compiling (eg, you 
have to type
'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM') and you can't change it when 
installing
(eg, you can't do 'make' then 'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM') - else 
it won't work. This would be very surprising for the average gnustep-make user
coming from another platform.  I suppose it could be acceptable, but we really 
need
to print out clear warnings on Apple. ;-)

 2. it means you can't move your library/framework from its final installation 
dir; 
this is different than what happens on all other platforms, and could make 
packaging
more difficult (packaging usually installs things into a temporary directory, 
different from the one where things will be installed for real when you install
the package) (I suppose that's not much of an issue if people are using 
whatever "Apple way" there is to package on Apple) - it can certainly be 
confusing
for users coming from another platform.  Maybe we can provide instructions on 
changing 
it after the installation.

Finally, after reading the Apple documentation on frameworks and linking, I'm no
longer sure if we need to hardcode the path after all ... it may depend on what
exactly you were trying to do :-)

I think the way it works is ...

 1. you should really install your framework either in the standard Apple 
filesystem
path (which requires no hardcoding of installation path), or bundle it with 
your 
application (which requires a custom install_name that you can set manually 
using
DYLIB_INSTALL_NAME_BASE I think)

 2. if you install it in a different ('private') location, then the 
compiler/linker
can't find it unless you pass the appropriate flags - but if you're building 
using
gnustep-make, then we do pass them when building an application - so it should 
be
possible to build applications :-).  Then the Apple documentation says that the
applications store the full path of the frameworks, so it should be possible to
then run the application even without gnustep-make and with no special flags.  
Unless we disabled storing the full path and only store a relative one ?  
That's quite possible, given our traditional dislike for hardcoding full paths. 
 
But in that case, we should probably look at the flags used when linking an 
application, and allow people/you to easily specify that they want the full 
framework paths to be stored in there ?  That might be a better fix (maybe) ?

Or maybe you were trying to distribute a framework installed in a non-standard
location, and wanted people to be able to easily link it ?

Anyway, we'll definitely make whatever you want to do possible and easy, but we
may want to have a ./configure switch to turn it on/off.

Comments welcome ;-)

Thanks for your time and help, much appreciated.  Sorry if the issue is a bit 
'hot'.


-------

I plan to apply the following patch to gnustep-make, but would like to  
see if anyone has any feedback against doing so first.  The purpose of  
this patch is to set the install_name on Mac OS X to an absolute  
(rather than relative) path for libraries and frameworks.  My reason  
for doing this is that with the current gnustep-make, if you use a  
file system layout other than apple on OS X, you will not be able to  
launch applications from the Dock.

I see 3 different possible solutions to this problem (my suggested  
patch is option 3):

1) Require any user on OS X to use the apple filesystem layout, and no  
longer set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH in GNUstep.sh  
(neither one is necessary as all libraries and frameworks are put in  
locations that are already searched when a filesystem of 'apple' is  
used).  For more info on why the apple filesystem layout works without  
setting the DYLD environment variables, see:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/DynamicLibraryUsageGuidelines.html#/
 
/apple_ref/doc/uid/TP40001928-SW12
[http://tinyurl.com/anr4m]

and also

http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html#/
 
/apple_ref/doc/uid/20002261-97184-TPXREF101
[http://tinyurl.com/eogrc]

2) Allow users of OS X to use any filesystem layout, but gnustep-make  
needs to create a ~/.MacOSX/environment.plist file to contain the same  
environment settings as are set by GNUstep.sh.  The environment.plist  
file is necessary so applications launched from the Dock will have the  
same environment (including DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH)  
as applications launched from Terminal.

3) Apply my patch so that the install_name for libraries and  
frameworks is absolute, rather than relative.  This is by far the most  
common way it is done on OS X 10.4 and 10.5 (I'm not sure about  
earlier versions of the OS).  In fact, I do not know of any public  
libraries or frameworks that do it any other way.

Note that my patch does not prevent the use of  
GNUSTEP_INSTALLATION_DOMAIN.  The person building the library or  
framework can still specify the domain and the install_name will be  
set appropriately.

Please let me know if you see any problems with my patch or if you  
recommend any adjustments to it.  I am far from a gnustep-make master,  
and appreciate any suggestions others may have.


Thanks,
Blake


Index: Instance/library.make
===================================================================
--- Instance/library.make       (revision 26514)
+++ Instance/library.make       (working copy)
@@ -236,9 +236,15 @@
  LIB_LINK_VERSION_FILE = $(VERSION_LIBRARY_FILE)
  LIB_LINK_SONAME_FILE = $(SONAME_LIBRARY_FILE)
  LIB_LINK_FILE = $(LIBRARY_FILE)
-LIB_LINK_INSTALL_NAME = $(SONAME_LIBRARY_FILE)
  LIB_LINK_INSTALL_DIR = $(FINAL_LIBRARY_INSTALL_DIR)

+ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
+  # On Mac OS X, set install_name to the absolute path to the library
+  LIB_LINK_INSTALL_NAME = $(LIB_LINK_INSTALL_DIR)/$ 
(SONAME_LIBRARY_FILE)
+else
+  LIB_LINK_INSTALL_NAME = $(SONAME_LIBRARY_FILE)
+endif
+
  #
  # Internal targets
  #
Index: Instance/framework.make
===================================================================
--- Instance/framework.make     (revision 26514)
+++ Instance/framework.make     (working copy)
@@ -307,8 +307,13 @@
  ifneq ($(DYLIB_INSTALL_NAME_BASE),)
    LIB_LINK_INSTALL_NAME = $(DYLIB_INSTALL_NAME_BASE)/$ 
(FRAMEWORK_FILE_NAME)
  else
-  # Use a relative path for easy relocation.
-  LIB_LINK_INSTALL_NAME = $(GNUSTEP_INSTANCE).framework/$ 
(GNUSTEP_INSTANCE)
+  ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
+    # On Mac OS X, set install_name to the absolute path to the  
framework
+    LIB_LINK_INSTALL_NAME = $(LIB_LINK_INSTALL_DIR)/$(GNUSTEP_INSTANCE)
+  else
+    # Use a relative path for easy relocation.
+    LIB_LINK_INSTALL_NAME = $(GNUSTEP_INSTANCE).framework/$ 
(GNUSTEP_INSTANCE)
+  endif
  endif





_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev