Re: GNUstep on OpenBSD..

[Sebastian Reitenbach]

On Tuesday 14 December 2010 01:25:22 pm you wrote:
> > take a look at attached port. The gnumake package Makefiles are a bit
> > hacked up to match the constraints/requirements of the ports framework,
> > i.e. libraries need to have libPreferencesPane.so.MAJOR.MINOR, and not
> > the Linuxish symlink clutter around.
>
> Is that how things should always be done in OpenBSD ?  If so, can you just
> contribute me the patch you're using and we'll apply it to gnustep-make
> trunk ? :-)
I still have one or two issues with how my patches are working ;)
I can send you in private mail what I have, and what issues I have, maybe you 
can suggest where to change what, to make it work better, then I'd be happy if 
it could get included to gnustep-make.


>
> > However, with the port I have the following problem:
> > when I start SystemPreferences, then I see on the console the following
> > error: Error (objc-load): File not found
> > and short after that, a error message window shows up, stating the
> > following:
> >
> > Bad pane bundle at: /usr/local/lib/GNUstep/Bundles/Defaults.prefPane!
> >
> > But I have those files at the location:
> > $ ls -l /usr/local/lib/GNUstep/Bundles/Defaults.prefPane
> > total 208
> > -rwxr-xr-x  1 root  bin    102302 Dec 14 08:32 Defaults.so
>
> Is it correct to have the '.so' at the end of the bundle name ?
I need to dig into that, why it actually gets installed with the .so 
extension.

>
> > Yes, this is a known problem. The gnustep ports from the ports tree link
> > against the system libobjc. When you have installed a version from ports
> > in /usr/local/lib, then there is no way to tell GNUmake to use the
> > version in /usr/lib instead. IIRC, I discussed that with Nicola last year
> > on the Fosdem, and he said that is all fine "by design", and there is no
> > need to change that.
>
> I'm not sure I understand the situation.
>
> I'll give you some background information and hopefully that helps :-)
>
> If there are two copies of a library installed, gnustep-make will by
> default prefer the one in LOCAL to the one in SYSTEM.  It's not just for
> libobjc; it's for every library, and is due to the order of
> -L/usr/local/lib and -L/usr/lib on the linker line.
>
> The logic is that it's assumed that if you install new library in LOCAL
> when you already have one in SYSTEM, it is because you want it to be used
> instead of the one in SYSTEM. Otherwise you'd just use the SYSTEM one and
> not bother installing a new one in LOCAL ;-)
>
> Because of the fact that the library to use is controlled by the order of
> -L flags, which is the same for every library, there isn't an easy way to
> decide that you want libobjc from SYSTEM instead of LOCAL (because,
> presumably, for all other libraries you'd still want LOCAL to take
> precedence over SYSTEM; if you just always want SYSTEM to have precedence
> over LOCAL, you could just swap them in your gnustep-make configuration!).
At least for me on OpenBSD, there is only the stuff that comes with OpenBSD 
directly installed in /usr. All third party ports and software is installed in 
/usr/local. I'm not aware of anything else but gobjc where I have this 
problem.

>
> I guess one possibility that you have is to use a different version number
> for the two libobjcs, so that they can be distinguished by the linker, and
> then you can figure out which linker flag is required on OpenBSD to
> explicitly link against a library with a certain version, and configure
> gnustep-make with it.
> Eg, "./configure --with-objc-lib-flag=-l:libobjc.so.1" would cause
> gnustep-make to use -l:libobjc.so.1 instead of -lobjc to link libobjc,
> which on gnu/linux seems to work to tell the linker to pick one library
> instead of the other based on version number.  If you can't reconfigure
> gnustep-make, you can add a objc_flag.make into
> /usr/GNUstep/System/Makefiles/ with the single line OBJC_LIB_FLAG =
> -l:libobjc.so.1
> or you can set it on the command-line:
>
> make OBJC_LIB_FLAG=-l:libobjc.so.1
>
> Summarizing, I can suggest a few solutions:
>
>  * do not install an additional libobjc in LOCAL if you don't want it to be
> used ...
>
>  * or swap LOCAL and SYSTEM if you want SYSTEM to take precedence by
> default ...
>
>  * or give a different version number to the two libobjcs so they can be
> distinguished, and then find the OpenBSD linker flag to use to link against
> one instead of the other one, and configure gnustep-make with it (/use one
> of the other options above) ...
>
>  * or, install yet another libobjc in NETWORK or USER so that it has
> precedence over LOCAL (I suppose it could be a symlink to the one in SYSTEM
> ?) (this requires NETWORK to exist in the gnustep-make configuration and be
> different from LOCAL) ...
>
> I'm not sure which one (if any) makes sense in your context.
Yes, I think the first one would be fine. I wasn't aware of this --with-objc-
lib-flag to the gnustep-make configure script., Definitely worth a try, 
especially for gnustep-make from the ports.

thanks,
Sebastian

>
> Thanks