Menu

error: syntax error before 'NSUInteger'

kane
2007-11-17
2013-04-24
  • kane

    kane - 2007-11-17

    I just downloaded and followed the directions to install the kit. Upon building I am getting the following errors.

    /Developer/Local/Frameworks/RegexKit.framework/Headers/RKCache.h:55: error: syntax error before 'NSUInteger'
    /Developer/Local/Frameworks/RegexKit.framework/Headers/RKCache.h:65: error: syntax error before 'NSUInteger'
    /Developer/Local/Frameworks/RegexKit.framework/Headers/RKCache.h:66: error: syntax error before 'NSUInteger'
    /Developer/Local/Frameworks/RegexKit.framework/Headers/RKCache.h:67: fatal error: method definition not in @implementation context
    compilation terminated.
    {standard input}:32:FATAL:.abort  detected.  Assembly stopping.

    I am trying to do a garbage collected build on x86.

    Does anyone have any ideas what might be causing this or how to fix it?

    Thanks,
    Kane

     
    • John Engelhart

      John Engelhart - 2007-11-17

      That's pretty odd.

      I use RKUInteger in the code for portability purposes, notably for GNUstep.  It's a #define macro that gets set to either NSUInteger or 'unsigned int' depending on some compile time pre-processor checks.  The specific test is:

      #if defined(__MACOSX_RUNTIME__) && defined(MAC_OS_X_VERSION_10_5)

      Since MAC_OS_X_VERSION_10_5 is only present under Mac OS X 10.5, then I assume that's what you're building it under.  NSUInteger is a new type introduced in 10.5, and the typedef for it exists in the foundation framework header 'NSObjCRuntime.h'.

      About the only way I can see the compiler spitting an error out like that is for some reason NSUInteger was never typedef'd, and therefore the compiler doesn't know what to do with it.

      My guess is that you've got the SDKROOT in xcode set to 10.4, not 10.5.  While moving code to 10.5, I noticed that even though I would set the SDKROOT to 10.4 (which ultimately turns on the compiler flags -isysroot /Developer/SDKs/MacOSX10.4u.sdk and the linker flags -isyslibroot /Developer/SDKs/MacOSX10.4u.sdk), the 10_5 definition would still be present.

      In xcode, SDKROOT can be set from a few different places.  In the Project > Edit Project Settings > General tab, near the bottom there's a place for "Cross-Develop using..." setting.  It can also be set from the Build tab, under the "Base SDK Path".  It can also be set manually, through either a .xcconfig setting file or via the xcodebuild command line tool with 'SDKROOT=' passed as an arg.

      There does not appear to be a simple #if like test to determine if NSUInteger exists.  Since it's a typedef, you can't do a #if defined(NSUInteger) for it.  Apple did not provide an easy to use, unambiguous way to determine if NSUInteger is present at compile time.

       
      • kane

        kane - 2007-11-17

        Thanks! That was it in a nutshell. I made the change you mentioned and things worked perfectly.

         
    • John Engelhart

      John Engelhart - 2007-11-17

      You know what?  While hunting down something else, I found this gem in NSObjCRuntime.h:

      #define NSINTEGER_DEFINED 1

      Now, I could have sworn that I looked for just such a thing when I was putting in support for 10.5 and NSIntegers, but I guess I just glanced over it or something.  I'll update the regexkit headers to check for this definition instead of what it currently does.

      #if defined(__MACOSX_RUNTIME__) && defined(MAC_OS_X_VERSION_10_5)

      will become

      #if defined(NSINTEGER_DEFINED)

      That should solve the issue once and for all, and would have prevented the problem you were having.  :(

       
    • Dru Kepple

      Dru Kepple - 2008-02-02

      I'm still on Tiger (10.4.11), with XCode 2.5 and RegexKit 0.6.0.  I'm getting this same error, but I am unable to set SDKROOT to 10.5, being on 10.4 and all.  I'm a bit confused, because the downloads section clearly states that all of the available release are for 10.4 and up.

      I'm a bit new to Cocoa, so I'm sure I'm doing something wrong, but I'm at a loss for what (for the record, I may be new to Cocoa specifically, but not to programming in general...just trying to reach that point where I actually understand the entire system...).

      Can't wait to get this working; I can't believe Objective-C doesn't just have Regular Expressions already.  I mean, it's 2008, right?  I already wasted a bunch of time just looking for the Obj-C implementation of Regex...only to find that it doesn't have it built-in.  Guess I take it for granted these days.

      Thanks.

       
    • John Engelhart

      John Engelhart - 2008-02-03

      Dru,

      I'm at a loss as to what the cause of the problem you're having is.  For a sanity check, I just performed the following commands (via ssh to my x86 laptop running 10.4.5 and Xcode 2.4.1) which essentially erases the installed RegexKit, reinstalls it, and builds the release version of RegexKit and executes the unit tests.  The setenv DEBUG 0 sets a unit tests environment variable.  When DEBUG > 0, it causes several other environment variables to be set (mostly having to do with malloc and some Foundation extra tests), but seems to cause problems on my x86 machine so I disable them here.

      [johne@LAPTOP_X86] ~% sudo rm -rf /Developer/Local/
      [johne@LAPTOP_X86] ~% installer -pkg ~/projects/0.6.0/RegexKit_0.6.0.mpkg/ -target /
      [johne@LAPTOP_X86] ~% cd /Developer/Local/RegexKit/Sourcecode/
      [johne@LAPTOP_X86] Sourcecode% setenv DEBUG 0
      [johne@LAPTOP_X86] Sourcecode% xcodebuild build -configuration 'Release' -target 'Unit Tests'
      ...
      ** BUILD SUCCEEDED **
      [johne@LAPTOP_X86] Sourcecode%

      Obviously, 'It works for me!' doesn't help you.  If you wouldn't mind, could you do the following on your machine?

      First, erase (or `mv` move, or backup, etc, which ever you prefer, but start with a clean/empty /Developer/Local).  Re-install RegexKit (I've guessed at some of the directory paths below, but the correct ones should be obvious).  Then rebuild the framework.

      [johne@LAPTOP_X86] ~% sudo rm -rf /Developer/Local/
      [johne@LAPTOP_X86] ~% open RegexKit_0.6.0.dmg
      [johne@LAPTOP_X86] ~% installer -pkg /Volumes/RegexKit_0.6.0/RegexKit_0.6.0.mpkg/ -target /
      [johne@LAPTOP_X86] ~% cd /Developer/Local/RegexKit/Sourcecode/
      [johne@LAPTOP_X86] Sourcecode% setenv DEBUG 0
      [johne@LAPTOP_X86] Sourcecode% script ~/regexkit_build.txt
      [johne@LAPTOP_X86] Sourcecode% xcodebuild build -configuration 'Release' -target 'Unit Tests'
      ...
      [johne@LAPTOP_X86] Sourcecode% exit
      [johne@LAPTOP_X86] Sourcecode%

      The 'script' command will spawn a new shell and capture all output and save a copy to (YOUR_HOME_DIRECTORY)/regexkit_build.txt.  Once the xcodebuild completes, exit the script spawned shell.  Then mail me (jengelhart -> users.sourceforge.net) the regexkit_build.txt file.  Hopefully that will contain a clue as to whatever is causing the problem.

      There are some problems with linking on 10.4 using the supplied RegexKit.framework binary (covered in the release notes), but if you can get this far then the next steps to overcome the 10.4 linking problems are pretty straightforward.  But one step at a time.

       
    • Dru Kepple

      Dru Kepple - 2008-02-03

      Thanks, John.  I have sent the text file to your email address.  Looking forward to those next steps.

       
    • John Engelhart

      John Engelhart - 2008-02-03

      Dru,

      I've taken a look at the output you sent me.  The short version: It built correctly and all the unit tests executed correctly.  There's a few harmless warnings when building under 10.4 (such as 'can't find the method defaultCollector' because 10.4 doesn't have NSGarbageCollector), but everything looks like it ought to to me.  The most important line is the one at the very end:

      ** BUILD SUCCEEDED **

      This leads me to suspect you're running in to the "DTrace on 10.4" problem.  See the release notes at http://regexkit.sourceforge.net/Documentation/ReleaseNotes.html#Release_0_6_0 for information on it.

      Next step is to copy and paste the following in to a file called 'rk_test.m'.  I prefer using the shell and emacs, but TextEdit.app is fine too.  If you do use TextEdit.app, be sure to select Format > Make Plain Text so it's just straight text and not RTF, which the compiler will be unhappy about.  :)

      -- start of: rk_test.m
      #import <Foundation/Foundation.h>
      #import <RegexKit/RegexKit.h>

      int main(int argc, char *argv[]) {
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
        unsigned int hexValue = 0xdeadbeef;

        [@"0x1234abcd" getCapturesWithRegexAndReferences:@"(0x[0-9a-fA-F]+)", @"${1:%x}", &hexValue, NULL];

        NSLog(@"I got: '%x'", hexValue);

        NSLog(@"Cache: %@", [RKRegex regexCache]);

        [pool release];
        exit(0);
      }
      -- end of: rk_test.m

      Then try the following from the shell.  You should get the same error message (this is the 10.4 / Xcode 2.5 linker bug which is not properly ignoring the 10.5 DTrace section):
      [johne@LAPTOP_X86] ~% gcc -F/Developer/Local/Frameworks -framework Foundation -framework RegexKit -o rk_test -g rk_test.m
      /usr/bin/ld: /Developer/Local/Frameworks/RegexKit.framework/RegexKit unknown flags (type) of section 5 (__TEXT,__dof_RegexKit) in load command 0
      collect2: ld returned 1 exit status

      Then, try the following command.  This one will link against the framework that you just built, and should execute error free:
      [johne@LAPTOP_X86] ~% gcc -F/Developer/Local/RegexKit/Sourcecode/build/Release/ -framework Foundation -framework RegexKit -o rk_test -g rk_test.m

      Now we'll try to run it.  Normally programs linked against RegexKit expect to find the shared library executable portion in their .App applications bundle Frameworks directory.  Since the executable we just created has none of that stuff, we need to give the dynamic linker a hint of where it can actually find the regexkit code:

      [johne@LAPTOP_X86] 105% setenv DYLD_FALLBACK_FRAMEWORK_PATH "/Developer/Local/RegexKit/Sourcecode/build/Release/"

      And now run the 'rk_test' program:

      [johne@LAPTOP_X86] 105% ./rk_test
      2008-02-03 01:44:35.213 rk_test[25306] CFLog (0): CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary.
      2008-02-03 01:44:35.214 rk_test[25306] CFLog (0): CFPropertyListCreateFromXMLData(): The file name for this data might be (or it might not): /System/Library/Frameworks/Foundation.framework/Resources/Languages/en
      2008-02-03 01:44:35.217 rk_test[25306] I got: '1234abcd'
      2008-02-03 01:44:35.217 rk_test[25306] Cache: <RKCache: 0x50a110> "RKRegex Regular Expression Cache" Enabled = Yes (Add: Yes, Lookup: Yes), Cleared count = 0, Cache count = 1, Hit rate =   0.00%, Hits = 0, Misses = 1, Total = 1

      The 'CFPropertyListCreateFromXMLData' message is due to the fact that I forgot a few trailing ;'s at the end of some of the strings in Localizable.strings.  Normally that message goes by so fast that you miss it, or ends up in /var/log/system.log.. I obviously missed it before I put the final 0.6 out, but it's harmless and doesn't effect anything.

      And one more test:

      [johne@LAPTOP_X86] 105% setenv DYLD_FALLBACK_FRAMEWORK_PATH "/Developer/Local/Frameworks/"
      [johne@LAPTOP_X86] 105% ./rk_test
      ... (should be the same output from the previous run) ...

      Now, assuming you made it this far and everything has gone as outlined, you've hit the 10.4 DTrace bug (I've filed a bug with apple, id# 5698078).  It won't build time link with the 10.5 version, but it will RUN and run time dynamic link with the 10.5 version.  :(  You've got a few choices as to how to proceed, depending on your needs, but the absolute simplest is to just copy the version you built under 10.4 over the copy in /Developer/Local/Frameworks/, with a command like (all on one line):

      [johne@LAPTOP_X86] 105% sudo cp /Developer/Local/RegexKit/Sourcecode/build/Release/RegexKit.framework/Versions/A/RegexKit /Developer/Local/Frameworks/RegexKit.framework/Versions/A/RegexKit

      You loose some of the 10.5 features, such as 64 bit architecture support, garbage collection, and dtrace support but for your needs that probably doesn't really matter.  The only thing that you loose which I think is significant is the stack protection features that are only available in the 10.5 compilers.  Runs just fine without it, but on the slim chance there's a stack overflow exploitable bug, you'll loose that extra layer of protection.  I wouldn't loose any sleep over it, though.

      Some of the other options are outlined in the release notes, but they get to be a bit more complicated.  It involves copying your 10.4 built version somewhere and changing the Xcode configuration o the application that uses regexkit to link with your 10.4 version, but copy the 10.5 version. Again, it depends on your needs and how much hassle you're willing to put up with.  If this is just a personal project, I'd just stick with the "copy over the 10.5 version" method.

      Assuming this 'solves' your problem, sorry for the hassles.  I tried to come up with a way around this, but there just doesn't appear to be one, short of Apple providing a trivial bug fix for the 2.5 tool chain.  :(

       
    • Dru Kepple

      Dru Kepple - 2008-02-03

      OK, that seems to do it.  For now, I need Tiger compatibility, although I must admit that between this and the current HandBrake source code in SVN requiring 10.5/XCode 3, I was seriously considering just upgrading to Leopard.  Would be nice, but my project requiring Regex will be used at work, where we're still on Tiger for a while yet.

      At any rate, a quick Regex test in an Xcode test project seems to work, so I'll just keep those missing features in mind.

      Thanks a billion for your help, John!

       
    • John Engelhart

      John Engelhart - 2008-02-03

      No problem, and best of luck.  Sorry about the inconvenience.  There just doesn't seem to be a simple way of overcoming the problem, other than a simple fix to the 'ld' command that would properly ignore the 10.5 DTrace section as the run time dyld linker does.

      I've filed a bug with apple, so with any luck the next version of the 2.5 tool chain will include a fixed 'ld' command and the whole thing will just work.  My suspicion is that someone correctly anticipated what would happen with a DTrace enhanced library on the run time dyld side of things, but forgot that they also needed to make changes to the 'ld' build time linker as well.  And it's such a simple change: Instead of throwing an error, just ignore the section.  :(

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.