Re: [Gnustep-cvs] Commit Update

[David Ayers]

Adam Fedor wrote:
> Index: core/make/ChangeLog
> ===================================================================
> RCS file: /cvsroot/gnustep/gnustep/core/make/ChangeLog,v
> retrieving revision 1.1085
> retrieving revision 1.1087
> diff -u -r1.1085 -r1.1087
> --- core/make/ChangeLog 1 Jun 2004 14:48:02 -0000       1.1085
> +++ core/make/ChangeLog 6 Jun 2004 04:09:04 -0000       1.1087
> @@ -1,3 +1,16 @@
> +2004-06-05  Adam Fedor  <address@hidden>
> +
> +       * ld_lib_path.[c]sh: Allow seting of GNUstep framework location on
> +       Mac OS X for all library combos (patch from Quentin Mathe
> +       <address@hidden>).
> +

Well when I was in private conversation with Nicola, he was pretty much 
against this.  But if we do this here, there are also some other changes 
that should be made wrt framework handling on non-apple-apple-apple combos.

From what I understand, the current issue is that even though our 
simulated frameworks get linked via -lMyFramework and 
-Lxxx/Library/Libraries/ where symlinks (libMyFramework.dylib) into the 
xxx/Library/Frameworks/MyFramework/Current/MyFramework.dylib reside, the 
Darwin linker seems to follow the symlink and notices that it is in fact 
a framework and not a library and marks the dependency as a framework 
dependency.  Yet the loader, expecting a framework, doesn't search the 
libraries to follow the same symlinks, so the framework isn't found w/o 
the LD_FRAMEWORK_PATH at runtime.  (I maybe wrong here on some details, 
as this if from memory and I don't have Darwin to verify this again.)

I see this a temporary workaround.  We either need find a way to link 
the simulated frameworks as libraries or add more general framework 
support for non-apple-apple-apple combo within -make.  We should define 
how we want to handle frameworks in the general case.  Anyone with 
Darwin have any interest on figuring this out?

Cheers,
David