Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:16 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote: > > without any problem. Howeber, when I try to compile the project in OSX, I can > compile the libs, one exec but it fails with the first plugin. I have > isolated the problem in this: > > Linking CXX shared library libpluginregistrodeiva.dylib > Undefined symbols: > > I don't have any special consideration with the OSX platform (CMake is > wonderfull, isn't it?) but it fails in this. It seems that the compiler, when > link the plugin try to find anything that doesn't find (in linux it finds...) I wonder if this is the "Apple linker always prefers dynamic libs" problem. Search the mailing list archives for that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
> On Jan 16, 2008 12:16 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]>
wrote:
> > without any problem. Howeber, when I try to compile the project in OSX, I
> > can compile the libs, one exec but it fails with the first plugin. I have
> > isolated the problem in this:
> >
> > Linking CXX shared library libpluginregistrodeiva.dylib
> > Undefined symbols:
> >
> > I don't have any special consideration with the OSX platform (CMake is
> > wonderfull, isn't it?) but it fails in this. It seems that the compiler,
> > when link the plugin try to find anything that doesn't find (in linux it
> > finds...)
>
> I wonder if this is the "Apple linker always prefers dynamic libs"
> problem. Search the mailing list archives for that.
I have this:
add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
set_target_properties( ${plugin} PROPERTIES
SOVERSION "${BULMAGES_VERSION_MAJOR}.${BULMAGES_VERSION_MINOR}"
VERSION "${BULMAGES_VERSION}")
the plugin is shared ...
I don't know what are your reffering to search in the mailing list because I
have done some search without any interesting result.
Best regards,
Leo
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:45 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote:
> A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
> >
> > I wonder if this is the "Apple linker always prefers dynamic libs"
> > problem. Search the mailing list archives for that.
>
> I have this:
>
> add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
> ${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
Well, if you're only using shared libs and no static libs, then I have
guessed wrongly about your problem.
> I don't know what are your reffering to search in the mailing list because I
> have done some search without any interesting result.
If you do have any static libs in your build, then try the keywords
"Apple shared static depreciated".
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
Leopold Palomo-Avellaneda wrote: Hi, I'm one of the developers of a free software project [1]. I have made the transition from qmake to cmake. The project has several targets (one lib and 3 exes, and a lot of plugins). I can compile the whole project in a GNU/Linux box with: mkdir build cd build cmake ../ make without any problem. Howeber, when I try to compile the project in OSX, I can compile the libs, one exec but it fails with the first plugin. I have isolated the problem in this: Linking CXX shared library libpluginregistrodeiva.dylib Undefined symbols: I don't have any special consideration with the OSX platform (CMake is wonderfull, isn't it?) but it fails in this. It seems that the compiler, when link the plugin try to find anything that doesn't find (in linux it finds...) So, please, have I to make some special consideration about qt, plugins in MacOSX? Have I to put some directive, or property when I compile a plugin in OSX? It might be helpful to know what the undefined symbols are... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Bill Hoffman va escriure: > Leopold Palomo-Avellaneda wrote: > > Hi, > > > > I'm one of the developers of a free software project [1]. I have made the > > transition from qmake to cmake. The project has several targets (one lib > > and 3 exes, and a lot of plugins). > > > > I can compile the whole project in a GNU/Linux box with: > > > > mkdir build > > cd build > > cmake ../ > > make > > > > without any problem. Howeber, when I try to compile the project in OSX, I > > can compile the libs, one exec but it fails with the first plugin. I have > > isolated the problem in this: > > > > Linking CXX shared library libpluginregistrodeiva.dylib > > Undefined symbols: > > > > I don't have any special consideration with the OSX platform (CMake is > > wonderfull, isn't it?) but it fails in this. It seems that the compiler, > > when link the plugin try to find anything that doesn't find (in linux it > > finds...) > > > > So, please, have I to make some special consideration about qt, plugins > > in MacOSX? > > > > Have I to put some directive, or property when I compile a plugin in OSX? > > It might be helpful to know what the undefined symbols are... the system is: $ uic -v Qt User Interface Compiler version 4.3.3 $ moc -v Qt Meta Object Compiler version 59 (Qt 4.3.3) $ g++ -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] [^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) and the error is in the plugin (or whatever plugin) Linking CXX shared library libpluginregistrodeiva.dylib Undefined symbols: "aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)", referenced from: linprevcobro::creaPago() in linprevcobro.o "aplinteligentesview::setfechaasiento(QString)", referenced from: linprevcobro::creaPago() in linprevcobro.o "regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced from: ListRegistroIvaView::boton_print() in listregistroivaview.o "BusquedaCuenta::BusquedaCuenta(QWidget*)", referenced from: Ui_CobroPagoBase::setupUi(QWidget*) in cobropagoview.o Ui_RegistroIvaBase::setupUi(QWidget*) in registroivaview.o "aplinteligentesview::inicializa(int)", referenced from: linprevcobro::creaPago() in linprevcobro.o "FichaBc::FichaBc(Empresa*, QWidget*, QFlags)", referenced from: RegistroIva::RegistroIva(Empresa*, QWidget*)in registroiva.o "aplinteligentesview::setvalores(QString, QString)", referenced from: linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o "Asiento1View::muestraasiento(int)", referenced from: ListLinPrevCobroView::contextMenu(int, int, QPoint const&)in listlinprevcobroview.o ListRegistroIvaView::on_mui_tablasoportado_cellDoubleClicked(int, int)in listregistroivaview.o ListRegistroIvaView::on_mui_tablarepercutido_cellDoubleClicked(int, int)in listregistroivaview.o ListRegistroIvaView::on_mui_tablasoportado_trataMenu(QAction*) in listregistroivaview.o ListRegistroIvaView::on_mui_tablarepercutido_trataMenu(QAction*) in listregistroivaview.o "Bulmacont::empresaactual()", referenced from: myRegIVA::elslot() in pluginregistroiva.o myRegIVA::elslot() in pluginregistroiva.o myRegIVA::elslot1() in pluginregistroiva.o myRegIVA::elslot1() in pluginregistroiva.o "Empresa::numdigitosempresa()", referenced from: linprevcobro::setcodigocuenta(QString) in linprevcobro.o linprevcobro::setcodigoctacliente(QString) in linprevcobro.o "FichaBc::qt_metacall(QMetaObject::Call, int, void**)", referenced from: vtable for RegistroIvain registroiva.o RegistroIvaView::qt_metacall(QMetaObject::Call, int, void**)in moc_registroivaview.o "Asiento1::companyact()", referenced from: _Asiento1_guardaAsiento1_post in pluginregistroiva.o "FichaBc::empresaBase()", referenced from: vtable for RegistroIvain registroiva.o RegistroIvaView::RegistroIvaView(Empresa*, QWidget*)in registroivaview.o vtable for RegistroIvaViewin moc_registroivaview.o "SubForm2Bc::SubForm2Bc(QWidget*)", referenced from: Ui_CobroPagoBase::setupUi(QWidget*) in cobropagoview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistro
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
> On Jan 16, 2008 12:45 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]>
wrote:
> > A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
> > > I wonder if this is the "Apple linker always prefers dynamic libs"
> > > problem. Search the mailing list archives for that.
> >
> > I have this:
> >
> > add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
> > ${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
>
> Well, if you're only using shared libs and no static libs, then I have
> guessed wrongly about your problem.
:-)
I really wanted that you had guessed correctly, but very thanks for trying it.
I'm not a OSX programmer ...
> > I don't know what are your reffering to search in the mailing list
> > because I have done some search without any interesting result.
>
> If you do have any static libs in your build, then try the keywords
> "Apple shared static depreciated".
Nops, any static lib. I will try.
Best regards,
Leo
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
Leopold Palomo-Avellaneda wrote: A Dimecres 16 Gener 2008, Bill Hoffman va escriure: Leopold Palomo-Avellaneda wrote: Linking CXX shared library libpluginregistrodeiva.dylib Undefined symbols: "aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)", referenced from: linprevcobro::creaPago() in linprevcobro.o "aplinteligentesview::setfechaasiento(QString)", referenced from: linprevcobro::creaPago() in linprevcobro.o "regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced from: ListRegistroIvaView::boton_print() in listregistroivaview.o OK, so all these symbols are from your stuff. I think I know the problem. Linux allows for shared libraries to have undefined symbols, and the mac does not. You need to add some target_link_libraries(libpluginregistrodeiva ...) Stuff into your cmake file. My guess is that if you went on to a linux system, and did nm on the .so , you would find these symbols are also undefined. I think there is a flag like -undefined suppress or something that you can pass to the mac linker to make it work more like linux. However, if you ever want to go to windows you will have to figure this out as there is no such flag on Windows. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
> Leopold Palomo-Avellaneda wrote:
> > A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
> >> Leopold Palomo-Avellaneda wrote:
> >
> > Linking CXX shared library libpluginregistrodeiva.dylib
> > Undefined symbols:
> > "aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)",
> > referenced from:
> > linprevcobro::creaPago() in linprevcobro.o
> > "aplinteligentesview::setfechaasiento(QString)", referenced from:
> > linprevcobro::creaPago() in linprevcobro.o
> > "regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced
> > from: ListRegistroIvaView::boton_print() in listregistroivaview.o
>
> OK, so all these symbols are from your stuff. I think I know the
> problem. Linux allows for shared libraries to have undefined symbols,
> and the mac does not. You need to add some
> target_link_libraries(libpluginregistrodeiva ...)
>
> Stuff into your cmake file.
I have it .
target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} ${PGSQL_LIBRARIES})
> My guess is that if you went on to a linux system, and did nm on the .so
> , you would find these symbols are also undefined. I think there is a
> flag like -undefined suppress or something that you can pass to the mac
> linker to make it work more like linux. However, if you ever want to go
> to windows you will have to figure this out as there is no such flag on
> Windows.
yes, I agree.
But how I can manage or protect this kind of stuff of different platforms.
Best regards,
Leo
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 1:05 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote: > "non-virtual thunk to FichaBc::empresaBase()", referenced from: > vtable for RegistroIvain registroiva.o > vtable for RegistroIvaViewin moc_registroivaview.o I've seen these types of errors before if you're mixing and matching g++'s (ie, your Qt was built with g++-3.3, but you're compiling using g++-4.0, or vice-versa). Not saying that's the problem, but it could be it... -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Benjamin Reed va escriure: > On Jan 16, 2008 1:05 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote: > > "non-virtual thunk to FichaBc::empresaBase()", referenced from: > > vtable for RegistroIvain registroiva.o > > vtable for RegistroIvaViewin moc_registroivaview.o > > I've seen these types of errors before if you're mixing and matching > g++'s (ie, your Qt was built with g++-3.3, but you're compiling using > g++-4.0, or vice-versa). > > Not saying that's the problem, but it could be it... nops all the stuff are compiled (qt, postgres and my app with the same compiler). But, thanks. Best regards, Leo ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008, at 1:36 PM, Leopold Palomo-Avellaneda wrote:
A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
Leopold Palomo-Avellaneda wrote:
A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
Leopold Palomo-Avellaneda wrote:
Linking CXX shared library libpluginregistrodeiva.dylib
Undefined symbols:
"aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)",
referenced from:
linprevcobro::creaPago() in linprevcobro.o
"aplinteligentesview::setfechaasiento(QString)", referenced from:
linprevcobro::creaPago() in linprevcobro.o
"regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced
from: ListRegistroIvaView::boton_print() in
listregistroivaview.o
OK, so all these symbols are from your stuff. I think I know the
problem. Linux allows for shared libraries to have undefined symbols,
and the mac does not. You need to add some
target_link_libraries(libpluginregistrodeiva ...)
Stuff into your cmake file.
I have it .
target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} $
{PGSQL_LIBRARIES})
I think you either need more libraries in the above statement or
you are not compiling enough source files into the bulmalib library.
For instance where is aplinteligentesview defined? Is is a part of
the bulmalib library?
My guess is that if you went on to a linux system, and did nm on
the .so
, you would find these symbols are also undefined. I think there
is a
flag like -undefined suppress or something that you can pass to
the mac
linker to make it work more like linux. However, if you ever want
to go
to windows you will have to figure this out as there is no such
flag on
Windows.
yes, I agree.
But how I can manage or protect this kind of stuff of different
platforms.
Best regards,
Leo
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Wednesday 16 January 2008 11:05:04 am Leopold Palomo-Avellaneda wrote: > > Linking CXX shared library libpluginregistrodeiva.dylib > Undefined symbols: [snip] > "FichaBc::qt_metacall(QMetaObject::Call, int, void**)", referenced from: > vtable for RegistroIvain registroiva.o > RegistroIvaView::qt_metacall(QMetaObject::Call, int, void**)in > moc_registroivaview.o Unresolved vtables in Qt code usually means you forgot to run moc on the header file and include it in the build. If that's it, it can be done by the QT4_WRAP_CPP macro. On Linux, you might see that problem at run time with a crash. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Mike Jackson va escriure:
> On Jan 16, 2008, at 1:36 PM, Leopold Palomo-Avellaneda wrote:
> > A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
> >> Leopold Palomo-Avellaneda wrote:
> >>> A Dimecres 16 Gener 2008, Bill Hoffman va escriure:
> Leopold Palomo-Avellaneda wrote:
> >>>
> >>> Linking CXX shared library libpluginregistrodeiva.dylib
> >>> Undefined symbols:
> >>> "aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)",
> >>> referenced from:
> >>> linprevcobro::creaPago() in linprevcobro.o
> >>> "aplinteligentesview::setfechaasiento(QString)", referenced from:
> >>> linprevcobro::creaPago() in linprevcobro.o
> >>> "regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced
> >>> from: ListRegistroIvaView::boton_print() in
> >>> listregistroivaview.o
> >>
> >> OK, so all these symbols are from your stuff. I think I know the
> >> problem. Linux allows for shared libraries to have undefined symbols,
> >> and the mac does not. You need to add some
> >> target_link_libraries(libpluginregistrodeiva ...)
> >>
> >> Stuff into your cmake file.
> >
> > I have it .
> >
> > target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} $
> > {PGSQL_LIBRARIES})
>
> I think you either need more libraries in the above statement or
> you are not compiling enough source files into the bulmalib library.
> For instance where is aplinteligentesview defined? Is is a part of
> the bulmalib library?
I'm compiling a plugin for the bulmacont app. Bulmacont is linked against
bulmalib.
aplinteligentesview is defined in bulmacont src and it's not a part of
bulmalib.
Regards,
Leo
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, [EMAIL PROTECTED] va escriure:
> On Wednesday 16 January 2008 11:05:04 am Leopold Palomo-Avellaneda wrote:
> > Linking CXX shared library libpluginregistrodeiva.dylib
> > Undefined symbols:
>
> [snip]
>
> > "FichaBc::qt_metacall(QMetaObject::Call, int, void**)", referenced
> > from: vtable for RegistroIvain registroiva.o
> > RegistroIvaView::qt_metacall(QMetaObject::Call, int, void**)in
> > moc_registroivaview.o
>
> Unresolved vtables in Qt code usually means you forgot to run moc on the
> header file and include it in the build. If that's it, it can be done by
> the QT4_WRAP_CPP macro. On Linux, you might see that problem at run time
> with a crash.
I fill the moc files by a glob. I thought it, but I didn't find any crash .
The complete CMakeList is:
###
# Plugin for bulmacont#
###
#pluginregistrodeiva
set (plugin pluginregistrodeiva)
file(GLOB plugin_SRC *.c *.cpp *.cxx)
file(GLOB plugin_MOCS *.hpp *.h)
file(GLOB plugin_UIS *.ui)
set(QT_USE_QTASSISTANT true)
set(QT_USE_QTXML true)
INCLUDE( ${QT_USE_FILE} )
include_directories(
${QT_INCLUDE_DIR}
${PGSQL_INCLUDE_DIR}
${QT_QTXML_INCLUDE_DIR}
${QT_QTASSISTANT_INCLUDE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_BINARY_DIR}/bulmalib/src/
${CMAKE_SOURCE_DIR}/bulmalib/src/
${CMAKE_BINARY_DIR}/bulmacont/src/
${CMAKE_SOURCE_DIR}/bulmacont/src/)
# generate rules for building source files that moc generates
QT4_WRAP_UI(plugin_UIS_H ${plugin_UIS})
QT4_WRAP_CPP(plugin_MOC_SRCS ${plugin_MOCS})
#ADD_DEFINITIONS(${QT_DEFINITIONS})
ADD_DEFINITIONS(-DQT_SHARED)
# build sources, moc'd sources, and rcc'd sources
add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
set_target_properties( ${plugin} PROPERTIES
SOVERSION "${BULMAGES_VERSION_MAJOR}.${BULMAGES_VERSION_MINOR}"
VERSION "${BULMAGES_VERSION}")
target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} ${PGSQL_LIBRARIES})
install_targets(/lib/bulmacont/plugins ${plugin})
add_dependencies(${plugin} bulmacont bulmalib)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 2:11 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > I think that is your problem. If you plugin is ONLY linking against > bulmalib BUT aplinteligentesview is defined in bulmacont executable, > then the linking for the plugin will NOT be possible because the > plugin is looking for aplinteligentesview in the bulmalib but it is > really located in bulmacont executable. Make sense? Right. Mac OS X is much stricter than most *NIXen about symbol reslution. It is possible to work around it, but better (and more portable) to make sure all symbols exist at link time, between any of the things you're linking. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
A Dimecres 16 Gener 2008, Benjamin Reed va escriure: > On Jan 16, 2008 2:11 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > > I think that is your problem. If you plugin is ONLY linking against > > bulmalib BUT aplinteligentesview is defined in bulmacont executable, > > then the linking for the plugin will NOT be possible because the > > plugin is looking for aplinteligentesview in the bulmalib but it is > > really located in bulmacont executable. Make sense? > > Right. Mac OS X is much stricter than most *NIXen about symbol > reslution. It is possible to work around it, but better (and more > portable) to make sure all symbols exist at link time, between any of > the things you're linking. Mike, I think that you rock it. And Benjamin you confirmed it. I suppose that if I define the classes as extern will not solve the problem, no? Well, we will rearrange some code to have a full cross platform. Best regards and very thanks to all. Leo ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 2:28 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote: > I think that you rock it. And Benjamin you confirmed it. I suppose that if I > define the classes as extern will not solve the problem, no? If you link with "-undefined dynamic_lookup" I think it should work, although in an ideal world you'd put it in the library instead of the binary so you wouldn't have to. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008, at 2:05 PM, Leopold Palomo-Avellaneda wrote:
I have it .
target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} $
{PGSQL_LIBRARIES})
I think you either need more libraries in the above statement or
you are not compiling enough source files into the bulmalib library.
For instance where is aplinteligentesview defined? Is is a part of
the bulmalib library?
I'm compiling a plugin for the bulmacont app. Bulmacont is linked
against
bulmalib.
aplinteligentesview is defined in bulmacont src and it's not a part of
bulmalib.
I think that is your problem. If you plugin is ONLY linking against
bulmalib BUT aplinteligentesview is defined in bulmacont executable,
then the linking for the plugin will NOT be possible because the
plugin is looking for aplinteligentesview in the bulmalib but it is
really located in bulmacont executable. Make sense?
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
