Re: Core release, Wed
On 2005-07-18 15:25:36 +0100 Adam Fedor <[EMAIL PROTECTED]> wrote: I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. Well ...I have nothing very concrete but ... I'm dubious about the recent make packagechange to when the objc library is linked into things (the one which seems to have caused problems on bsd). The reason I'm worried is that, on a couple of production machines I wanted to make local bugfix updates to part of my software, and (for no very good reason ... I just like to keep things up to date) I updated the make package on these machines before recompiling my patched code. Upon relinking I got a load of errors about undefined symbols from the runtime library ... but upon reverting to the earlier make package I was able to build without problems. I haven't investigated in any depth ... partly lack of time, partly because I don't want to tinker too much with live production systems running customer-facing services. The linkage problems may well be something wrong in my makefiles which the make system was masking and is not masking any more, but it may be the case that the make package really should link every tool/app with -lobjc evn though it has already linked the base library with it, I'm just not sure - I find the rules about dynamic libraries confusing. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Wed Jul 20 06:34:09 EDT 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Wed Jul 20 03:58:20 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Wed Jul 20 03:25:45 MDT 2005 Success Compile sparc-sun-solaris2.7 Wed Jul 20 02:08:59 EDT 2005
Re: Core release, Wed
> > I'm mostly satisfied with the libraries now, which is to say, I don't > > really > > have any time to make any significant changes. So I'll plan on freezing the > > release this Wednesday. Unless there are any objections. > > Well ...I have nothing very concrete but ... I'm dubious about the recent > make packagechange to when the objc library is linked into things (the one > which seems to have caused problems on bsd). > > The reason I'm worried is that, on a couple of production machines I wanted > to make local bugfix updates to part of my software, and (for no very good > reason ... I just like to keep things up to date) I updated the make package > on these machines before recompiling my patched code. Upon relinking I got > a load of errors about undefined symbols from the runtime library ... but > upon reverting to the earlier make package I was able to build without > problems. > > I haven't investigated in any depth ... partly lack of time, partly because > I don't want to tinker too much with live production systems running > customer-facing services. The linkage problems may well be something wrong > in my makefiles which the make system was masking and is not masking any > more, but it may be the case that the make package really should link every > tool/app with -lobjc evn though it has already linked the base library with > it, I'm just not sure - I find the rules about dynamic libraries confusing. Thanks - yes, I had exactly that same problem on my office workstation. :-) I believe the problem is that if you switch to the new -make package, you have to recompile everything from scratch (which I didn't, I reverted to the old gnustep-make as you did). :-( My understanding is that before the change, we linked a tool against -lgnustep-base and -lobjc. gnustep-base itself was not linked against libobjc. After the change, we now link a tool just against -lgnustep-base. gnustep-base itself is now linked to libobjc. So if your gnustep-base was built with the old gnustep-make, but you're using the new gnustep-make to link a tool, libobjc is not linked into gnustep-base (old building style), and will not be linked into the tool (new building style), so you get undefined symbols because libobjc is never linked. Rebuilding only gnustep-base might be enough to fix the problem ... I'd still rebuild everything just to be sure. This makes upgrades a bit cumbersome as you have to upgrade everything, but well that's why we're making a major release I suppose. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
Adam, --- Adam Fedor <[EMAIL PROTECTED]> wrote: > I'm mostly satisfied with the libraries now, which is to say, I don't > really have any time to make any significant changes. So I'll plan on > freezing the release this Wednesday. Unless there are any objections. > There is a memory leak in NSWindowController which I'd like to fix before the release. The class should, per specs, release all of the top level objects in the nib/gorm it loads when it is released. It currently doesn't do that. > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
On Jul 20, 2005, at 6:14 AM, Nicola Pero wrote: I believe the problem is that if you switch to the new -make package, you have to recompile everything from scratch (which I didn't, I reverted to the old gnustep-make as you did). :-( My understanding is that before the change, we linked a tool against -lgnustep-base and -lobjc. gnustep-base itself was not linked against libobjc. After the change, we now link a tool just against -lgnustep-base. gnustep-base itself is now linked to libobjc. So if your gnustep-base was built with the old gnustep-make, but you're using the new gnustep-make to link a tool, libobjc is not linked into gnustep-base (old building style), and will not be linked into the tool (new building style), so you get undefined symbols because libobjc is never linked. Rebuilding only gnustep-base might be enough to fix the problem ... I'd still rebuild everything just to be sure. This makes upgrades a bit cumbersome as you have to upgrade everything, but well that's why we're making a major release I suppose. ;-) Well, I can revert the make part of the patch. It shouldn't be a problem to have lobjc linked multiple times. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep make patch take 1
Thanks Jeremy, good patch! :-) Adam is doing a release today (I think), so I didn't want to make too many changes [in case I break more than I fix ;-)]; I've committed the fix for frameworks with subprojects on mingw32 though. I'll work on the other changes after the release ... I suspect Adam will make a minor bugfix release quite soon, so those will get into the minor bugfix release. :-) Thanks! > I have the vague feeling that I should be sending these to the patch tracker > on savannah, but here we are: > > Thanks for the windows changes in CVS, I have a few more things that I > changed to make things go: This patch is relative to CVS as of about 20 > minutes ago. > > * configure: Need to use install -p instead of install, so that make doesn't > rebuild frameworks everytime due to header copies. > * configure.ac: Same change > * rules.make: Don't create the obj symlink (we have no symlinks and it > leaves a useless empty dir) > * target.make: add -Wl,--export-all-symbols to SHARED_LIB_LINK_CMD, so that > ld will export all symbols even if the code uses __declspec(dllexport) > extern. See > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html > for more info. Also add -Wl,--enable-auto-import to ADDITIONAL_LDFLAGS to > shut up a linker warning. > * which_lib.c: when searching for _d _p stuff, on windows look for > FOO_d.dll, then libFOO_d.dll.a, then libFOO_d.a, since that is the same > sequence that ld will use when linking. > * Instance/framework.make: I changed the build-headers code to be faster, > because I have > 209 public headers in my framework, and the old makefile was doing 209*209 > copies. Changed the $(FRAMEWORK_FILE) target to NOT $(LN_S) the files to > the framework dir unless the link actually succeeded. > * Instance/subproject.make: Make build-headers faster. > * Master/rules.make: Changed subproject to reflect changes to framework.make > wrt Versions dir. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/make ChangeLog config.make.in Inst...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/07/20 16:00:07 Modified files: core/make : ChangeLog config.make.in core/make/Instance: framework.make core/make/Master: rules.make Log message: Fixed building frameworks with subprojects on Windows CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1157&tr2=1.1158&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/config.make.in.diff?tr1=1.63&tr2=1.64&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/Instance/framework.make.diff?tr1=1.68&tr2=1.69&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/Master/rules.make.diff?tr1=1.33&tr2=1.34&r1=text&r2=text
Re: Core release, Wed
> > This makes upgrades a bit cumbersome as you have to upgrade everything, > > but well that's why we're making a major release I suppose. ;-) > > > > Well, I can revert the make part of the patch. It shouldn't be a > problem to have lobjc linked multiple times. My personal suggestion would be to leave the change in, but add a clear explanation (that you need to recompile everything) in the release notes. Eg, taking us (Brainstorm/Opera Telecom) as an example, ordinately rebuilding all software on our live systems when we do our next upgrade should not be too much of a problem ... the important thing is that we know we have to do it! :-) I'm happy with any other solution (including reverting the make part of the patch), I don't think it is particularly important -- the most important thing is having a clear understanding of what is needed to upgrade without problems, and communicating it to users. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GCC 4.x and ObjC/ObjC++ type encodings
Ziemowit Laski wrote: > As some of you may have noticed, the Objective-C method signature, > instance variable and type encodings (including @encode expressions) > have changed between GCC 3.X and GCC 4.X series of compilers. The GCC > 4.X implementation, although suffering from a couple of bugs, is > nevertheless an improvement over the previous schemes in that it is > more orthogonal, and handles ObjC qualifiers (e.g., 'bycopy', > 'inout') in a more canonical fashion (though further improvements are > certainly possible). > Thing is, it turns out that this encoding rewrite has caused quite a > bit of pain in the Apple/Darwin world :-(. As a result, I'm presently > working on a patch (which will go into apple-local-200502-branch for > now) that will make GCC 4.X encodings match (to the extent possible) > what Apple's GCC 3.3 did. This is neither pretty nor intellectually > satisfying, but is nonetheless necessary to preserve > release-to-release binary compatibility for the NeXT runtime. > However, this requirement may or may not hold for the _GNU_ runtime, > which is why I'm writing this e-mail. Have folks in the GNU ObjC > world experienced problems with the encoding changes between GCC 4.x > and earlier versions? Would it be OK for the GNU runtime to go back > to GCC 3.x encodings? (Doing so would clearly be easier for me :-) ). > If not, could someone come up with a collection of > GNU-runtime-specific test cases that capture what the desired GNU > encodings are, so that I don't break you guys once I start > integrating my encoding changes back into mainline in the future? I think it would be great it we had some clarification on the intended semantics of the encoding schemes. To do that we should look at a) in FSF GCC 3.3 b) in FSF GCC 3.4 c) in FSF GCC 4.0 d) and define what we really want (I don't think that there was intended change wrt encoding/message signatures between b-c but I think the logs showed an ordering issue wrt bycopy out.) I'm not sure about the apple runtime but for the GNU runtime the method signature version a) included platform specific information on argument/return values wrt the calling conventions on that platform. (PS: I think you needed a non-x86 platform like SPARC to actually see the extra notation.) b) already included the change you are referring to in: c) in which this information is not generated anymore. (There may have not been a GCC 3.4 from Apple which explains why you only mention 3.3 and 4.0.) But I'm not clear about what the intended changes were other than the one you have mentioned (i.e. handle qualifiers like (oneway, in, out, inout, bycopy, byref). More specifically, what do you mean by: - more orthogonal - more canonical fashion And what which part do you intend to revert, the qualifiers? I've started on some test cases but beware they are WIP and I still yet have to figure out how to make them portable as signatures are platform dependent. We (GNUstep) used to use the information provided by the method signature do help us implement forwarding and possibly DO but currently rely on libffi/ffcall. I suppose that is the reason that GCC 3.4 did not cause great breakage wrt GNUstep. Yet we did have fallout on architectures like NetBSD on SPARC in some of our signature validation code. For reference I've attached not only the test cases but some log files for: i686-pc-linux-gnu FSF GCC 3.3.6 i686-pc-linux-gnu FSF GCC 3.4.4 i686-pc-linux-gnu FSF GCC 4.0.1 sparc-sun-solaris2.7 FSF GCC 3.4.2 Cheers, David enc_sig.tar.gz Description: GNU Zip compressed data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog Palettes/1Windo...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento <[EMAIL PROTECTED]> 05/07/21 03:34:04 Modified files: dev-apps/Gorm : ChangeLog dev-apps/Gorm/Palettes/1Windows: GormNSPanel.m GormNSWindow.m Log message: Reverted previous change, it had some unintended side effects. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.720&tr2=1.721&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/1Windows/GormNSPanel.m.diff?tr1=1.12&tr2=1.13&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/1Windows/GormNSWindow.m.diff?tr1=1.16&tr2=1.17&r1=text&r2=text
