Compiling avogadro under Mac OS 10.6

Can anyone please help by providing the crucial additional information beyond http://avogadro.openmolecules.net/wiki/Compiling_on_Linux_and_Mac_OS_X that would enable the building of Avogadro under Snow Leopard? If one does it in a simple-minded way, one trips over the 64/32 bit library compatibility problems that are not seen under Leopard, where gcc is by default 32 bit. My attempts to go beyond this by

cmake -DCMAKE_OSX_ARCHITECTURES=i386

for example, lead to unresolved symbols that I do not understand.

Has anyone done this from the very beginning (including getting prerequisites such as openbabel) in a way that is cleanly reproducible?

Thanks very much,
Peter


Prof. Peter J. Knowles
School of Chemistry, Cardiff University, Main Building, Park Place, Cardiff CF10 3AT, UK
Telephone +44 29 208 74805 Email KnowlesPJ@Cardiff.ac.uk
WWW http://www.cardiff.ac.uk/chemy/contactsandpeople/academicstaff/knowles.html

The 32 bit version of Avogadro can be built using the following cmake
arguments, as previously pointed out by Konstantin ;
" -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 ".
Provided you have a working OB somewhere. There are many other problems
compiling the trunk version. For one, the 32 bit version of OB do not yield
a working babel with cmake, at least in OS X 10.6.2. I filed a bug report
in openbabel yesterday regarding this issue.

Secondly, the availability of Qt 4.6 support for 64 bit mode in OS X may be
a way to get Avo working, but compilation of OB in x86_64 mode fails
due to missing x86_64 support in the Quicktime framework (???, not
multy arch ?).

Hope someone may supply more infos,

Cheers,

Louis

Peter Knowles a écrit :

Can anyone please help by providing the crucial additional information beyond http://avogadro.openmolecules.net/wiki/Compiling_on_Linux_and_Mac_OS_X that would enable the building of Avogadro under Snow Leopard? If one does it in a simple-minded way, one trips over the 64/32 bit library compatibility problems that are not seen under Leopard, where gcc is by default 32 bit. My attempts to go beyond this by

cmake -DCMAKE_OSX_ARCHITECTURES=i386

for example, lead to unresolved symbols that I do not understand.

Has anyone done this from the very beginning (including getting prerequisites such as openbabel) in a way that is cleanly reproducible?

Thanks very much,
Peter


Prof. Peter J. Knowles
School of Chemistry, Cardiff University, Main Building, Park Place, Cardiff CF10 3AT, UK
Telephone +44 29 208 74805 Email KnowlesPJ@Cardiff.ac.uk
WWW http://www.cardiff.ac.uk/chemy/contactsandpeople/academicstaff/knowles.html


Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Secondly, the availability of Qt 4.6 support for 64 bit mode in OS X may be
a way to get Avo working, but compilation of OB in x86_64 mode fails
due to missing x86_64 support in the Quicktime framework (???, not
multy arch ?).

Can you give me a specific error message? I’ve compiled Avogadro and Open Babel as both 32-bit Universal, and 64-bit-Intel binaries.

Thanks,
-Geoff

it in a simple-minded way, one trips over the 64/32 bit library compatibility problems that are not seen under Leopard, where gcc is by default 32 bit. My attempts to go beyond this by

cmake -DCMAKE_OSX_ARCHITECTURES=i386

I clearly need to revise that wiki, but I need some feedback on what’s causing problems.

First off, what version of Cmake are you using?

Has anyone done this from the very beginning (including getting prerequisites such as openbabel) in a way that is cleanly reproducible?

Yes. I have to get my nightly builds going again, but I can build everything reproducible. The problem has been Cmake 2.6.x, which gets confused with Snow Leopard’s multiple SDKs.

As a rule, it’s usually easier to build an Avogadro + Open Babel “super-project.” Here’s what I do:

CXX=g+±4.0 CC=gcc-4.0 cmake ~/Devel/avogadro-super/ -DCMAKE_BUILD_TYPE:STRING=MinSizeRel -DCMAKE_OSX_ARCHITECTURES=“i386;ppc” -DCMAKE_OSX_SYSROOT=‘/Developer/SDKs/MacOSX10.4u.sdk’ -DENABLE_PYTHON=false -DENABLE_GLSL=false -DENABLE_AVO_PACKAGE=true -DCMAKE_CXX_FLAGS=‘-I/usr/local/include/openbabel-2.0’ -DENABLE_UPDATE_CHECKER=true -DENABLE_VERSIONED_PLUGIN_DIR=false

This forces an Avogadro build to work on 10.4 with universal binaries (and the Qt “Carbon” installation).

I’m happy to help people work out the Mac builds on the list – there seems to be some real trouble, for reasons I don’t quite understand. Obviously that’s bad!

-Geoff

Building OB trunk version, 64 bit version, Mac OS X 10.6.2 on a MacBook,
with gcc 4.2.1. Configured with “cmake …” in build directory with
cmake version 2.8.0. Same error with version 2.6.4.
The error list is quite verbose and occurs when linking OBGUI in step 100.
Enclosing the make.log file.

I will retry 32 bit later on this evening using gcc 4.0 as you mentioned in your
reply to Peter.

My simple minded idea behind this was that the 64 bit version could work.
Babel always produces errors, as I posted yesterday on the openbabel
bugs list.

There is also another unrelated warning in the make log.

Louis

The error list is quite verbose and occurs when linking OBGUI in step 100.
Enclosing the make.log file.

Ah. Right. I had turned off the compilation of OBGUI.

I’ll see what’s happening there.

-Geoff

Problems in building OB, trunk or version 2.2.3, appear to be related to cmake.
Using gcc-4.2.1 and cmake (2.8.0 or 2.6.4) always result in an error message:
“babel: cannot write output format!
Open Babel 2.2.99 – Dec 7 2009 – 20:25:12
Usage: babel [-i] [-o]
Try -H option for more information.”

I can only get a working babel using version 2.2.3 and configure.
Works in default 64 bit mode in OS X 10.6.2 or in i386 mode
after exporting CXXFLAGS=-m32 and CFLAGS=-m32.

Still have to resolve problem building Avo trunk.

“cmake/modules/MacroEnsureVersion.cmake”

fails for me.

As an aside, I like to keep OB in /usr/local for I use babel to
maintain an Intranet X-ray database: some scripts depend
on this path.

Cheers,

Louis

Le 7 déc. 2009 à 19:44, Geoffrey Hutchison a écrit :

The error list is quite verbose and occurs when linking OBGUI in step 100.
Enclosing the make.log file.

Ah. Right. I had turned off the compilation of OBGUI.

I’ll see what’s happening there.

-Geoff


Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Hi all.

This morning, rebuilt everything, starting with cmake-2.8.0.
I initially built cmake in default mode : g++2.4.1 and x86_84
mode. Then, babel fails to work, even when compiled in i386
mode. So in doubt, I rebuilt cmake as follows:
“export CXX=g+±4.0
export CC=gcc-4.0
export CXXFLAGS=-m32
export CFLAGS=-m32
./bootstrap”

Now have an i386 cmake.

Removed all previous openbabel libs and includes in /usr/local.
Then compiled OB trunk with:
“CXX=g+±4.0 CC=gcc-4.0 cmake -DCMAKE_OSX_ARCHITECTURES=“i386” …”

And now have a working babel. I do not understand why not with default g++.

Then tried compiling avogadro trunk with:
“CXX=g+±4.0 CC=gcc-4.0 cmake -DCMAKE_OSX_ARCHITECTURES=“i386”
-DOPENBABEL2_INCLUDE_DIR=/usr/local/include/openbabel-2.0
-D-DOPENBABEL2_LIBRARIES=/usr/local/lib/libopenbabel.4.0.0.dylib
-DOPENBABEL2_VERSION_MET=true -DENABLE_PYTHON=false …”

cmake configure fails with:
“-- Found OpenBabel 2.2 or later: /usr/local/lib/libopenbabel.dylib
– Found OpenBabel2 executable: /usr/local/bin/babel
CMake Error at cmake/modules/MacroEnsureVersion.cmake:95 (NORMALIZE_VERSION):
NORMALIZE_VERSION Macro invoked with incorrect arguments for macro named:
NORMALIZE_VERSION
Call Stack (most recent call first):
cmake/modules/FindOpenBabel2.cmake:108 (macro_ensure_version)
CMakeLists.txt:130 (find_package)”

So then I savagely replaced FindOpenbabel2.cmake with the avogadro-1.0
version and got a working Avo after repeating the above configuration.

This is a dirty workaround, but …

Hope it helps,

Louis

Le 7 déc. 2009 à 21:30, Louis Ricard a écrit :

Problems in building OB, trunk or version 2.2.3, appear to be related to cmake.
Using gcc-4.2.1 and cmake (2.8.0 or 2.6.4) always result in an error message:
“babel: cannot write output format!
Open Babel 2.2.99 – Dec 7 2009 – 20:25:12
Usage: babel [-i] [-o]
Try -H option for more information.”

I can only get a working babel using version 2.2.3 and configure.
Works in default 64 bit mode in OS X 10.6.2 or in i386 mode
after exporting CXXFLAGS=-m32 and CFLAGS=-m32.

Still have to resolve problem building Avo trunk.

“cmake/modules/MacroEnsureVersion.cmake”

fails for me.

As an aside, I like to keep OB in /usr/local for I use babel to
maintain an Intranet X-ray database: some scripts depend
on this path.

Cheers,

Louis

Le 7 déc. 2009 à 19:44, Geoffrey Hutchison a écrit :

The error list is quite verbose and occurs when linking OBGUI in step 100.
Enclosing the make.log file.

Ah. Right. I had turned off the compilation of OBGUI.

I’ll see what’s happening there.

-Geoff


Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options


Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

This morning, rebuilt everything, starting with cmake-2.8.0.
I initially built cmake in default mode : g++2.4.1 and x86_84

Now have an i386 cmake.

You should not need to build Cmake from scratch. Consider that GCC is multi-architecture:
[ghutchis@geoffh-desktop] ~: file /usr/bin/gcc-4.2
/usr/bin/gcc-4.2: Mach-O universal binary with 3 architectures
/usr/bin/gcc-4.2 (for architecture i386): Mach-O executable i386
/usr/bin/gcc-4.2 (for architecture ppc7400): Mach-O executable ppc
/usr/bin/gcc-4.2 (for architecture x86_64): Mach-O 64-bit executable x86_64

The same is true of “make.” I use the Cmake binary distribution and it works fine.

And now have a working babel. I do not understand why not with default g++.

There is a strange wxWidgets bug preventing us from linking the OBGUI on Snow Leopard with the default g++. I committed a patch last night which disables OBGUI on Mac. (We have iBabel, for example.)

CMake Error at cmake/modules/MacroEnsureVersion.cmake:95 (NORMALIZE_VERSION):
NORMALIZE_VERSION Macro invoked with incorrect arguments for macro named:
NORMALIZE_VERSION

Hmm. I’ll investigate this next. I have been building the Avogadro “superpackage,” and I haven’t seen this bug. I’ll see if I can fix it momentarily.

-Geoff

Hello there,

Long time Linux (ubuntu) developer and compiler of openbabel and Avogadro.
New project: build Avogadro and Openbabel using Mac OS 10.6

First things first,

I started out on a completely new installation of 10.6 - not infected by any
software other than what I did to it. And what I did to it, comes here:

I downloaded and installed the latest compiler tools from
developer.apple.com so I can compile stuff (gcc 4.2.1). Then I proceeded to
download the latest CMAKE (2.8) and Qt (4.6) dmg packages and installed them
using the built-in tools for that. From here, I downloaded and extracted the
openbabel 2.2.3 source code and extracted it into ~/software/src giving me
an openbabel-2.2.3 folder here. Based on this mail, I’ve exported
CXXFLAGS=-m32 and CFLAGS=-m32 to enable 32 bit compilation of openbabel
(this is required since I’ve apparently got hold of the 32 bit Qt package).
I have a build directory for openbabel in ~/software/build/openbabel from
where i run the following command

…/…/src/openbabel-2.2.3/configure

to configure the makefiles for openbabel

then

make
sudo make install

which works flawlessly.

I can run babel -H and it shows me the available formats GAMESS, GAUSSIAN,
CML and lots of others. To confirm that openbabel is working, I also ran
obminize -ff MMFF94 with some random xyz file as argument and it starts to
minimize and thus it works with forcefields too. (yay)

I’ve also installed eigen (in a non standard location) as required (notice
that I have not attempted to build the avogadro+python binaries, but it’ll
come when I get this working)

Now I want to compile avogadro so I’ve download the 1.0.0 source from
sourceforge and extracted it in ~/software/src to get a
~/software/src/avogadro-1.0.0 folder.

If I am in the corresponding build folder (~/software/build/avogadro-1.0.0)
which I’ve created myself, and I run

cmake -DEIGEN2_INCLUDE_DIR=~/software/install/include/eigen2
-DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -DENABLE_PYTHON=false
-DCMAKE_OSX_ARCHITECTURES:STRING=i386 -DCMAKE_BUILD_TYPE=Debug
…/…/src/avogadro-1.0.0

It reports that it cannot find openbabel. I am then thinking: well, this is
a mac and I down know how your work compared to my ubuntu, so OK.

I then provide the following arguments to cmake

cmake -DCMAKE_OSX_ARCHITECTURES:STRING=i386 -DCMAKE_BUILD_TYPE=Debug
-DEIGEN2_INCLUDE_DIR=/Users/administrator/software/install/include/eigen2/
-DOPENBABEL2_INCLUDE_DIR=/usr/local/include/openbabel-2.0
-DOPENBABEL2_LIBRARIES=/usr/local/lib/libopenbabel.dylib
-DOPENBABEL2_VERSION_MET=true -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32
-DENABLE_PYTHON=false …/…/src/avogadro-1.0.0

in which case it runs, accepts the input and even states that it found the
openbabel executable in /usr/local/bin/babel.

I then run

make

and everything compiles and links like it should in which case I can assume
that the openbabel libraries are also correctly versioned and being 32 bit.

My problem then

if I go into ~/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS
and launch avogadro by

./Avogadro

I get the following output

"Avogadro version: 1.0.0 Git:
LibAvogadro version: 1.0.0 Git: “
Locale: “en_US"
Libavogadro translations not found.
“System has OpenGL support.”
“About to test OpenGL capabilities.”
“OpenGL capabilities found: “
“Double Buffering.”
“Direct Rendering.”
“Antialiasing.“
Loading plugins:
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/colors"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/engines"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/extensions"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/tools"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/contrib"
Loading plugins: "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/colors"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/engines"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/extensions"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/tools"
Searching for plugins in “/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/contrib”

The first problem is that this does not automatically load any plugins what
so ever ( I get a message box about it and i cant do anything). Apparently,
the libraries are not put into the Contents folder when everything is built.
I then browsed through the source code of avogadro to find out where stuff
gets loaded. I fell upon these lines in libavogadro/src/pluginmanager.cpp

// If we are in a Mac build dir things are a little different - if the
// expected relative path does not exist try the build dir path
QFileInfo info(QCoreApplication::applicationDirPath()
               + "/../CMakeCache.txt");
if (info.exists()) {// In a build directory
    loadPluginDir(QCoreApplication::applicationDirPath()
                  + "/../../../../lib", settings);
}

where it is assumed that a CMakeCache.txt file is located (which it
apparently not is since this is skipped) before it attempts to read
alternative locations. If i do

touch CMakeCache.txt

in the MacOS folder. Then the extensions, however, do load but other errors
are encountered:

"Avogadro version: 1.0.0 Git:
LibAvogadro version: 1.0.0 Git: “
Locale: “en_US"
Libavogadro translations not found.
“System has OpenGL support.”
“About to test OpenGL capabilities.”
“OpenGL capabilities found: “
“Double Buffering.”
“Direct Rendering.”
“Antialiasing.“
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/…/…/…/lib”
“libavogadro.1.0.0.dylib” failed to load. “The file
’/Users/administrator/software/build/avogadro-1.0.0/lib/libavogadro.1.0.0.dylib’
is not a valid Qt plugin.”
“libavogadro.1.dylib” failed to load. “The file
’/Users/administrator/software/build/avogadro-1.0.0/lib/libavogadro.1.0.0.dylib’
is not a valid Qt plugin.”
“libavogadro.dylib” failed to load. “The file
’/Users/administrator/software/build/avogadro-1.0.0/lib/libavogadro.1.0.0.dylib’
is not a valid Qt plugin.“
Loading plugins:
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/colors"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/engines"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/extensions"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/tools"
Searching for plugins in
”/Users/administrator/software/build/avogadro-1.0.0/bin/Avogadro.app/Contents/MacOS/…/lib/avogadro/1_0/contrib"
Loading plugins: "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/colors"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/engines"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/extensions"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/tools"
Searching for plugins in "/Users/administrator/Library/Application
Support/avogadro/1_0/Plugins/contrib"
QStackedLayout::setCurrentWidget: Widget 0x1b93270 not contained in stack
Unable to set up and use any force fields.
GLWidget initialisation…
GLWidget initialised…
createObjects()
libpng warning: Ignoring attempt to set cHRM RGB triangle with zero area

where the most fatal one is “Unable to set up and use any force fields.”. So
I can draw molecules. load molecules, but the force-fields do not get loaded
and I simply cant figure out why. On the wiki:
http://avogadro.openmolecules.net/wiki/Compiling_on_Linux_and_Mac_OS_X - the
following lines are the only ones I could hope help

export BABEL_LIBDIR=/usr/local/lib/openbabel/2.2.3/
export BABEL_DATADIR=/usr/local/share/openbabel/2.2.3/

but alas, no effect what so ever.

Now, I have no clue how to continue from here since it appears that
openbabel is working (but not inside avogadro) and avogadro is working with
its tools.

Any help is appreciated

Kind Regards,
Casper Steinmann

Hi all.

It never occured to me that pkg-config is not installed on the Mac !
I have just compiled pkg-config-0.23 from “http://pkgconfig.freedesktop.org/releases/”,
using default configure.
The “openbabel-2.0.pc” file in “/usr/local/lib/pkgconfig” is now detected
and Avo configuration is simply accomplished with:
“CXX=g+±4.0 CC=gcc-4.0 cmake -DCMAKE_OSX_ARCHITECTURES=“i386”
-DENABLE_PYTHON=false …”,
no sweat.

It may be worth mentioning on the wiki page.

Cheers,

Louis

Le 8 déc. 2009 à 19:18, Geoffrey Hutchison a écrit :

CMake Error at cmake/modules/MacroEnsureVersion.cmake:95 (NORMALIZE_VERSION):
NORMALIZE_VERSION Macro invoked with incorrect arguments for macro named:
NORMALIZE_VERSION

Hmm. I’ll investigate this next. I have been building the Avogadro “superpackage,” and I haven’t seen this bug. I’ll see if I can fix it momentarily.

-Geoff

Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options