Re: Compilation error on Solaris...
(not having really followed the thread, just chipping in on building stuff) At the moment this isn't used in all base headers (and gui still lags behind, there we only have cleaned up most of the implementation files). What I don't see is how this mechanism could have helped in your case. Agreed ... it seems to me that it is correct behavior for gui to build using the *installed* base library. When building base, base should use its own headers, not the installed ones. When building gui, gui should use its own headers, not installed ones, and so on. But gui should use the installed base headers, and back should use installed base and gui headers. That's because base, gui, and back are all separate packages. Yes. :-) Anything else introduces dependencies between the packages that make maintenance too complicated. ;-) Now, it might be nice to be able to build a core package entirely standalone without reference to installed headers, but I think that's a special case we haven't addressed ... it would presumably need a mechanism to tell gnustep-make to refrain from looking for installed headers (eg by supplying a special version of GNUstep.conf and using the environment variable to get it used instead of the default one). There would be various ways of doing this. They all involve installing "temporarily" gnustep-base somewhere locally (either using a special local GNUstep tree, or using DESTDIR), then using the locally installed gnustep-base headers. I'm not sure that it is really particularly useful ... I can't really think of a good reason why the standard procedure of compiling/installing packages separately wouldn't be good enough. You can always use a script if the problem is not wanting to type 'make / make install' multiple times :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
On 29 Apr 2010, at 08:35, Fred Kiefer wrote: > Am 28.04.2010 22:56, schrieb Gregory Casamento: >> I'm pleased to report that deleting the version of GNUstep I had at >> /usr/GNUstep cleared this problem. It's likely an issue with >> includes. It appears the code may be including the .h files from the >> installed version rather than the one we're building from when the >> installed version is available (am I describing this clearly?). >> >> I would still consider this a bug, albeit a minor one. Also, with >> the version of GCC I'm using, gcc 4.3.x, I'm getting a message about >> missing stdint.h. It's been a while since I built on Solaris, so I'm >> not sure if this is expected. > > The problem you had was with a gui file (NSGraphicsContext.m) including > a base header (NSThread.h). I think in this case of two different > libraries, although belonging to the same project, we would expect that > the installed files get used in preference over any other version. > Within the base library Richard tried to address the import issue by > changing all import in implementation files to use "" when importing > headers from the same library and started to use some #ifdef mechanism > in the headers to achieve the same there: > > #if defined(GNUSTEP_BASE_INTERNAL) > > At the moment this isn't used in all base headers (and gui still lags > behind, there we only have cleaned up most of the implementation files). > What I don't see is how this mechanism could have helped in your case. Agreed ... it seems to me that it is correct behavior for gui to build using the *installed* base library. When building base, base should use its own headers, not the installed ones. When building gui, gui should use its own headers, not installed ones, and so on. But gui should use the installed base headers, and back should use installed base and gui headers. That's because base, gui, and back are all separate packages. Now, it might be nice to be able to build a core package entirely standalone without reference to installed headers, but I think that's a special case we haven't addressed ... it would presumably need a mechanism to tell gnustep-make to refrain from looking for installed headers (eg by supplying a special version of GNUstep.conf and using the environment variable to get it used instead of the default one). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
Am 28.04.2010 22:56, schrieb Gregory Casamento: > I'm pleased to report that deleting the version of GNUstep I had at > /usr/GNUstep cleared this problem. It's likely an issue with > includes. It appears the code may be including the .h files from the > installed version rather than the one we're building from when the > installed version is available (am I describing this clearly?). > > I would still consider this a bug, albeit a minor one. Also, with > the version of GCC I'm using, gcc 4.3.x, I'm getting a message about > missing stdint.h. It's been a while since I built on Solaris, so I'm > not sure if this is expected. The problem you had was with a gui file (NSGraphicsContext.m) including a base header (NSThread.h). I think in this case of two different libraries, although belonging to the same project, we would expect that the installed files get used in preference over any other version. Within the base library Richard tried to address the import issue by changing all import in implementation files to use "" when importing headers from the same library and started to use some #ifdef mechanism in the headers to achieve the same there: #if defined(GNUSTEP_BASE_INTERNAL) At the moment this isn't used in all base headers (and gui still lags behind, there we only have cleaned up most of the implementation files). What I don't see is how this mechanism could have helped in your case. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
On Apr 28, 2010, at 2:56 PM, Gregory Casamento wrote: > I would still consider this a bug, albeit a minor one. Also, with > the version of GCC I'm using, gcc 4.3.x, I'm getting a message about > missing stdint.h. It's been a while since I built on Solaris, so I'm > not sure if this is expected. Yes I get this as well on older version of Solaris. I should probably update configure for this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
I'm pleased to report that deleting the version of GNUstep I had at /usr/GNUstep cleared this problem. It's likely an issue with includes. It appears the code may be including the .h files from the installed version rather than the one we're building from when the installed version is available (am I describing this clearly?). I would still consider this a bug, albeit a minor one. Also, with the version of GCC I'm using, gcc 4.3.x, I'm getting a message about missing stdint.h. It's been a while since I built on Solaris, so I'm not sure if this is expected. GC On Wed, Apr 28, 2010 at 12:45 PM, Gregory Casamento wrote: > I'm using the standard libobjc. Pretty much the same configuration > that I've been using on Linux. > > GC > > On Wed, Apr 28, 2010 at 11:15 AM, Adam Fedor wrote: >> >> On Apr 27, 2010, at 10:36 PM, Gregory Casamento wrote: >> >>> Compiling file NSFormCell.m ... >>> Compiling file NSGraphicsContext.m ... >>> NSGraphicsContext.m: In function 'GSCurrentContext': >>> NSGraphicsContext.m:100: warning: instance variable '_gcontext' is >>> @private; this will be a hard error in the future >>> NSGraphicsContext.m: In function '+[NSGraphicsContext setCurrentContext:]': >>> NSGraphicsContext.m:169: error: instance variable '_gcontext' is >>> declared private >>> NSGraphicsContext.m:169: error: instance variable '_gcontext' is >>> declared private >>> make[4]: *** [obj/libgnustep-gui.obj/NSGraphicsContext.m.o] Error 1 >>> >>> I'm getting this using both GCC 3.x and 4.x on Solaris. I don't seem >>> to be getting the same error on Linux. >> >> I don't have that problem on my Solaris boxes (see >> http://www.gnustep.org/developers/testfarm.html). Did you install libobjc2 >> on these machines or are you using the standard libobjc? >> >> >> >> ___ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> http://lists.gnu.org/mailman/listinfo/gnustep-dev >> > > > > -- > Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
I'm using the standard libobjc. Pretty much the same configuration that I've been using on Linux. GC On Wed, Apr 28, 2010 at 11:15 AM, Adam Fedor wrote: > > On Apr 27, 2010, at 10:36 PM, Gregory Casamento wrote: > >> Compiling file NSFormCell.m ... >> Compiling file NSGraphicsContext.m ... >> NSGraphicsContext.m: In function 'GSCurrentContext': >> NSGraphicsContext.m:100: warning: instance variable '_gcontext' is >> @private; this will be a hard error in the future >> NSGraphicsContext.m: In function '+[NSGraphicsContext setCurrentContext:]': >> NSGraphicsContext.m:169: error: instance variable '_gcontext' is >> declared private >> NSGraphicsContext.m:169: error: instance variable '_gcontext' is >> declared private >> make[4]: *** [obj/libgnustep-gui.obj/NSGraphicsContext.m.o] Error 1 >> >> I'm getting this using both GCC 3.x and 4.x on Solaris. I don't seem >> to be getting the same error on Linux. > > I don't have that problem on my Solaris boxes (see > http://www.gnustep.org/developers/testfarm.html). Did you install libobjc2 on > these machines or are you using the standard libobjc? > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
Fred, On Wed, Apr 28, 2010 at 2:55 AM, Fred Kiefer wrote: (snip) > Both of these issues sound very strange to me. Are you sure, you are using an > up to date version of the code? > Fred Yes, I'm sure. I did a revert and an update to be sure. I'm going to try to do a completely clean build to see if that helps at all. GC ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
On Apr 27, 2010, at 10:36 PM, Gregory Casamento wrote: > Compiling file NSFormCell.m ... > Compiling file NSGraphicsContext.m ... > NSGraphicsContext.m: In function 'GSCurrentContext': > NSGraphicsContext.m:100: warning: instance variable '_gcontext' is > @private; this will be a hard error in the future > NSGraphicsContext.m: In function '+[NSGraphicsContext setCurrentContext:]': > NSGraphicsContext.m:169: error: instance variable '_gcontext' is > declared private > NSGraphicsContext.m:169: error: instance variable '_gcontext' is > declared private > make[4]: *** [obj/libgnustep-gui.obj/NSGraphicsContext.m.o] Error 1 > > I'm getting this using both GCC 3.x and 4.x on Solaris. I don't seem > to be getting the same error on Linux. I don't have that problem on my Solaris boxes (see http://www.gnustep.org/developers/testfarm.html). Did you install libobjc2 on these machines or are you using the standard libobjc? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
That's an interesting problem you found here. NSGraphicsContext uses an instance variable of NSThread directly to find and set the current context. This instance variable is public, not private as your compiler claims, but it might get hidden, wen GS_EXPOSE(NSThread) is not set. One question here is why your compiler would decide to build base with hidden ivars. GS_EXPOSE is defined as: #define GS_EXPOSE(X)(!GS_NONFRAGILE || defined(EXPOSE_##X##_IVARS)) And I don't expect your gcc to support non fragile ivars. Just to make sure we could define EXPOSE_NSThread_IVARS in NSGraphicsContext before we import the header. Another question is why nobody noticed this issue before. The code in NSThread.h hasn't changed for two months at least. Both of these issues sound very strange to me. Are you sure, you are using an up to date version of the code? Fred Original-Nachricht > Datum: Wed, 28 Apr 2010 00:36:35 -0400 > Von: Gregory Casamento > An: Developer GNUstep > Betreff: Compilation error on Solaris... > Compiling file NSFormCell.m ... > Compiling file NSGraphicsContext.m ... > NSGraphicsContext.m: In function 'GSCurrentContext': > NSGraphicsContext.m:100: warning: instance variable '_gcontext' is > @private; this will be a hard error in the future > NSGraphicsContext.m: In function '+[NSGraphicsContext > setCurrentContext:]': > NSGraphicsContext.m:169: error: instance variable '_gcontext' is > declared private > NSGraphicsContext.m:169: error: instance variable '_gcontext' is > declared private > make[4]: *** [obj/libgnustep-gui.obj/NSGraphicsContext.m.o] Error 1 > > I'm getting this using both GCC 3.x and 4.x on Solaris. I don't seem > to be getting the same error on Linux. > > GC > -- > Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Compilation error on Solaris...
Compiling file NSFormCell.m ... Compiling file NSGraphicsContext.m ... NSGraphicsContext.m: In function 'GSCurrentContext': NSGraphicsContext.m:100: warning: instance variable '_gcontext' is @private; this will be a hard error in the future NSGraphicsContext.m: In function '+[NSGraphicsContext setCurrentContext:]': NSGraphicsContext.m:169: error: instance variable '_gcontext' is declared private NSGraphicsContext.m:169: error: instance variable '_gcontext' is declared private make[4]: *** [obj/libgnustep-gui.obj/NSGraphicsContext.m.o] Error 1 I'm getting this using both GCC 3.x and 4.x on Solaris. I don't seem to be getting the same error on Linux. GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
