wxvtk-users

[wxVTK] Installing wxVTK

[Andrey S. <sky...@gm...>]

Hi all,

I am having some trouble linking the samples provided with wxVTK.
Could somebody please point me to a reference that explains:

- how one should install wxWidgets in order for it to work with wxVTK
- how one should install VTK to have it work with wxVTK
- how to compile and link the sample programs provided with wxVTK using cmake
- what wxWidgets_CONFIG_EXECUTABLE and wxWidgets_wxrc_EXECUTABLE are
- how to have cmake find those directories automatically

For anyone who wants to know more about what I did specifically to
come up with these questions, a detailed description is below.

- Andrey

Details:
-----------------------------------------------------
I'm running cygwin 1.5.25 on Windows XP.
I'm using
- g++ version 3.4.4 (sygming special, gdc 0.12, using dmd 0.125)
- cmake version 2.6-patch 2
- VTK 5.2.0
- wxWidgets version 2.8


VTK Setup
-----------------------------------------------------
I installed VTK on 10/29/2008.  I am able to run the sample programs
that came with it.


wxWidgets Setup
-----------------------------------------------------
I acquired and compiled wxWidgets following directions on
http://wiki.wxwidgets.org/Cygwin

I entered this in the shell (following the "To get an executable
independent of Cygwin DLL" directions)

$ cvs -d :pserver:an...@cv...:/pack/cvsroots/wxwidgets
checkout -r WX_2_8_BRANCH wxMSW
$ cd wxWidgets
$ export CFLAGS=-mno-cygwin
$ export CPPFLAGS=-mno-cygwin
$ export CXXFLAGS=-mno-cygwin
$ export LDFLAGS="-mno-cygwin -mwindows"
$ ./configure --with-msw --enable-debug --enable-debug_gdb
--disable-shared --with-libjpeg=builtin --disable-precomp-headers
--without-expat
$ make

I downloaded the provided hworld.cpp and successfully generated the GUI.


wxVTK Setup
-----------------------------------------------------
I then proceeded to try to get wxVTK to work.
I downloaded wxVTK from

http://sourceforge.net/project/showfiles.php?group_id=114757&package_id=124328&release_id=603693

and extracted it to ~/wxVTK

I then copied all the files needed for compiling the samples to a new
directory and did an out of source build using cmake

$ mkdir ~/test
$ cd ~/test
$ mkdir src
$ mkdir bin
$ cd ~/wxVTK
$ cp -r src/ Sample/ CMakeLists.txt ~/test/src
$ cd ~/test/bin
$ ccmake ../src

This lead to the first stopping point.  There were two variables:

wxWidgets_CONFIG_EXECUTABLE
wxWidgets_wxrc_EXECUTABLE

That are not described or explained anywhere (google or otherwise).  I
ended up looking through the FindwxWidgets.cmake module in both

~/wxVTK/Modules
/usr/share/cmake-2.6.2/Modules

The one that came with cmake had a little bit of an explanation as to
what the parameters were.  I ended up running make install on both vtk
and wxWidgets so that they would be in directories the script would
look in (on the path).  In the end, I got that

wxWidgets_CONFIG_EXECUTABLE = /usr/local/bin/wx-config
which is a pointer to usr/ocal/lib/wx/config/msw-ansi-debug-static-2.8
- what is this and why is it needed for using wxWidgets?

Getting a value for wxWidgets_wxrc_EXECUTABLE was harder.  Using
FindwxWidgets.cmake that came with wxVTK, it just kept telling me
"Cannot find wxWidgets libraries and/or header files."  Using the
FindwxWidgets.cmake that came with cmake accepted /usr/local/lib/wx,
/usr/local/include/wx-2.8/wx, /usr/local/include/wx-2.8, it doesn't
seem to care what you put there.  I expect that this is where my
problems are coming from.  In the end I kept

wxWidgets_wxrc_EXECUTABLE = /usr/local/include/wx-2.8

I generated the make file and ran make.  It wxImagePlaneWidgets.cxx
and then wxVTKRenderWindowInteractor.cxx, then tried to link them, and
spewed a lot of errors concerning ___assert and ___errno.
Unfortunately I didn't save the errors and have recompiled wxWindows
since then and don't want to spend a third hour recompiling that
library.  Upon examining wxVTKRenderWindowInteractor.cxx I saw that it
used <assert.h> and the assert macro.  It seemed like the linker
wasn't linking libc because I compiled wxWidgets with -mno-cygwin,
thus leading to ___assert and ___errno not being found when linking.

I recompiled wxWidgets without the -mno-cygwin flags.  I used these
commands in the wxWidgets directory:
$ ./configure --with-msw --enable-debug --enable-debug_gdb
--disable-shared --with-libjpeg=builtin
$ make

The ___assert and ___errno errors promptly disappeared, but the linker
is still complaining.  I tried building the samples again using the
same cmake configuration as before and I am currently received the
warning

/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line.
This should work unless it involves constant data structures
referencing symbols from auto

Seems like it didn't work... The full error message is below:

$ make
Scanning dependencies of target wxImagePlaneWidget
[ 10%] Building CXX object
CMakeFiles/wxImagePlaneWidget.dir/Sample/wxImagePlaneWidget.cxx.o
[ 20%] Building CXX object
CMakeFiles/wxImagePlaneWidget.dir/src/wxVTKRenderWindowInteractor.cxx.o
Linking CXX executable bin/wxImagePlaneWidget.exe
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line.
This should work unless it involves constant data structures
referencing symbols from auto
-imported DLLs./usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/.
/src/msw/window.cpp:1340: undefined reference to
`wxSystemOptions::GetOptionInt(wxString const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3956:
undefined reference to `_wxEVT_POWER_SUSPENDING'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3960:
undefined reference to `_wxEVT_POWER_SUSPEND_CANCEL'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3964:
undefined reference to `_wxEVT_POWER_SUSPENDED'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3971:
undefined reference to `_wxEVT_POWER_RESUME'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_wincmn.o): In function
`wxWindowBase':/usr/src/wxWidgets/./src/common/wincmn.cpp:212:
undefined reference to `wxSystemOptions::HasOption(wxString const&)'
/usr/src/wxWidgets/./src/common/wincmn.cpp:214: undefined reference to
`wxSystemOptions::GetOptionInt(wxString const&)'
/usr/src/wxWidgets/./src/common/wincmn.cpp:212: undefined reference to
`wxSystemOptions::HasOption(wxString const&)'
/usr/src/wxWidgets/./src/common/wincmn.cpp:214: undefined reference to
`wxSystemOptions::GetOptionInt(wxString const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_colourcmn.o): In function
`_ZlsR9wxVariantRK8wxColour':
/usr/src/wxWidgets/./src/common/colourcmn.cpp:141: undefined reference
to `wxVariant::SetData(wxVariantData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_colourcmn.o): In function
`__static_initialization_and_destruction_0':
/usr/src/wxWidgets/./src/common/colourcmn.cpp:29: undefined reference
to `wxVariantData::ms_classInfo'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_colourcmn.o): In function
`~wxVariantData':
/usr/src/wxWidgets/./include/wx/variant.h:99: undefined reference to
`vtable for wxVariantData'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_colourcmn.o): In function
`wxVariantData':
/usr/src/wxWidgets/./include/wx/variant.h:68: undefined reference to
`vtable for wxVariantData'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_font.o):/usr/src/wxWidgets/./src/msw/font.cpp:431:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_dc.o):/usr/src/wxWidgets/./src/msw/dc.cpp:1213:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_dc.o):/usr/src/wxWidgets/./src/msw/dc.cpp:2138:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_tbar95.o):/usr/src/wxWidgets/./src/msw/tbar95.cpp:570:
undefined reference to `wxSystemOptions::HasOption(wxString const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_tbar95.o):/usr/src/wxWidgets/./src/msw/tbar95.cpp:570:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_statbox.o):/usr/src/wxWidgets/./src/msw/statbox.cpp:211:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_statbox.o):/usr/src/wxWidgets/./include/wx/sysopt.h:40:
undefined reference to `wxSystemOptions::HasOption(wxString const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_statbox.o):/usr/src/wxWidgets/./include/wx/sysopt.h:40:
undefined reference to `wxSystemOptions::GetOptionInt(wxString
const&)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o): In function
`~wxSizer':/usr/src/wxWidgets/./src/common/sizer.cpp:509: undefined
reference to `wxClientDataContainer::~wxClientDataContainer()'
/usr/src/wxWidgets/./src/common/sizer.cpp:509: undefined reference to
`wxClientDataContainer::~wxClientDataContainer()'
/usr/src/wxWidgets/./src/common/sizer.cpp:509: undefined reference to
`wxClientDataContainer::~wxClientDataContainer()'
/usr/src/wxWidgets/./src/common/sizer.cpp:509: undefined reference to
`wxClientDataContainer::~wxClientDataContainer()'
/usr/src/wxWidgets/./src/common/sizer.cpp:509: undefined reference to
`wxClientDataContainer::~wxClientDataContainer()'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):/usr/src/wxWidgets/./src/common/sizer.cpp:509:
more undefined references to
`wxClientDataContainer::~wxClientDataContainer()'
follow
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o): In function `wxSizer':
/usr/src/wxWidgets/./include/wx/sizer.h:410: undefined reference to
`wxClientDataContainer::wxClientDataContainer()'
/usr/src/wxWidgets/./include/wx/sizer.h:410: undefined reference to
`wxClientDataContainer::~wxClientDataContainer()'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV16wxStaticBoxSizer[vtable
for wxStaticBoxSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV16wxStaticBoxSizer[vtable
for wxStaticBoxSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV16wxStaticBoxSizer[vtable
for wxStaticBoxSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV16wxStaticBoxSizer[vtable
for wxStaticBoxSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV10wxBoxSizer[vtable
for wxBoxSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV10wxBoxSizer[vtable
for wxBoxSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV10wxBoxSizer[vtable
for wxBoxSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV10wxBoxSizer[vtable
for wxBoxSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV15wxFlexGridSizer[vtable
for wxFlexGridSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV15wxFlexGridSizer[vtable
for wxFlexGridSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV15wxFlexGridSizer[vtable
for wxFlexGridSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV15wxFlexGridSizer[vtable
for wxFlexGridSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV11wxGridSizer[vtable
for wxGridSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV11wxGridSizer[vtable
for wxGridSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV11wxGridSizer[vtable
for wxGridSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV11wxGridSizer[vtable
for wxGridSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV7wxSizer[vtable
for wxSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV7wxSizer[vtable
for wxSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV7wxSizer[vtable
for wxSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV7wxSizer[vtable
for wxSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV22wxStdDialogButtonSizer[vtable
for wxStdDialogButtonSizer]+0x7c): undefined reference to
`wxClientDataContainer::DoSetClientObject(wxClientData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV22wxStdDialogButtonSizer[vtable
for wxStdDialogButtonSizer]+0x80): undefined reference to
`wxClientDataContainer::DoGetClientObject() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV22wxStdDialogButtonSizer[vtable
for wxStdDialogButtonSizer]+0x84): undefined reference to
`wxClientDataContainer::DoSetClientData(void*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_sizer.o):sizer.cpp:(.rdata$_ZTV22wxStdDialogButtonSizer[vtable
for wxStdDialogButtonSizer]+0x88): undefined reference to
`wxClientDataContainer::DoGetClientData() const'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_bmpbase.o): In function
`_ZlsR9wxVariantRK8wxBitmap':
/usr/src/wxWidgets/./src/common/bmpbase.cpp:141: undefined reference
to `wxVariant::SetData(wxVariantData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_bmpbase.o): In function
`_ZlsR9wxVariantRK6wxIcon':
/usr/src/wxWidgets/./src/common/bmpbase.cpp:32: undefined reference to
`wxVariant::SetData(wxVariantData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_bmpbase.o): In function
`__static_initialization_and_destruction_0':
/usr/src/wxWidgets/./src/common/bmpbase.cpp:31: undefined reference to
`wxVariantData::ms_classInfo'
/usr/src/wxWidgets/./src/common/bmpbase.cpp:32: undefined reference to
`wxVariantData::ms_classInfo'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_image.o): In function
`_ZlsR9wxVariantRK7wxImage':
/usr/src/wxWidgets/./src/common/image.cpp:141: undefined reference to
`wxVariant::SetData(wxVariantData*)'
/usr/local/lib/libwx_mswd_core-2.8.a(corelib_image.o): In function
`__static_initialization_and_destruction_0':
/usr/src/wxWidgets/./src/common/image.cpp:52: undefined reference to
`wxVariantData::ms_classInfo'
Info: resolving __timezone by linking to __imp___timezone (auto-import)
collect2: ld returned 1 exit status
make[2]: *** [bin/wxImagePlaneWidget.exe] Error 1
make[1]: *** [CMakeFiles/wxImagePlaneWidget.dir/all] Error 2
make: *** [all] Error 2

Re: [wxVTK] Installing wxVTK

[Mathieu M. <mat...@gm...>]

Andrey,

  Sorry to hear about your misfortune trying to use wxVTK.

On Tue, Dec 23, 2008 at 9:22 AM, Andrey Sklyar <sky...@gm...> wrote:
> Hi all,
>
> I am having some trouble linking the samples provided with wxVTK.
> Could somebody please point me to a reference that explains:
>
> - how one should install wxWidgets in order for it to work with wxVTK
> - how one should install VTK to have it work with wxVTK
> - how to compile and link the sample programs provided with wxVTK using cmake
> - what wxWidgets_CONFIG_EXECUTABLE and wxWidgets_wxrc_EXECUTABLE are
> - how to have cmake find those directories automatically

I am mostly a UNIX guy, so this might not be the best way. I used a
page explaining how to build wxWidgets using the Free Compiler Tools
(released in 2003, this is a equivalent to MS VS7.1 compiler).
I then set `cl` in the path (+proper INCLUDE and LIBS), I start
cmakesetup, select 'NMake Makefiles', then from the cygwin shell
starts 'nmake': repeat for (1) VTK and (2) wxVTK. I *think* if you do
it in this order cmakesetup will be able to figure out where you build
VTK and will fill in VTK_DIR when configuring wxVTK.

Technically this should work with cygwin...but this is true (1) I
never tried, (2) I hardly ever play with the -mno-cygwin option.

> Details:
> -----------------------------------------------------
> I'm running cygwin 1.5.25 on Windows XP.
> I'm using
> - g++ version 3.4.4 (sygming special, gdc 0.12, using dmd 0.125)
> - cmake version 2.6-patch 2
> - VTK 5.2.0
> - wxWidgets version 2.8

Perfect.

>
> VTK Setup
> -----------------------------------------------------
> I installed VTK on 10/29/2008.  I am able to run the sample programs
> that came with it.

Hum... I am not an expert, but I do not think you can mix symbol from
a M$ compiled binary and a cygwin compiled binary. I do not think the
linker can find the symbols (C++) in the other one. I would suggest
you try compiling VTK yourself, with the *exact* same set of option
(esp. your -mno-cygwin).

>
> wxWidgets Setup
> -----------------------------------------------------
> I acquired and compiled wxWidgets following directions on
> http://wiki.wxwidgets.org/Cygwin
>
> I entered this in the shell (following the "To get an executable
> independent of Cygwin DLL" directions)
>
> $ cvs -d :pserver:an...@cv...:/pack/cvsroots/wxwidgets
> checkout -r WX_2_8_BRANCH wxMSW
> $ cd wxWidgets
> $ export CFLAGS=-mno-cygwin
> $ export CPPFLAGS=-mno-cygwin
> $ export CXXFLAGS=-mno-cygwin
> $ export LDFLAGS="-mno-cygwin -mwindows"
> $ ./configure --with-msw --enable-debug --enable-debug_gdb
> --disable-shared --with-libjpeg=builtin --disable-precomp-headers
> --without-expat
> $ make

Looks fine to me, and should work with VTK & wxVTK.

> wxVTK Setup
> -----------------------------------------------------
> I then proceeded to try to get wxVTK to work.
> I downloaded wxVTK from
>
> http://sourceforge.net/project/showfiles.php?group_id=114757&package_id=124328&release_id=603693
>
> and extracted it to ~/wxVTK

You may want to have a look at the CVS HEAD sometimes it is a little old...

> I then copied all the files needed for compiling the samples to a new
> directory and did an out of source build using cmake
>
> $ mkdir ~/test
> $ cd ~/test
> $ mkdir src
> $ mkdir bin
> $ cd ~/wxVTK
> $ cp -r src/ Sample/ CMakeLists.txt ~/test/src
> $ cd ~/test/bin
> $ ccmake ../src

I did not quite follow what you did. Here is what I would be doing (not tested):

$ cd ~/wxVTK
$ mkdir ~/wxVTK-bin
$ cd ~/wxVTK-bin
$ cmake ~/wxVTK
$ make


> wxWidgets_CONFIG_EXECUTABLE = /usr/local/bin/wx-config

yup.

> which is a pointer to usr/ocal/lib/wx/config/msw-ansi-debug-static-2.8
> - what is this and why is it needed for using wxWidgets?

On UNIX this is the way people have been distributing executable and
little helper that would tell developers how to link executable. Just
enter `wx-config` in your shell, this is pretty much self-explained.

> Getting a value for wxWidgets_wxrc_EXECUTABLE was harder.  Using

This should refer to the wxrc executable. I am not sure if this is
required or not. I would think this is located in /usr/local/bin
(funny cmake did not find it...).

> I generated the make file and ran make.  It wxImagePlaneWidgets.cxx
> and then wxVTKRenderWindowInteractor.cxx, then tried to link them, and
> spewed a lot of errors concerning ___assert and ___errno.

I might be missing a #include <assert.h>

> Unfortunately I didn't save the errors and have recompiled wxWindows
> since then and don't want to spend a third hour recompiling that
> library.  Upon examining wxVTKRenderWindowInteractor.cxx I saw that it
> used <assert.h> and the assert macro.  It seemed like the linker
> wasn't linking libc because I compiled wxWidgets with -mno-cygwin,
> thus leading to ___assert and ___errno not being found when linking.
>
> I recompiled wxWidgets without the -mno-cygwin flags.  I used these

No ! You cannot link a -mno-cygwin and a regular cygwin lib. They do
not export symbols the same way (AFAIK).

> The ___assert and ___errno errors promptly disappeared, but the linker
> is still complaining.  I tried building the samples again using the
> same cmake configuration as before and I am currently received the
> warning
>
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
> warning: auto-importing has been activated without
> --enable-auto-import specified on the command line.
> This should work unless it involves constant data structures
> referencing symbols from auto

Looks like a warning...

> Seems like it didn't work... The full error message is below:
>
> $ make
> Scanning dependencies of target wxImagePlaneWidget
> [ 10%] Building CXX object
> CMakeFiles/wxImagePlaneWidget.dir/Sample/wxImagePlaneWidget.cxx.o
> [ 20%] Building CXX object
> CMakeFiles/wxImagePlaneWidget.dir/src/wxVTKRenderWindowInteractor.cxx.o
> Linking CXX executable bin/wxImagePlaneWidget.exe
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
> warning: auto-importing has been activated without
> --enable-auto-import specified on the command line.
> This should work unless it involves constant data structures
> referencing symbols from auto
> -imported DLLs./usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/.
> /src/msw/window.cpp:1340: undefined reference to
> `wxSystemOptions::GetOptionInt(wxString const&)'
> /usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3956:
> undefined reference to `_wxEVT_POWER_SUSPENDING'

Your linker is lost IMHO. You may want to inspect the output of:

 $ make VERBOSE=1

To check that library are properly passed to the linker.


Good luck.
-- 
Mathieu

Re: [wxVTK] Installing wxVTK

[Mathieu M. <mat...@gm...>]

On Tue, Dec 23, 2008 at 10:06 AM, Mathieu Malaterre
<mat...@gm...> wrote:
> Andrey,
>
>  Sorry to hear about your misfortune trying to use wxVTK.

One last things. You can only use cmake cygwin package to generate
cygwin Makefile. While you can only use cmake/cmakesetup (from
cmake.org) for all other Win32 type of compilation. One is using UNIX
path (for cygwin), while the other is generating DOS path (to please
cl and al.)

-- 
Mathieu

Re: [wxVTK] Installing wxVTK

[Andrey S. <sky...@gm...>]

Thanks for your quick reply!

> > VTK Setup
> > -----------------------------------------------------
> > I installed VTK on 10/29/2008.  I am able to run the sample programs
> > that came with it.
>
> Hum... I am not an expert, but I do not think you can mix symbol from
> a M$ compiled binary and a cygwin compiled binary. I do not think the
> linker can find the symbols (C++) in the other one. I would suggest
> you try compiling VTK yourself, with the *exact* same set of option
> (esp. your -mno-cygwin).

I compiled everything using cygwin, including VTK.  I used these
options with cmake:

BUILD_EXAMPLES                   ON
BUILD_SHARED_LIBS                OFF
BUILD_TESTING                    ON
CMAKE_BACKWARDS_COMPATIBILITY    2.4
CMAKE_BUILD_TYPE
CMAKE_INSTALL_PREFIX             /usr/local
VTK_DATA_ROOT                    /usr/src/VTKData
VTK_USE_INFOVIS                  ON
VTK_USE_PARALLEL                 OFF
VTK_USE_RENDERING                ON
VTK_USE_VIEWS                    ON
VTK_WRAP_JAVA                    OFF
VTK_WRAP_PYTHON                  OFF
VTK_WRAP_TCL                     OFF

> >
> > wxWidgets Setup
> > -----------------------------------------------------
> > I acquired and compiled wxWidgets following directions on
> > http://wiki.wxwidgets.org/Cygwin
> >
> > I entered this in the shell (following the "To get an executable
> > independent of Cygwin DLL" directions)
> >
> > $ cvs -d :pserver:an...@cv...:/pack/cvsroots/wxwidgets
> > checkout -r WX_2_8_BRANCH wxMSW
> > $ cd wxWidgets
> > $ export CFLAGS=-mno-cygwin
> > $ export CPPFLAGS=-mno-cygwin
> > $ export CXXFLAGS=-mno-cygwin
> > $ export LDFLAGS="-mno-cygwin -mwindows"
> > $ ./configure --with-msw --enable-debug --enable-debug_gdb
> > --disable-shared --with-libjpeg=builtin --disable-precomp-headers
> > --without-expat
> > $ make
>
> Looks fine to me, and should work with VTK & wxVTK.

Would this still work with a VTK and wxVTK that was linked with cygwin?

>
> > wxVTK Setup
> > -----------------------------------------------------
> > I then proceeded to try to get wxVTK to work.
> > I downloaded wxVTK from
> >
> > http://sourceforge.net/project/showfiles.php?group_id=114757&package_id=124328&release_id=603693
> >
> > and extracted it to ~/wxVTK
>
> You may want to have a look at the CVS HEAD sometimes it is a little old...

I did, and it didn't compile, so I went to the branch.  I saw also
that they're using SVN now (http://www.wxwidgets.org/develop/svn.htm)
and that the cvs repository is "obsolete"
(http://wiki.wxwidgets.org/Cvs).

>
> > I then copied all the files needed for compiling the samples to a new
> > directory and did an out of source build using cmake
> >
>
> I did not quite follow what you did. Here is what I would be doing (not tested):
>

We both ended up doing an out of source build.  Ok, that's good, got
something right!

>
>
> > wxWidgets_CONFIG_EXECUTABLE = /usr/local/bin/wx-config
>
> yup.
>
> > which is a pointer to usr/ocal/lib/wx/config/msw-ansi-debug-static-2.8
> > - what is this and why is it needed for using wxWidgets?
>
> On UNIX this is the way people have been distributing executable and
> little helper that would tell developers how to link executable. Just
> enter `wx-config` in your shell, this is pretty much self-explained.

Thanks, that explained it.

> > Getting a value for wxWidgets_wxrc_EXECUTABLE was harder.  Using
>
> This should refer to the wxrc executable. I am not sure if this is
> required or not. I would think this is located in /usr/local/bin
> (funny cmake did not find it...).

I don't seem to have a wxrc executable... does the path that you have
for wxWidgets_wxrc_EXECUTABLE on your machine point to such an
executable?  If it's not really needed, is there a way to turn it off
(so that cmake doesn't ask you for it)?

>
> > I generated the make file and ran make.  It wxImagePlaneWidgets.cxx
> > and then wxVTKRenderWindowInteractor.cxx, then tried to link them, and
> > spewed a lot of errors concerning ___assert and ___errno.
>
> I might be missing a #include <assert.h>

You have it there.  It was just my linker not liking something.

> > Unfortunately I didn't save the errors and have recompiled wxWindows
> > since then and don't want to spend a third hour recompiling that
> > library.  Upon examining wxVTKRenderWindowInteractor.cxx I saw that it
> > used <assert.h> and the assert macro.  It seemed like the linker
> > wasn't linking libc because I compiled wxWidgets with -mno-cygwin,
> > thus leading to ___assert and ___errno not being found when linking.
> >
> > I recompiled wxWidgets without the -mno-cygwin flags.  I used these
>
> No ! You cannot link a -mno-cygwin and a regular cygwin lib. They do
> not export symbols the same way (AFAIK).

The reason I recompiled wxWidgets was because VTK was built with
cygwin libraries, but wxWidgets was built without the.  This lead lead
to the symbol mismatch problems you described.  I think that ___assert
and ___errno were some of these symbols that weren't getting exported
the same way and thus causing errors.

> > The ___assert and ___errno errors promptly disappeared, but the linker
> > is still complaining.  I tried building the samples again using the
> > same cmake configuration as before and I am currently received the
> > warning
> >
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
> > warning: auto-importing has been activated without
> > --enable-auto-import specified on the command line.
> > This should work unless it involves constant data structures
> > referencing symbols from auto
>
> Looks like a warning...
>
> > Seems like it didn't work... The full error message is below:
> >
> > $ make
> > Scanning dependencies of target wxImagePlaneWidget
> > [ 10%] Building CXX object
> > CMakeFiles/wxImagePlaneWidget.dir/Sample/wxImagePlaneWidget.cxx.o
> > [ 20%] Building CXX object
> > CMakeFiles/wxImagePlaneWidget.dir/src/wxVTKRenderWindowInteractor.cxx.o
> > Linking CXX executable bin/wxImagePlaneWidget.exe
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
> > warning: auto-importing has been activated without
> > --enable-auto-import specified on the command line.
> > This should work unless it involves constant data structures
> > referencing symbols from auto
> > -imported DLLs./usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/.
> > /src/msw/window.cpp:1340: undefined reference to
> > `wxSystemOptions::GetOptionInt(wxString const&)'
> > /usr/local/lib/libwx_mswd_core-2.8.a(corelib_window.o):/usr/src/wxWidgets/./src/msw/window.cpp:3956:
> > undefined reference to `_wxEVT_POWER_SUSPENDING'
>
> Your linker is lost IMHO. You may want to inspect the output of:
>
>  $ make VERBOSE=1
>
> To check that library are properly passed to the linker.

I will do that.  Once I figure out which libraries I'm missing, how
should I edit CMakeList.txt to have cmake add the libraries to the
Makefile for linking?  Is there a good online reference for CMake file
writing (I know there's the book for Kitware...)?

> Good luck.
> --
> Mathieu

Thanks again for your help.

- Andrey

Re: [wxVTK] Installing wxVTK

[Mathieu M. <mat...@gm...>]

On Tue, Dec 23, 2008 at 10:53 AM, Andrey Sklyar <sky...@gm...> wrote:
> I compiled everything using cygwin, including VTK.  I used these
> options with cmake:
>
> BUILD_EXAMPLES                   ON
> BUILD_SHARED_LIBS                OFF
> BUILD_TESTING                    ON
> CMAKE_BACKWARDS_COMPATIBILITY    2.4
> CMAKE_BUILD_TYPE
> CMAKE_INSTALL_PREFIX             /usr/local
> VTK_DATA_ROOT                    /usr/src/VTKData
> VTK_USE_INFOVIS                  ON
> VTK_USE_PARALLEL                 OFF
> VTK_USE_RENDERING                ON
> VTK_USE_VIEWS                    ON
> VTK_WRAP_JAVA                    OFF
> VTK_WRAP_PYTHON                  OFF
> VTK_WRAP_TCL                     OFF

cmake option are not the important part. The important part were the
compilation flags.

export CFLAGS=blafoo
export CXXFLAGS=foobar
export CC=my_c-compiler
export CXX=my_cxx_compiler

THEN (and only afterward) can you start `cmake /path/to/src` *in an
empty* directory. Do not report *any* message where you did not start
from an empty directory !

> Would this still work with a VTK and wxVTK that was linked with cygwin?

Yes. As long as you mix dll compiled with same compiler. VTK supports
mingw type compiler (~equivalent to cygwin gcc with -mon-cygwin).

> I did, and it didn't compile, so I went to the branch.  I saw also
> that they're using SVN now (http://www.wxwidgets.org/develop/svn.htm)
> and that the cvs repository is "obsolete"
> (http://wiki.wxwidgets.org/Cvs).

I was talking about wxVTK, not wxWidgets.

http://sourceforge.net/cvs/?group_id=114757

> I don't seem to have a wxrc executable... does the path that you have
> for wxWidgets_wxrc_EXECUTABLE on your machine point to such an
> executable?  If it's not really needed, is there a way to turn it off
> (so that cmake doesn't ask you for it)?

If this does not work, replace the cmake entry with either `echo` of
`ls` those are unix cmd that are available by default on any cygwin
install. You do not need wxrc for compiling wxVTK AFAIK.

> The reason I recompiled wxWidgets was because VTK was built with
> cygwin libraries,

No. At least not the one from vtk.org.

> but wxWidgets was built without the.  This lead lead
> to the symbol mismatch problems you described.  I think that ___assert
> and ___errno were some of these symbols that weren't getting exported
> the same way and thus causing errors.

ok.

> I will do that.  Once I figure out which libraries I'm missing, how
> should I edit CMakeList.txt to have cmake add the libraries to the
> Makefile for linking?  Is there a good online reference for CMake file
> writing (I know there's the book for Kitware...)?

Check out cmake wiki, google is your friend. Or else I found this:
http://eris.liralab.it/yarp/specs/dox/dev/html/using_cmake.html

You basically need: add_executable, add_library and
target_link_libraries. Otherwise from the command line:

 $ cmake --help-commands | less

if you know cmd contains the string `foobar` but dont remember proper spelling:

 $ cmake --help-command-list | grep -i foobar
 $ cmake --help-command my_complex_foobar_doh

cmake mailing list is also an excellent ressource.

2cts

--
Mathieu

Re: [wxVTK] Installing wxVTK

[Andrey S. <sky...@gm...>]

Changing

FIND_PACKAGE(wxWidgets COMPONENTS base core adv ${WXGLCANVASLIBS})

to

FIND_PACKAGE(wxWidgets COMPONENTS core adv ${WXGLCANVASLIBS} base)

solves the linking issue I was having.  I saw somewhere on line that
this has to do with the order in which Find_Packages adds the link
libraries to the linking command, but I can't find the specific post.

- Andrey

Re: [wxVTK] Installing wxVTK

[Mathieu M. <mat...@gm...>]

On Sat, Jan 3, 2009 at 2:51 AM, Andrey Sklyar <sky...@gm...> wrote:
> Changing
>
> FIND_PACKAGE(wxWidgets COMPONENTS base core adv ${WXGLCANVASLIBS})
>
> to
>
> FIND_PACKAGE(wxWidgets COMPONENTS core adv ${WXGLCANVASLIBS} base)
>
> solves the linking issue I was having.  I saw somewhere on line that
> this has to do with the order in which Find_Packages adds the link
> libraries to the linking command, but I can't find the specific post.

Hum... ok that patch looks fine.
Plrease log that in the bug tracker:

http://sourceforge.net/tracker/?group_id=114757&atid=669338


thx
-- 
Mathieu