Re: GNUstep on OpenBSD..

[Nicola Pero]

> 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 ? :-)


> 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 ?


> 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!).

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.

Thanks