bugGNUstep - Bugs: bug #28814, r29461 breaks building of gui on...

Group
 
 

bug #28814: r29461 breaks building of gui on Windows

Submitter:  Doug Simons <theeggcamefirst>
Submitted:  Fri 05 Feb 2010 12:30:49 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 18 Feb 2010 02:32:38 PM UTC, comment #5: 

Closing this as it's now working.

Richard Frith-Macdonald <CaS>
Group Member
Sat 06 Feb 2010 05:12:44 AM UTC, comment #4: 

Hmm... well, now that you've said the magic words (perhaps setting the status of this bug to "Works For Me" did it?) it seems to be working for me as well. I would think that I just did something wrong or got confused, but my colleague Jonathan ran into the exact same problem with exactly the same symptoms.

However, at the moment I have updated everything to an even more recent version of the trunk (r29490), done a make distclean and a make install on base, gui, and back, and everything seems to be working just fine. One factor that may be related is that we are setting the installation domain to SYSTEM, so my actual commands are:

make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM distclean
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

I don't know if that would make a difference. I also noticed on looking closer that the make_services tool and several other tools in my GNUstep/System/Tools directory don't appear to have been built recently. They all have creation dates of 2009-08-14 so I guess they are the original versions that were installed by the Windows installer package? I would have thought that the make distclean would delete them and force them to be rebuilt, but apparently not.

I will check with Jonathan later and see if this problem is persisting for him, but otherwise I guess it's a non-issue now unless you have other thoughts about what might be going on.

Doug Simons <theeggcamefirst>
Fri 05 Feb 2010 05:46:50 PM UTC, comment #3: 

I think I probably did do a clean build last time (SOP), but just to be absolutely sure, I've done 'make distclean' on base and gui, then 'svn update' on both, then 'make install' on both ... and it worked fine.

I also updated the testsuite from svn and ran the new NSOperation tests (which passed once I changed a call to sleep() which doesn't exist on windows) to confirm that the latest base library is definitely being used (if an older library was being picked up, the NSOperation tests would have failed because NSOperation was not implemented).

Please could you check that you are not accidentally usning some other copy of the library, and use gdb or some other tooo, to get a stacktrace showing the crash.

Richard Frith-Macdonald <CaS>
Group Member
Fri 05 Feb 2010 03:29:42 PM UTC, comment #2: 

Yes, I'm using the latest code from the svn trunk. The problem is definitely in the NSAutoreleasePool.m change at r29461. If I check out r29460 of that file and the latest (r29478 last night) of everything else, it builds fine.

If you didn't do a make distclean then it probably didn't delete and rebuild the make_services tool in gui, which is why your build would succeed. If you rebuild that tool you'll find that it crashes when it is run during the build process.

Doug Simons <theeggcamefirst>
Fri 05 Feb 2010 05:50:44 AM UTC, comment #1: 

Is this using up to date code from svn trunk?
I tried it and it worked fine for me.

There was a thread problem (fixed yesterday) which could cause a crash on program termination (and therefore the program termination status) on mingw.
Perhaps if the gui build process is checkign the termination status of the tools it runs, it might have decided to abort if that happened?

Richard Frith-Macdonald <CaS>
Group Member
Fri 05 Feb 2010 12:30:49 AM UTC, original submission:  

Since the changes to base committed in r29461, it's no longer possible to build gui (at least on Windows) because the make_services tool crashes during the build process. I strongly suspect the changes to NSAutoreleasePool are the source of the problem, but I don't understand the code there well enough to say what's wrong.

Could someone (Richard?) please fix the problem right away, or else roll back those changes for now? Thanks!

Doug Simons <theeggcamefirst>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by theeggcamefirst (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-02-18 CaS Open/ClosedOpen Closed
    2010-02-05 CaS StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code