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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #28814: r29461 breaks building of gui on Windows

Submitted by:  Doug Simons <theeggcamefirst>
Submitted on:  Fri 05 Feb 2010 12:30:49 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Works For Me
Privacy: PublicAssigned to: None
Open/Closed: Closed

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

Closing this as it's now working.

Richard Frith-Macdonald <CaS>
Project 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>
Project 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>
Project 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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 18 Feb 2010 02:32:38 PM UTCCaSOpen/ClosedOpen=>Closed
    Fri 05 Feb 2010 05:50:44 AM UTCCaSStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1