bugGNUstep - Bugs: bug #34692, if multiple libobjc's exist, the...


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

bug #34692: if multiple libobjc's exist, the use of AC_CHECK_FUNCS for checking functions in libobjc can give wrong results

Submitted by:  Eric Wasylishen <ericw>
Submitted on:  Sun 30 Oct 2011 06:46:44 AM UTC  
Category:  Base/Foundation Severity:  2 - Minor
Item Group:  Bug Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Tue 08 Mar 2016 10:18:39 PM UTC, comment #4:

Closing as problem was never confirmed

Richard Frith-Macdonald <CaS>
Project Member
Sun 17 Feb 2013 09:12:35 AM UTC, comment #3:

I can't really make sense of this:

Firstly, I don't see how/why we should pick up the wrong libobjc ... we use the results of `gnustep-config --objc-libs` which should be setting the arguments to use the right one.

Secondly, I don't see where '-undefined dynamic_lookup' can be coming from ... while target.make in gnustep-make does set that, it seems to do so only for the flags for linking bundles, and that shouldn't be in the flags that gnustep-base uses.

Perhaps this issue applies to older versions of the code and doesn't actually occur for current gnustep?

Richard Frith-Macdonald <CaS>
Project Member
Sun 30 Oct 2011 11:37:08 PM UTC, comment #2:

Investigated a bit more, and the problem is not exactly what I though.

Within the section of configure.ac starting at:
# Check whether Objective-C /really/ works
where the Objective-C flags are added to LIBS/CPPFLAGS, we add the "-undefined dynamic_lookup" flag on mac os x (c.f. target.make in gnustep-make). This flag means something along the lines of, "the linker will not generate an error if there are undefined symbols in the code being linked, but it will be a runtime error."

As a result, any calls to AC_CHECK_FUNC in this section will pass. (e.g. AC_CHECK_FUNC(SomeNonExistentFunction) passes). likewise, any use of AC_LINK_IFELSE will pass.

Not sure what we should do about this.. we could either replace all of the AC_CHECK_FUNC and AC_LINK_IFELSE with AC_RUN_IFELSE, or else disable the "-undefined dynamic_lookup" flag for the configure tests.

Eric Wasylishen <ericw>
Project Member
Sun 30 Oct 2011 05:10:10 PM UTC, comment #1:

Also, the same sort of problem occurs with:


This will pick up the apple runtime's runtime.h even though I'm not using the apple runtime.

Eric Wasylishen <ericw>
Project Member
Sun 30 Oct 2011 06:46:44 AM UTC, original submission:

I'm trying to build gnustep-base 1.23.0 on Mac OS 10.7. I am using the macports-gcc-4.4 compiler and its objc runtime.

The AC_CHECK_FUNCS configure macros testing for functions in libobjc are finding functions in Apple's libobjc (objc_setProperty, _Block_copy) which my gcc libobjc doesn't have. This messes up the compilation later, because base thinks it will be linked agains a libobjc which has these modern features, but I end up linking it against the gcc 4.4 libobjc.

I think this can be fixed by creating test programs (like the tests in config/config.*.m) for these features, and avoiding the use of AC_CHECK_FUNCS for testing for functions in libobjc.

Eric Wasylishen <ericw>
Project Member


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 ericw (Submitted the item)

    Do you think this task is very important?
    If so, you can 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
    Tue 08 Mar 2016 10:18:39 PM UTC CaS StatusNone => Works For Me
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.1-cleanup1