cannot install ogre

[newchief@…]

It fails with following output in CMakeError.log:

Determining if the C compiler works failed with the following output:
Change Dir: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_ogre/ogre/work/ogre_src_v1-7-3/CMakeFiles/CMakeTmp

Run Build Command:/opt/local/bin/cmakexbuild -project CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration Debug

=== BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug ===
Check dependencies
error: There is no SDK with the name or path '/'
[BEROR]error: There is no SDK with the name or path '/'
** BUILD FAILED **

[ryandesign (Ryan Carsten Schmidt)]

Please remember to use WikiFormatting and to preview before submitting, to fill in the Port field, and to Cc that port's maintainer.

[mamoll (Mark Moll)]

This is very odd. The Portfile for ogre doesn't set the SDK root. This is done in the cmake PortGroup. Specifically, this command:

configure.args-append -DCMAKE_OSX_SYSROOT=/

Does the same thing happen if you install another cmake-based port (e.g., tinyxml)?

[newchief@…]

Strangely, tinyxml built properly.

[mamoll (Mark Moll)]

Can you attach the main.log file that MacPorts produced? Or do "sudo port clean ogre" and attach the output of "sudo port -dv install ogre"?

[newchief@…]

I've attached logs from sudo port -dv install ogre.

[mamoll (Mark Moll)]

For some reason "port" is using gcc 4.2 on your machine and llvm-gcc 4.2 on mine. What version of OS X are you running? And what version of XCode? Can you verify that /usr/bin/gcc-4.2 exists on your machine?

[newchief@…]

It is Mac OSX 10.6.8 I have few different versions of gcc installed, 'port select gcc' says:

Available versions for gcc:
        gcc40
        gcc42
        llvm-gcc42 (active)
        mp-gcc44
        none

I pulled lots of open source packages using macports, I guess different gcc versions were pulled with them as dependencies.

BTW, I tried gcc42, llvm-gcc42, mp-gcc44 and none (which says it is gcc-4.2.1) to build ogre, no luck. For each selection gcc command is found and different versions are dispaled. I also noticed that /usr/bin/gcc-4.2 remains the same and cmake for ogre wants to use exactly this one binary no matter what gcc version is currently selected (active). I have renamed this binary so it became invisibe under that name and then cmake for ogre complained that compiler couldn't be found. I think something is not prepared for many gcc versions installed in one box.

[mamoll (Mark Moll)]

I have gcc45 installed on my machine, multiple gcc versions might not be the issue.

Does adding this to the ogre Portfile help?:

platform darwin 10 {
    macosx_deployment_target 10.6
    configure.sdkroot  /Developer/SDKs/MacOSX10.6.sdk
}

[newchief@…]

Yes, it helped, however, it failed later at install stage. Note that this host is equipped with nvidia GPU and nvidia-cg-toolkit downloaded directly from nvidia is installed in its default directories. May this be the reason for this error? I'd be more than happy if ogre was able to use nvidia-cg-toolkit on this machine....

[mamoll (Mark Moll)]

I also have the Cg.framework installed in /Library/Frameworks. At some point I fiddled around with install_name_tool to fix the rpath of the Cg framework. This is what tool shows for me:

> otool -L /Library/Frameworks/Cg.framework/Cg 
/Library/Frameworks/Cg.framework/Cg:
	/Library/Frameworks/Cg.framework/Cg (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)

Please attach the output of "sudo port -dv install ogre" after you made the change in the Portfile.

[newchief@…]

It's attached...

[mamoll (Mark Moll)]

Do you have Cg installed in some non-standard location? In line 5660 there is this error:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_ogre/ogre/work/ogre_src_v1-7-3/PlugIns/CgProgramManager/include/OgreCgPrerequisites.h:32:19: error: Cg/cg.h: No such file or directory

[newchief@…]

Cg framework was installed from ordinary Cg-3.0_February2011.dmg file.

I was able to make small step ahead: I've created following symlink:

/opt/local/include/Cg -> /Library/Frameworks/Cg.framework/Versions/1.0/Headers

This unfortunately leads to another error at link time:

ld: framework not found Cg

I'd tried to make following symlink:

/opt/local/Library/Frameworks/Cg.framework -> /Library/Frameworks/Cg.framework

it did not help, followink symlik also did not help:

/System/Library/Frameworks/Cg.framework -> /Library/Frameworks/Cg.framework

still the same.

Unfortunately, this is beyond by humble abilities.

[mamoll (Mark Moll)]

I am not sure, but this sounds like a problem with the rpath stored in the Cg framework (see my comment above). Please read the man page for install_name_tool and modify the Cg framework. Alternatively, temporarily move the Cg framework out of the way and see if Ogre builds that way.

[newchief@…]

I have manually removed Cg framework files (I already learned that there's no such thing as automatic framework uninstall) and I was able to install ogre.

[newchief@…]

Now when I got it installed, I'm experiencing problems with bugs within it:

In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43,
                 from /opt/local/include/OGRE/OgreStdHeaders.h:106,
                 from /opt/local/include/OGRE/OgrePrerequisites.h:315,
                 from /opt/local/include/OGRE/Ogre.h:31,
                 from /Users/newchief/gazebo/src/gazebo/server/rendering/OgreVisual.hh:30,
                 from /Users/newchief/gazebo/src/gazebo/server/physics/Body.cc:37:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147: error: format string argument not a string type

The easiest workaround that worked for me is to remark lines 146 and 147 in CFBundle.h file in ogre framework.

[mamoll (Mark Moll)]

Some quick googling suggests that this might be compiler related. Which compiler are you using? OTOH, if a small patch could avoid the problem, I'd be happy to use that route instead, so please do attach a diff.

As a side note, if you get gazebo compiled, I'd be interested in your build notes. I might be able to translate that into a Portfile.

[newchief@…]

I think that making this workaround official is not a good idea: CFBundle.h file is not a part of Ogre framework, the change that I did may potentially break compilation of other things. The gcc version that I selected using port select is mp-gcc44 (4.4.6).

If you want to open pandoras box with Player/Stage/Gazebo, I need to mention that I'm always compiling SVN/GIT snapshot of all those robotics stuff to have them compiled in latest versions with (possibly) all libraries from this list: ​http://vlab.pjwstk.edu.pl/~vlabdemo/psg/player3deps.txt (to my surprise, macports offers most of them). Some hints are:

• gazebo cmake scripts expect that tbb still provides tbb.pc file which is not the truth anymore; you can copy this file: ​http://vlab.pjwstk.edu.pl/~vlabdemo/psg/tbb.pc to /opt/local/lib/pkgconfig for a workaround
• you need two of my patches (ID 3399691 and ID 3399907 on playerstage patch tracker) for svn snapshot of Gazebo to make it compileable
• still it will fail to build at link time, see attached bug report, I'm too new on MacOSX to deal with errors like that

[newchief@…]

One more note: I'm not sure if it is the right thing, however, I did a symlink like this: /opt/local/lib/libopenal.dylib ==> /opt/local/Library/Framework/OpenAL.framework/Versions/Current/OpenAL - this causes cmake script stopped to complain that OpenAL is missing (which disables audio/visual features in Gazebo).

[benjamin.michalski@…]

Cc Me!

[marin.saric@…]

Hi, I can confirm that the mmoll's patch to specify the SDK root fixes the problem for me. I do not have the Cg.framework, so I think the Cg.framework stuff is a separate problem.

I opened a ticket #31889 to track this specific issue. I am also attaching the diff for mmoll's fix in this ticket.

[marin.saric@…]

The patch suggested by mmoll to fix the SDK root

[marin.saric@…]

I submitted a new static-linking-based port of OGRE as a ticket #32302.

The new port builds without XCode and runs on MacOS X 10.6 and MacOS X 10.7 . I am using my new port in a Computer Vision/Robotics application where it also interacts with OpenCV and even successfully links itself into a MATLAB plugin(!).

The new port's name is ogre-static, because it cannot as of now coexist with the currently present ogre and it is not a simple variant.

[mamoll (Mark Moll)]

Wouldn't it be better to simply replace the current Ogre port with ogre-static? Is there code that requires Ogre as a shared library? You seem to have a lot of time in creating this port, so help the rest us understand the pros and cons of two ports vs. one.

[newchief@…]

What about Cg Framework integration? Is it safe to install Cg Framework on my system again? (I had to remove it to make ogre buildable).

[marin.saric@…]

One line answer: I think ogre-static can be renamed ogre and replace the current ogre port as v1.7.3 revision 3.

Long answer:

I think Cg Framework integration should work without problems now but I have not tested extensively. The only prerequisite is that Ogre is installed after Cg.framework. However, if there is any problems I promise to fix them promptly.

Upsides of static build: no dependency hell, deployed binaries just work, regardless of whether the end user has MacPorts installed or not.

Downside: the port does not "react" to user upgrading the install with new libraries. Same goes for deployed binaries. In theory code written for OGRE should support both installs, as it is literally just a few extra lines of code. In practice some people omit the static code, betting on people having a shared library code installed as default.

Overall I think upsides outweigh the downsides. In the future I hope to deploy both libraries in one port, but that requires some changes upstream that I hope to squeeze in before 1.8 is out.

[mamoll (Mark Moll)]

Try the latest version (committed in r87836).

[shenzhuxi@…]

I think it's because SDKROOT is not there.

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_Growl/Growl/main.log

version:1
:debug:main Growl has no conflicts
:debug:main Executing org.macports.main (Growl)
:debug:main changing euid/egid - current euid: 0 - current egid: 0
:debug:main egid changed to: 501
:debug:main euid changed to: 503
:debug:main Skipping completed org.macports.archivefetch (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.fetch (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.checksum (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.extract (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.patch (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.configure (Growl)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:build build phase started at Tue Jun 12 17:23:59 BST 2012
:notice:build --->  Building Growl
:debug:build Executing org.macports.build (Growl)
:debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_Growl/Growl/work/Growl-1.1.6-src" && /usr/bin/xcodebuild  -target "Growl" -configuration Deployment build OBJROOT=build/ MACOSX_DEPLOYMENT_TARGET=10.7 ARCHS=i386 SDKROOT="" '
:info:build Build settings from command line:
:info:build     ARCHS = i386
:info:build     MACOSX_DEPLOYMENT_TARGET = 10.7
:info:build     OBJROOT = build/
:info:build     SDKROOT = 
:info:build 
:info:build === BUILD NATIVE TARGET GrowlMenu OF PROJECT Growl WITH CONFIGURATION Deployment ===
:info:build Check dependencies
:info:build error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk'
:info:build 
:info:build 
:info:build ** BUILD FAILED **
:info:build 
:info:build 
:info:build The following build commands failed:
:info:build 	Check dependencies
:info:build (1 failure)
:info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_Growl/Growl/work/Growl-1.1.6-src" && /usr/bin/xcodebuild  -target "Growl" -configuration Deployment build OBJROOT=build/ MACOSX_DEPLOYMENT_TARGET=10.7 ARCHS=i386 SDKROOT="" 
:info:build Exit code: 65
:error:build org.macports.build for port Growl returned: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
    while executing
"$procedure $targetname"
:info:build Warning: targets not executed for Growl: org.macports.activate org.macports.build org.macports.destroot org.macports.install
:notice:build Please see the log file for port Growl for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_Growl/Growl/main.log