bugGNUstep - Bugs: bug #28900, GDL2 fails to build due to...

 
 

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

bug #28900: GDL2 fails to build due to GSLazyRecursiveLock

Submitted by:  Tim Käck <tkack>
Submitted on:  Mon 15 Feb 2010 11:39:13 AM UTC  
 
Category: gdl2Severity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: David Ayers <ayers>
Open/Closed: Closed

Sat 24 Apr 2010 02:11:28 PM UTC, comment #4:

Fix committed.

David Ayers <ayers>
Project MemberIn charge of this item.
Mon 19 Apr 2010 11:34:38 AM UTC, comment #3:

Change state to in test.

Fred Kiefer <FredKiefer>
Project Member
Tue 30 Mar 2010 08:36:36 AM UTC, comment #2:

Sorry for the delay. I haven't been following bugreports as closely as I should have. Feel free to assign GDL2 issues to me.

I have no issue with removing the macro. The newLockAt: is convenience extension to avoid a race for plugins that get loaded into an already multithreaded environment.

If there is some canonical approach on how to deal with such situations, I'll be happy to use it. Until then I'll implement an approach that relies on the runtime's +initialize semantics and will be GDL2 internal.

David Ayers <ayers>
Project MemberIn charge of this item.
Mon 15 Feb 2010 12:41:14 PM UTC, comment #1:

Most likely you just need to include/import Foundation/Foundation.h to get visibility of the category containing +newLockAt:

NB. The file base/Headers/Additions/GNUstepBase/GSCategories.h is only supposed to be included by code building on OSX without the base library.

Actually, I wonder it we should be defining that macro at all ... it does not appear to be used much (a grep of the svn repository shows it used in only four places ... threeof which are inside the base library itsself). Perhaps we should remove that macro and the +newLockAt: method.

Richard Frith-Macdonald <CaS>
Project Member
Mon 15 Feb 2010 11:39:13 AM UTC, original submission:

Not sure if this has to do with the reorg of gnustep currently.
The problem seems to stem from:

[GS_INITIALIZED_LOCK(local_lock, GSLazyRecursiveLock) lock];

Error (removing stuff since it is compining in parallel, single mode produces same result)

Compiling file EONSAddOns.m ...
EONSAddOns.m: In function ‘GSUseStrictWO451Compatibility’:
EONSAddOns.m:77: error: expected expression before ‘GSLazyRecursiveLock’
EONSAddOns.m:77: warning: invalid receiver type ‘int’
EONSAddOns.m:77: confused by earlier errors, bailing out
Compiling file EOArrayDataSource.m ...
Preprocessed source stored into /tmp/ccbVAozx.out file, please attach this to your bugreport.

The macro that fails look like this:

#define GS_INITIALIZED_LOCK(IDENT,CLASSNAME) \
(IDENT != nil ? IDENT : [CLASSNAME newLockAt: &IDENT])

and is defined in base/Headers/Additions/GNUstepBase/GSCategories.h

I workaround it by doing:

if (local_lock == nil) {
local_lock = [GSLazyRecursiveLock new];
}

Probably not optimal since GSLazyRecursiveLock does not implement newLockAt: (or its super class NSRecursiveLock)
What is the best way to solve this?

Let me know if you need the preprocessed file.

Tim Käck <tkack>

 

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 FredKiefer (Posted a comment)
  • -unavailable- added by ayers (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by tkack (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 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 24 Apr 2010 02:11:28 PM UTCayersStatusReady For Test=>Fixed
      Open/ClosedIn Test=>Closed
    Mon 19 Apr 2010 11:34:38 AM UTCFredKieferOpen/ClosedOpen=>In Test
    Tue 30 Mar 2010 09:10:33 AM UTCayersStatusIn Progress=>Ready For Test
    Tue 30 Mar 2010 08:36:36 AM UTCayersStatusNone=>In Progress
      Assigned toNone=>ayers

    Back to the top


    Powered by Savane 3.1-cleanup1