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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
