On 03/12/12 23:16, Jeff Kearns wrote:
Hi, I'm having a build problem with Clam 1.4.1~svn15308 on my iMac. I'm using
QT 4.8.4 library frameworks and tools and all 64-bit dependencies. Llvm-g++-4.2
compiler
Well I have a very limited experience dealing with the multiple
architectures and compilers in Mac. So it would be helpful if some of
the past Mac based CLAMers jump in the thread.
Ill do my best but keep in mind i am just figuring out things. I am glad
someone giving a try again to mac compilation.
. The 3 Clam libraries all compiled just fine. So on to Network Editor. At
first, the build halted trying to link the first library target:
libclam_qtmonitors.1.4.1.dylib :
Undefined symbols for architecture x86_64:
"_glBegin", referenced from:
CLAM::VM::Tonnetz::DrawTile(int, int)in Tonnetz.os
QFirstPerson::roomWall(float, float)in moc_QFirstPerson.os
QFirstPerson::paintDecoration() in moc_QFirstPerson.os
"_glBlendFunc", referenced from:
CLAM::VM::Tonnetz::initializeGL() in Tonnetz.os
QFirstPerson::initializeGL() in moc_QFirstPerson.os
"_glColor4fv", referenced from:
QFirstPerson::paintDecoration() in moc_QFirstPerson.os
QFirstPerson::paintScene() in moc_QFirstPerson.os …..
… 38 more missing _gl** symbols, all referenced from moc_QFirstPerson.os
Well, that's because on OSX 10.8.2 the only place those symbols exist is in libGL.1.dylib
and libGLU.1.dylib , which both must be added to the final link step. Those symbols are NOT
in OpenGL.framework,OpenAL.framework, in any of the 10.5 to 10.8 MacSDKs, or in the new
XCode IDE. Only in the new X11-quartz library package as dylibs. In fact, the build stopped
earlier when <GL/Glu.h> was not found from QFirstPerson.hxx. Which is when I pointed
it to </opt/X11/include/Glu.h>. Also by the way,that ('/opt') does not suggest I use
MacPorts or anything nasty like that, that's where Apple installs the new X11 quartz pkg,
sym-linking the pre-existing /usr/X11 folder. So I built libclam_qtmonitors from the
command line by simply adding -L/opt/X11/lib -lGL -lGLU. Glad I had verbose enabled for the
full gcc string.
Sounds reasonable. In general, QtOpenGl (qt4.py scons tool) should
provide GL as well as dependency.
For GLU in SConstruct (lines 132-144) we explicitly add it for Windows
and Linux. But there is no code for Mac. The problem here again is that
we don't have a machine to test it. As you see in those lines the rule
of thumb is use the pkg-config file if available, if not, explicitly add
the options.
So, next target is src/clamWidgetsPlugin. I tried scons -k to see where it
thought it was and to see further output. All 19 *.hxx in the folder fail to
generate the moc, with the same error.
Scons output:
moc
-I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-I/opt/local/include -I/usr/local/include -I/opt/gtk/audio-96/include
-I/Library/Frameworks/QtCore.framework/headers
-I/Library/Frameworks/QtGui.framework/headers
-I/Library/Frameworks/QtOpenGL.framework/headers
-I/Library/Frameworks/QtXml.framework/headers
-I/Library/Frameworks/QtSvg.framework/headers
-I/Library/Frameworks/QtUiTools.framework/headers
-I/Library/Frameworks/QtDesigner.framework/headers
-I/Library/Frameworks/QtWebKit.framework/headers
-I/Library/Frameworks/QtNetwork.framework/headers
-I/Library/Frameworks/QtXmlPatterns.framework/headers -o
src/clamWidgetsPlugin/generated/moc_KeySpacePlugin.cxx
src/clamWidgetsPlugin/KeySpacePlugin.hxx ----
src/clamWidgetsPlugin/KeySpacePlugin.hxx:33: Error: Undefined interface
scons: ** [src/clamWidgetsPlugin/generated/moc_KeySpacePlugin.cxx]Error 1..
src/clamWidgetsPlugin/CLAMWidgets.hxx:10: Error: Undefined interface
scons: ** [src/clamWidgetsPlugin/generated/moc_CLAMWidgets.cxx] Error 1..
src/clamWidgetsPlugin/QFirstPersonPlugin.hxx:33: Error: Undefined interface
scons: *** [src/clamWidgetsPlugin/generated/moc_QFirstPersonPlugin.cxx] Error 1
etc
Looks defined to me, they all have Q_INTERFACES(QDesignerCustomWidgetInterface), and
<QtDesigner/customwidget.h> sure looks to declare them.
Scons has cheese documentation IMHO, how does one know whether it's going to
start all over when invoked or resume after a error is corrected? Can it list
targets like make or CMake? Also, where in your Sconstruct can I add the libGL
and libGLU dependencies so I can rebuild without having it halt with the first
target.
(Didn't one use to need a Sconstruct in each subfolder?)
I used to get those same missleading errors from moc. Although it seems
to compile about 'defined interface' it is more related to the
availability or not of certain headers, that is the cpppath which for
moc is controled by QT4_MOCCPPPATH. The solution was usualily to copy
the values from CPPPATH. But maybe that's not working for mac.
By the way, in your Sconstruct ln:30 for the Clam Libs, there's a comment for
opts.Add( 'LINKFLAGS'..) that mentions adding OPenGL.framework for OSX, well
those libs don't need it, Network Editor does, only NOT the frameworks, the X11
dylibs.If your building with the GL includes you kind of need to link the
library. At least on 10.8 Mountain Lion. Can one declare options on the command
line (LDFlags?) when invoking scons or only when sconstruct knows what to do
with them? Or in ENV?
That comment is quite old. Many versions ago before we decoupled the
core from any gui thing. I guess it has no sense now at least for the
core libraries. since then mac compilation has changed a lot. Indeed
every time some mac user says he is compiling for mac they seem to
follow different strategies (macports dependencies vs framworks,
native/x11/macports qt, xcode....)
So at this point I could use some advice about my undefined interface for the
clamWidgetsPlugin sources.
I built this project several years ago on a PPC ibook, scons gave me a headache
the, now with a new Qt, new OS, a bs Xcode update and whatelse, I want to
bring it up to date. Know anyone who has built this on 64 bit 10.8?
Not that i know. From time to time a mac user appears trying to compile
clam and sometimes achieving it. People using clam in mac should join
efforts to define a clear and repeatable installation. That's something
i cannot do myself, poor linux user. :-)
Thanks, Jeff K
PS; Your tarball release won't build on 10.8 and never will. Xerces with DOMWriter cannot be compiled, I noticed you canned it too in CVS.
There is an option to choose which xml backend you want to compile:
xercesc, libxml++, or both. Choosing just the later would be enough to
go forward.
Actually, CVS won't even start to compile as long as EmbeddedFile.hxx only allows
__MINGW32__ and __ELF__ or #error "No support for embedded files in your
platform" pops up. We'll see about that.
If you know how to generate in mac a binary object with a data section
with the content of a file and addressable as symbol I will celebrate that.
We were working on a solution with a guy who helped me to try things in
mac but as you may imagine it was a hard workflow and at some point we
stopped. I have in local an almost working code which i don't know
whether is architecture specific. Maybe that was the last problem we
didn't manage to solve.
The snippet looks like this:
#elif defined __MACH__ && defined __APPLE__
#define CLAM_EMBEDDED_FILE(varname, file) \
asm ( \
".cstring \n" \
" .globl _" #varname " \n" \
"_" #varname ": \n" \
" .asciz "mycontent" \n" \
" .byte 0 \n" \
"_" #varname "_end: \n" \
); \
extern const char varname[];
but as i said, not even sure that it worked.
_______________________________________________
clam-devel mailing list
clam-devel@lists.clam-project.org
http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org
