Building with GNUstep make on Panther/Tiger

  • Hello all,

    we are trying to build bundles and tools on Tiger using GNUstep make.
    While linking a bundle we get

      Linking bundle HolzPoolBundle ...
    ld: can't locate file for: -lbundle1.o
    make[1]: ***
    [/Build/HolzPoolBundle/HolzPoolBundle.bundle/./HolzPoolBundle] Error 1

    While linking a tool we get

      Linking tool Adaptor ...
    ld: can't locate file for: -lcrt1.o
    make[1]: *** [/Build/Adaptor/shared_obj/Adaptor] Error 1
    make: *** [Adaptor.all.tool.variables] Error 2

    I looked for these files and found them in:

    /Developer/SDKs/MacOSX10.1.5.sdk/usr/lib/crt1.o
    /Developer/SDKs/MacOSX10.2.7.sdk/usr/lib/crt1.o
    /Developer/SDKs/MacOSX10.3.0.sdk/usr/lib/crt1.o

    It looks like this directory has been installed by the dev kit. I added
    the following in the bundle project:

    ADDITIONAL_LIB_DIRS += -L/Developer/SDKs/MacOSX10.3.0.sdk/usr/lib
    HolzPoolBundle_BUNDLE_LIBS += -framework AppKit -framework
    FaxServiceFoundation            -framework FBAccess -framework
    FBAppKit -framework FBDesign            -framework FBEnterprise
    -framework FBInterface            -framework FBObjects -framework
    FBQuery              -framework Message            -framework
    SOFoundation

    Now I get

    Making all for bundle HolzPoolBundle...
      Linking bundle HolzPoolBundle ...
    ld: can't locate framework for: -framework FaxServiceFoundation
    make[1]: ***
    [/Build/HolzPoolBundle/HolzPoolBundle.bundle/./HolzPoolBundle] Error 1

    All the frameworks including FaxServiceFoundation are in
    /Library/Frameworks. I also treid to add

    ADDITIONAL_LIB_DIRS += -L/Library/Frameworks

    but this did not fix it. Our make files used to work on Jaguar. Has
    anybody had more success with using GNUstep make for building stuff on
    Panther and/or Tiger? Thanks a lot for any hint!

    Regards,

      Andreas
  • On Jun 13, 2005, at 5:48 AM, Andreas Höschler wrote:

    > Hello all,
    >
    > we are trying to build bundles and tools on Tiger using GNUstep make.
    > While linking a bundle we get
    >
    > Linking bundle HolzPoolBundle ...
    > ld: can't locate file for: -lbundle1.o
    > make[1]: ***
    > [/Build/HolzPoolBundle/HolzPoolBundle.bundle/./HolzPoolBundle] Error 1
    >
    > While linking a tool we get
    >
    > Linking tool Adaptor ...
    > ld: can't locate file for: -lcrt1.o
    > make[1]: *** [/Build/Adaptor/shared_obj/Adaptor] Error 1
    > make: *** [Adaptor.all.tool.variables] Error 2
    >
    >

    Well I know that Panther works fine with GNUstep.  I don't know about
    Tiger - I've heard people have had trouble with it.
  • Hi,

    >> we are trying to build bundles and tools on Tiger using GNUstep make.
    >> While linking a bundle we get
    >>
    >> Linking bundle HolzPoolBundle ...
    >> ld: can't locate file for: -lbundle1.o
    >> make[1]: ***
    >> [/Build/HolzPoolBundle/HolzPoolBundle.bundle/./HolzPoolBundle] Error >> 1
    >>
    >> While linking a tool we get
    >>
    >> Linking tool Adaptor ...
    >> ld: can't locate file for: -lcrt1.o
    >> make[1]: *** [/Build/Adaptor/shared_obj/Adaptor] Error 1
    >> make: *** [Adaptor.all.tool.variables] Error 2
    >>
    >>
    >
    > Well I know that Panther works fine with GNUstep.  I don't know about
    > Tiger - I've heard people have had trouble with it.

    Any chance Frameworks, tools and apps built on Panther (using GNUstep
    make) will run on Tiger? At least the apps build on Jaguar don't really
    work on Tiger which is more or less to be expected. We e.g. have a
    subclass of NSImageView in one app. If Apple modified the ivars on
    NSImageView from Jaguar to Panther/Tiger this will of course break
    everything. I find it discouraging that apps aren't binary compatible
    between 10.2, 10.3 and 10.4, although I understand why. I guess Apple
    tries to solve this issue with xCode by creating fat bundles containing
    code for all three OS versions.

    How do you guys manage this in production environments where not all
    Macs can always be upgraded to the newest OS? I would hate to have 3
    different dirs with binaries on the NFS server for the 3 different
    OSes. Until now we haven't been able to build anything on Tiger with
    GNUstep make. This is a problem since all Macs shipped from now on will
    come with Tiger and won't run Panther (just tried that with a new G5
    iMac).

    Thanks,

      Andreas
  • At 10:05 PM +0200 6/15/05, Andreas Höschler wrote:
    > I find it discouraging that apps aren't binary
    > compatible between 10.2, 10.3 and 10.4, although
    > I understand why. I guess Apple tries to solve
    > this issue with xCode by creating fat bundles
    > containing code for all three OS versions.

    You are misinformed.

    Apps are absolutely binary compatible from 10.2, 10.3, and 10.4!

    Fat binaries are NOT used for different OS
    versions, only for different CPU architectures.

    In addition, in most cases, things built on 10.4
    will also run on OLDER OS versions as long as you
    don't use APIs only available in the newer OS.

    -pmb
  • Hello Yves,

    >>> we are trying to build bundles and tools on Tiger using GNUstep
    >>> make. While linking a bundle we get
    >>>
    >>> Linking bundle HolzPoolBundle ...
    >>> ld: can't locate file for: -lbundle1.o
    >>> make[1]: ***
    >>> [/Build/HolzPoolBundle/HolzPoolBundle.bundle/./HolzPoolBundle] Error
    >>> 1
    >>>
    >>> While linking a tool we get
    >>>
    >>> Linking tool Adaptor ...
    >>> ld: can't locate file for: -lcrt1.o
    >>> make[1]: *** [/Build/Adaptor/shared_obj/Adaptor] Error 1
    >>> make: *** [Adaptor.all.tool.variables] Error 2
    >>>
    >>>
    >>>
    >>
    >> Well I know that Panther works fine with GNUstep.  I don't know about
    >> Tiger - I've heard people have had trouble with it.
    >
    > It would be easier to help with the actual build command used

    The following archive (7kB) contains a framework and a tool. Both
    builds fine on Jaguar using "make install". This fails on Tiger.cd ./TestFrame
    make install
      Creating /Build/TestFrame...
    Making build-headers for framework TestFrame...
      Creating /Build/TestFrame/derived_src...
      Creating /Build/TestFrame/TestFrame.framework/Versions/A/....
      Creating /Build/TestFrame/TestFrame.framework/Versions/A/Headers...
      Creating /Build/TestFrame/TestFrame.framework/Versions/A/Resources...
    Making all for framework TestFrame...
      Compiling file Person.m ...
      Linking framework TestFrame ...
    /usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0)
    file: -lSystem is not an object file (not allowed in a library)
      Creating
    /Build/TestFrame/TestFrame.framework/Versions/A/Resources/Info.plist...
    Making install for framework TestFrame...
      Creating //Library/Frameworks...
      Installing framework TestFrame...

    cd ./TestTool
    make install
      Creating /Build/TestTool...
    Making all for tool TestTool...
      Compiling file TestTool_main.m ...
    gcc: -framework: linker input file unused because linking not done
    gcc: TestFrame: linker input file unused because linking not done
      Linking tool TestTool ...
    ld: can't locate file for: -lcrt1.o
    make[1]: *** [/Build/TestTool/shared_obj/TestTool] Error 1
    make: *** [TestTool.all.tool.variables] Error 2

    I looked up libcrt1.o and gave make the lib dir. It then complained
    that it could not locate the frameworks!? Any ideas?

    Regards,

      Andreas
  • Hi Peter,

    >> I find it discouraging that apps aren't binary compatible between
    >> 10.2, 10.3 and 10.4, although I understand why. I guess Apple tries
    >> to solve this issue with xCode by creating fat bundles containing
    >> code for all three OS versions.
    >
    > You are misinformed.
    >
    > Apps are absolutely binary compatible from 10.2, 10.3, and 10.4!

    Thanks for the info!

    > Fat binaries are NOT used for different OS versions, only for
    > different CPU architectures.
    >
    > In addition, in most cases, things built on 10.4 will also run on
    > OLDER OS versions

    What exactly means "most cases" except the obvious API extension
    reason? Why does code built one Jaguar not work on Tiger properly then?

    Regards,

      Andreas
  • At 10:25 PM +0200 6/15/05, Andreas Höschler wrote:
    > Hi Peter,
    >
    >>> I find it discouraging that apps aren't binary
    >>> compatible between 10.2, 10.3 and 10.4,
    >>> although I understand why. I guess Apple tries
    >>> to solve this issue with xCode by creating fat
    >>> bundles containing code for all three OS
    >>> versions.
    >>
    >> You are misinformed.
    >>
    >> Apps are absolutely binary compatible from 10.2, 10.3, and 10.4!
    >
    > Thanks for the info!
    >
    >> Fat binaries are NOT used for different OS
    >> versions, only for different CPU architectures.
    >>
    >> In addition, in most cases, things built on
    >> 10.4 will also run on OLDER OS versions
    >
    > What exactly means "most cases" except the
    > obvious API extension reason? Why does code
    > built one Jaguar not work on Tiger properly then?

    Anything built on Jaguar should work on Tiger.
    Period. If it doesn't, there's a bug in the OS,
    or the binary was doing something unsupported
    from the beginning. Apple spends an amazing
    amount of effort on "backwards compatibility".
    That's where 10.4 is able to run any binary built
    for 10.2, etc..

    MOST things built on Tiger (10.4) will also run
    on Panther (10.3), etc... That's called
    "forwards" compatibility, and it's MUCH harder,
    because it means that 10.2 somehow is able to
    deal with the FUTURE changes in the OS.

    Summary:

    Backwards compatibility should always work. The
    binary you build today should continue to work
    tomorrow unless you do something unsupported.

    Forwards compatibility will usually work, but you
    shouldn't count on it. If you want to create a
    binary using 10.4 tools that will run on 10.2,
    you should use the 10.2 SDK.

    -pmb
  • On 16/06/2005, at 6:58, Peter Bierman wrote:

    > Forwards compatibility will usually work, but you shouldn't count
    > on it. If you want to create a binary using 10.4 tools that will
    > run on 10.2, you should use the 10.2 SDK.

    ... and the GCC 3.3 compiler. We had problems when initially
    compiling under Tiger because it uses GCC 4 by default. Even if you
    use the 10.2 cross-development SDK, you also need to change the
    compiler to GCC 3.3 or your app won't run in 10.2.

    - rob.keniger
  • On Jun 15, 2005, at 4:43 PM, Nicolas Roard wrote:
    > I can confirm that existing binaries of GNUstep works on Tiger. I can
    > also confirm that GNUstep doesn't work on Tiger :-)
    > -- the compilation is ok,... well you need to get a libobjc as usual,
    > but with some little tweak it compiles with Apple's gcc.The problem is
    > with loading dynamic code, that doesn't work. And as GNUstep relies on
    > bundles to load the GNUstep gui backend... same problem with FSF's
    > gcc..
    >

    Hmm, I wonder if they got rid of the dlfcn compatibility? Maybe it's
    about time we started using the native dynamic loading interface...
  • dlopen(3) *is* the native dynamic loading interface on Tiger and
    later. From the man page:

          In Mac OS X 10.4, dlopen was rewritten to be a native part of
    dyld.

    Shantonu

    On Jun 15, 2005, at 9:29 PM, Adam Fedor wrote:

    >
    > On Jun 15, 2005, at 4:43 PM, Nicolas Roard wrote:
    >
    >> I can confirm that existing binaries of GNUstep works on Tiger. I
    >> can also confirm that GNUstep doesn't work on Tiger :-)
    >> -- the compilation is ok,... well you need to get a libobjc as
    >> usual, but with some little tweak it compiles with Apple's gcc.The
    >> problem is with loading dynamic code, that doesn't work. And as
    >> GNUstep relies on bundles to load the GNUstep gui backend... same
    >> problem with FSF's gcc..
    >>
    >>
    >
    > Hmm, I wonder if they got rid of the dlfcn compatibility? Maybe
    > it's about time we started using the native dynamic loading
    > interface...
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • Hello Yves,

    thanks to all that responded to my post. I got a bunch of good answers.
    I especially I was informed that xCode 1.0 can't be used. I need to
    remove this and do a full install of xCode 1.1. Only this will copy the
    files bundle1.o, crt1.o ... into the correct location. So while doing
    this I got rid of one problem. Another problem remained.

    > it seems to works for me ...

    Neither for me! I get:

    cd ./TestFrame
    make messages=yes install
    Making build-headers for framework TestFrame...
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs
    /Build/TestFrame/derived_src
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs
    /Build/TestFrame/TestFrame.framework/Versions/A/.
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs
    /Build/TestFrame/TestFrame.framework/Versions/A/Headers
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs
    /Build/TestFrame/TestFrame.framework/Versions/A/Resources
    cd /Build/TestFrame/TestFrame.framework/Versions; \
    rm -f Current; \
    ln -s A Current
    cd /Build/TestFrame/TestFrame.framework; \
      if [ ! -h "Resources" ]; then \
        rm -f Resources; \
        ln -s Versions/Current/Resources Resources; \
      fi; \
      if [ ! -h "Headers" ]; then \
        rm -f Headers; \
        ln -s Versions/Current/Headers Headers; \
      fi
    cd /Build/TestFrame/derived_src; \
      if [ ! -h "TestFrame" ]; then \
        rm -f ./TestFrame; \
        ln -s ../TestFrame.framework/Headers \
                        ./TestFrame; \
      fi
    for file in Person.h __done; do \
      if [ $file != __done ]; then \
        /usr/bin/install -c  -m 644 ./$file \

    /Build/TestFrame/TestFrame.framework/Versions/A/Headers/$file ; \
      fi; \
    done
    Making all for framework TestFrame...
    cd /Build/TestFrame; \
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs ./shared_obj; \
    rm -f obj; \
    ln -s ./shared_obj obj
    gcc Person.m -c \
          -MMD -MP -DNeXT_Foundation_LIBRARY=1 -DNeXT_GUI_LIBRARY=1
    -DNeXT_RUNTIME=1 -dynamic -fno-common -DGSWARN -DGSDIAGNOSE -O2
    -fno-strict-aliasing -fnext-runtime -Wno-parentheses -Wno-import
    -I/Build/TestFrame/derived_src -I.
    -I/opt/GNUstep/System/Library/Headers/
    -F/opt/GNUstep/Local/Library/Frameworks/ \
            -o /Build/TestFrame/shared_obj/Person.o
    \
    gcc  -dynamiclib  -current_version 1.0.0 -install_name
    TestFrame.framework/TestFrame -flat_namespace -undefined warning
      -o
    /Build/TestFrame/TestFrame.framework/Versions/A/./
    libTestFrame.dylib.1.0.0  -L/opt/GNUstep/System/Library/Libraries/
    -F/opt/GNUstep/Local/Library/Frameworks/ -framework Foundation
    -framework AppKit  /Build/TestFrame/shared_obj/Person.o ; (cd
    /Build/TestFrame/TestFrame.framework/Versions/A/.; rm -f
    libTestFrame.dylib; if [ "libTestFrame.dylib.1" !=
    "libTestFrame.dylib.1.0.0" ]; then rm -f libTestFrame.dylib.1; ln -s
    libTestFrame.dylib.1.0.0 libTestFrame.dylib.1; fi; ln -s
    libTestFrame.dylib.1.0.0 libTestFrame.dylib); \
    (cd /Build/TestFrame/TestFrame.framework/Versions/A/.; \
      rm -f TestFrame; \
      ln -s libTestFrame.dylib TestFrame) \

    /usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0)
    file: -lSystem is not an object file (not allowed in a library)
    (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
      echo "  NSExecutable = \"TestFrame\";"; \
      echo "  NSMainNibFile = \"\";"; \
      echo "  NSPrincipalClass = \"TestFrame\";"; \
      echo "}")
    > /Build/TestFrame/TestFrame.framework/Versions/A/Resources/Info.plist
    cd /Build/TestFrame/TestFrame.framework; \
    rm -f TestFrame; \
    ln -s Versions/Current/./TestFrame TestFrame
    Making install for framework TestFrame...
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs //Library/Frameworks
    rm -rf //Library/Frameworks/TestFrame.framework; \
    (cd /Build/TestFrame; gnutar cfX -
    /opt/GNUstep/System/Library/Makefiles/tar-exclude-list
    TestFrame.framework) | (cd //Library/Frameworks; gnutar xf -)

    cd ./TestTool
    make messages=yes install
    Making all for tool TestTool...
    cd /Build/TestTool; \
    /opt/GNUstep/System/Library/Makefiles/mkinstalldirs ./shared_obj; \
    rm -f obj; \
    ln -s ./shared_obj obj
    gcc TestTool_main.m -c \
          -MMD -MP -DNeXT_Foundation_LIBRARY=1 -DNeXT_GUI_LIBRARY=1
    -DNeXT_RUNTIME=1 -dynamic -fno-common -DGSWARN -DGSDIAGNOSE -O2
    -fno-strict-aliasing -fnext-runtime -Wno-parentheses -Wno-import
    -framework TestFrame -I. -I/opt/GNUstep/System/Library/Headers/
    -F/opt/GNUstep/Local/Library/Frameworks/ \
            -o /Build/TestTool/shared_obj/TestTool_main.o
    gcc: -framework: linker input file unused because linking not done
    gcc: TestFrame: linker input file unused because linking not done
    gcc        -o /Build/TestTool/shared_obj/TestTool \
            /Build/TestTool/shared_obj/TestTool_main.o \
              -L/opt/GNUstep/System/Library/Libraries/ -lm
    -F/opt/GNUstep/Local/Library/Frameworks/ -framework TestFrame
    -framework Foundation
    ld: can't locate framework for: -framework TestFrame
    make[1]: *** [/Build/TestTool/shared_obj/TestTool] Error 1
    make: *** [TestTool.all.tool.variables] Error 2

    TestFrame.framework got installed in /Library/Frameworks inspite of the
    above error message. What's this locate problem about?

    Thanks a lot!

    Regards,

      Andreas
  • Dude, you're using the Panther Dev Tools on a Tiger system.

    Install the Tiger developer tools.

    Shantonu

    On Jun 16, 2005, at 8:50 AM, Andreas Höschler wrote:

    > Hello Yves,
    >
    > thanks to all that responded to my post. I got a bunch of good
    > answers. I especially I was informed that xCode 1.0 can't be used.
    > I need to remove this and do a full install of xCode 1.1. Only this
    > will copy the files bundle1.o, crt1.o ... into the correct
    > location. So while doing this I got rid of one problem. Another
    > problem remained.
    >
    >
    >> it seems to works for me ...
    >>
    >
    > Neither for me! I get:
    >
    > cd ./TestFrame
    > make messages=yes install
    > Making build-headers for framework TestFrame...
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs /Build/
    > TestFrame/derived_src
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs /Build/
    > TestFrame/TestFrame.framework/Versions/A/.
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs /Build/
    > TestFrame/TestFrame.framework/Versions/A/Headers
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs /Build/
    > TestFrame/TestFrame.framework/Versions/A/Resources
    > cd /Build/TestFrame/TestFrame.framework/Versions; \
    > rm -f Current; \
    > ln -s A Current
    > cd /Build/TestFrame/TestFrame.framework; \
    > if [ ! -h "Resources" ]; then \
    > rm -f Resources; \
    > ln -s Versions/Current/Resources Resources; \
    > fi; \
    > if [ ! -h "Headers" ]; then \
    > rm -f Headers; \
    > ln -s Versions/Current/Headers Headers; \
    > fi
    > cd /Build/TestFrame/derived_src; \
    > if [ ! -h "TestFrame" ]; then \
    > rm -f ./TestFrame; \
    > ln -s ../TestFrame.framework/Headers \
    > ./TestFrame; \
    > fi
    > for file in Person.h __done; do \
    > if [ $file != __done ]; then \
    > /usr/bin/install -c  -m 644 ./$file \
    > /Build/TestFrame/TestFrame.framework/Versions/A/
    > Headers/$file ; \
    > fi; \
    > done
    > Making all for framework TestFrame...
    > cd /Build/TestFrame; \
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs ./shared_obj; \
    > rm -f obj; \
    > ln -s ./shared_obj obj
    > gcc Person.m -c \
    > -MMD -MP -DNeXT_Foundation_LIBRARY=1 -DNeXT_GUI_LIBRARY=1 -
    > DNeXT_RUNTIME=1 -dynamic -fno-common -DGSWARN -DGSDIAGNOSE -O2 -fno-
    > strict-aliasing -fnext-runtime -Wno-parentheses -Wno-import -I/
    > Build/TestFrame/derived_src -I. -I/opt/GNUstep/System/Library/
    > Headers/ -F/opt/GNUstep/Local/Library/Frameworks/ \
    > -o /Build/TestFrame/shared_obj/Person.o
    > \
    > gcc  -dynamiclib  -current_version 1.0.0 -install_name
    > TestFrame.framework/TestFrame -flat_namespace -undefined
    > warning        -o /Build/TestFrame/TestFrame.framework/Versions/
    > A/./libTestFrame.dylib.1.0.0  -L/opt/GNUstep/System/Library/
    > Libraries/ -F/opt/GNUstep/Local/Library/Frameworks/ -framework
    > Foundation -framework AppKit  /Build/TestFrame/shared_obj/
    > Person.o ; (cd /Build/TestFrame/TestFrame.framework/Versions/A/.;
    > rm -f libTestFrame.dylib; if [ "libTestFrame.dylib.1" !=
    > "libTestFrame.dylib.1.0.0" ]; then rm -f libTestFrame.dylib.1; ln -
    > s libTestFrame.dylib.1.0.0 libTestFrame.dylib.1; fi; ln -s
    > libTestFrame.dylib.1.0.0 libTestFrame.dylib); \
    > (cd /Build/TestFrame/TestFrame.framework/Versions/A/.; \
    > rm -f TestFrame; \
    > ln -s libTestFrame.dylib TestFrame) \
    >
    > /usr/bin/libtool: for architecture: cputype (16777234) cpusubtype
    > (0) file: -lSystem is not an object file (not allowed in a library)
    > (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
    > echo "  NSExecutable = \"TestFrame\";"; \
    > echo "  NSMainNibFile = \"\";"; \
    > echo "  NSPrincipalClass = \"TestFrame\";"; \
    > echo "}") >/Build/TestFrame/TestFrame.framework/Versions/A/
    > Resources/Info.plist
    > cd /Build/TestFrame/TestFrame.framework; \
    > rm -f TestFrame; \
    > ln -s Versions/Current/./TestFrame TestFrame
    > Making install for framework TestFrame...
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs //Library/
    > Frameworks
    > rm -rf //Library/Frameworks/TestFrame.framework; \
    > (cd /Build/TestFrame; gnutar cfX - /opt/GNUstep/System/Library/
    > Makefiles/tar-exclude-list TestFrame.framework) | (cd //Library/
    > Frameworks; gnutar xf -)
    >
    >
    > cd ./TestTool
    > make messages=yes install
    > Making all for tool TestTool...
    > cd /Build/TestTool; \
    > /opt/GNUstep/System/Library/Makefiles/mkinstalldirs ./shared_obj; \
    > rm -f obj; \
    > ln -s ./shared_obj obj
    > gcc TestTool_main.m -c \
    > -MMD -MP -DNeXT_Foundation_LIBRARY=1 -DNeXT_GUI_LIBRARY=1 -
    > DNeXT_RUNTIME=1 -dynamic -fno-common -DGSWARN -DGSDIAGNOSE -O2 -fno-
    > strict-aliasing -fnext-runtime -Wno-parentheses -Wno-import -
    > framework TestFrame -I. -I/opt/GNUstep/System/Library/Headers/ -F/
    > opt/GNUstep/Local/Library/Frameworks/ \
    > -o /Build/TestTool/shared_obj/TestTool_main.o
    > gcc: -framework: linker input file unused because linking not done
    > gcc: TestFrame: linker input file unused because linking not done
    > gcc        -o /Build/TestTool/shared_obj/TestTool \
    > /Build/TestTool/shared_obj/TestTool_main.o \
    > -L/opt/GNUstep/System/Library/Libraries/ -lm -F/opt/
    > GNUstep/Local/Library/Frameworks/ -framework TestFrame -framework
    > Foundation
    > ld: can't locate framework for: -framework TestFrame
    > make[1]: *** [/Build/TestTool/shared_obj/TestTool] Error 1
    > make: *** [TestTool.all.tool.variables] Error 2
    >
    > TestFrame.framework got installed in /Library/Frameworks inspite of
    > the above error message. What's this locate problem about?
    >
    > Thanks a lot!
    >
    > Regards,
    >
    > Andreas
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • Dear Shantonu,

    > Dude, you're using the Panther Dev Tools on a Tiger system.
    >
    > Install the Tiger developer tools.

    This actually fixed the problem. Thanks!

    It was not clear to me that this was necessary. The release notes and
    CD labels tell me "You need 10.3.x or higher". They don't say "Never
    install this on a system >= 10.4". Never mind. I am glad, I can at
    least compile stuff now, although the app still does not work correctly
    (see my other mail).

    Thanks anyway!

    Regards,

      Andreas
previous month june 2005 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Go to today