discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep on OpenBSD..


From: Sebastian Reitenbach
Subject: Re: GNUstep on OpenBSD..
Date: Wed, 15 Dec 2010 09:12:58 +0100
User-agent: KMail/1.10.3 (Linux/2.6.27.54-0.1-xen; KDE/4.1.3; x86_64; ; )

On Wednesday 15 December 2010 08:48:04 am Wolfgang Lux wrote:
> Sebastian Reitenbach wrote:
> > Hi,
> >
> > On Wednesday 15 December 2010 12:00:28 am Riccardo Mottola wrote:
> >> Hi
> >>
> >>> Now I could go and ask the old maintainer about the intention of the
> >>> patch, and if he is fine with it, to actually remove it. On the
> >>> other
> >>> side I wonder, whether SystemPreferences would work on Windows,
> >>> because
> >>> BUNDLE_OBJ_EXT is set to .dll. I guess, plmerge on Windows would
> >>> also
> >>> cause the same problem like I have seen here.
> >>> Otherwise, it probably would be save to remove all the
> >>> "NSExecutable ="
> >>> lines from the *Info.plist files that come with SystemPreferences,
> >>> since
> >>> the "NSExecutable =" line is created correctly when running make,
> >>> and
> >>> then the rest of it is merged.
> >>
> >> Don't ask how, but the current SVN trunk compiles and works on
> >> Windows!
> >
> > ok, now I'm curious, could you please send me the output of make
> > messages=yes
> > when it makes one of the modules, like I did, starting from  "Making
> > all for
> > bundle Defaults...". And also what ends up in the resulting
> > DefaultsInfo.plist, the NSExecutable with or without the .dll.
> >
> > Don't know whether this will help me to understand what's going on
> > there, but
> > who knows ;)
>
> Don't know whether this helps you, but the code happens to work under
> Windows because NSBundle contains conditional code that adds the .dll
> extension if it is not present (have a look at function
> bundle_object_name). Now you could do the same with .so for OpenBSD,
> but I doubt that this is a good idea.
Ah, thanks, I took a quick look there, and now I understand why it is working 
on Windows.

For me the Bundle binary is a shared object, and no a standalone binary. I 
cannot just run it. For me, a shared object usually has a .so extension.
So I still don't know why it is not a good idea to have .so extension for 
Bundle binaries. 
I guess there were some reasons, when it was decided how they have to look 
like, and don't want to question that, but rather understand why it is the way 
it is, since I don't see the reason, yet, and why there is an exception 
explicitly for Windows?
Maybe its just kind of historical reason, as it was done by NeXT?

thanks,
Sebastian

>
> Wolfgang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]