Re: install_name for libraries and frameworks on OS X

[Nicola Pero]

Blake,

yes I like your option 1. as the general option to give to the 'average' user
because it really should work well if the user just wants "something that
works".  Things will work 'out of the box' with no intervention, will install 
straight into the Apple recommended locations, and work consistently with 
the way that gnustep-make works on all other platforms. :-)


> I think it would be wise to add some checking to  
> configure for gnustep-make that verifies that a user on OS X uses the  
> apple layout.  Should attempting to use a different layout produce an  
> error or simply a warning?

Definitely a warning - some people will definitely find a useful use
for a different layout and will know enough to get around to have it
working ;-)

In fact I also liked your option of hardcoding the full path - for the more
experienced users who know what they are doing - what about having
a ./configure flag to turn that behaviour on and off ?  Or maybe a make
option (make full_install_name=yes ?)

Thanks


-----Original Message-----
From: Blake Nicholson <address@hidden>
Sent: Tuesday, 13 May, 2008 20:41
To: address@hidden
Cc: address@hidden
Subject: Re: install_name for libraries and frameworks on OS X

Hi Nicola,

Thank you for the extensive feedback.  It appears to me that your  
suggestion is that we go with what I described as option 1 (tell users  
on OS X they need to use the apple filesystem).  This is a reasonable  
solution to me.  I think it would be wise to add some checking to  
configure for gnustep-make that verifies that a user on OS X uses the  
apple layout.  Should attempting to use a different layout produce an  
error or simply a warning?


Thanks,
Blake


On May 13, 2008, at 3:18 AM, Nicola Pero wrote:
> 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
>
>
>
>