writing .minf
-
- Posts: 6
- Joined: Thu Jul 06, 2006 4:26 pm
writing .minf
The following code produces Segmentation Fault
PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );
with sources of aimsdata updated and compiled from perforce on 04/07/2006
Has PythonHeader been replaced by something else ?
JD
PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );
with sources of aimsdata updated and compiled from perforce on 04/07/2006
Has PythonHeader been replaced by something else ?
JD
-
- Posts: 6
- Joined: Thu Jul 06, 2006 4:26 pm
- Yann Cointepas
- Posts: 316
- Joined: Tue Jan 20, 2004 2:56 pm
- Location: Neurospin, Saint Aubin, France
- Contact:
-
- Posts: 6
- Joined: Thu Jul 06, 2006 4:26 pm
My code is
#include <aims/data/pheader.h>
using namespace aims;
int main()
{
PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );
return 1;
}
I am using the following lines for compilation of test.o :
g++ -c -Wall -W -D_REENTRANT -fPIC -DCARTO_DEBUGMODE=\"default\" -DAIMS -DAIMS -DQT_CLEAN_NAMESPACE -DQT_THREAD_SUPPORT -DHAS_GLEXT -I/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/include -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/include/libxml2 -I/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat+-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/vidaIO-main-linux-default/include -o test.o test.cpp
and for linking :
g++ -o test test.o -L/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/lib -laimsdata -lcartobase -lcartodata -lgraph
and ./test produces a Segmentation Fault
#include <aims/data/pheader.h>
using namespace aims;
int main()
{
PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );
return 1;
}
I am using the following lines for compilation of test.o :
g++ -c -Wall -W -D_REENTRANT -fPIC -DCARTO_DEBUGMODE=\"default\" -DAIMS -DAIMS -DQT_CLEAN_NAMESPACE -DQT_THREAD_SUPPORT -DHAS_GLEXT -I/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/include -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/include/libxml2 -I/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat+-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/vidaIO-main-linux-default/include -o test.o test.cpp
and for linking :
g++ -o test test.o -L/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/lib -laimsdata -lcartobase -lcartodata -lgraph
and ./test produces a Segmentation Fault
-
- Posts: 6
- Joined: Thu Jul 06, 2006 4:26 pm
-
- Posts: 6
- Joined: Thu Jul 06, 2006 4:26 pm
Do you think the problem could come from the fact that aims library and the test program are not compiled on the same machine ?
Would it be a problem for functions such as dynamic_cast ( the same object has different representation, depending on compilation machine or compilation options ) ?
Is it possible that the PythonHeader object I create in my program is not "recognized" by aims library and causes an error in dyncamic_cast ?
Would it be a problem for functions such as dynamic_cast ( the same object has different representation, depending on compilation machine or compilation options ) ?
Is it possible that the PythonHeader object I create in my program is not "recognized" by aims library and causes an error in dyncamic_cast ?
- Yann Cointepas
- Posts: 316
- Joined: Tue Jan 20, 2004 2:56 pm
- Location: Neurospin, Saint Aubin, France
- Contact:
If it is not on the same machine but the two systems are the same, it is ok. But if the sytems differ, it can lead to problems according to gcc and libstdc++ versions. For example, in Orsay we slowly passed from Fedora Core 2 to Fedora Core 4. It was not possible to make one compilation distributed on the two systems. During the transition, we had to compile only on one system.
I am not sure about compilation options. It should not be a problem as long as you use the same -D options because of #if / #endif that may compile different code.
There is no dynamic_cast in your program, the problem is in the library or in the way is is compiled or linked.
I am not sure about compilation options. It should not be a problem as long as you use the same -D options because of #if / #endif that may compile different code.
There is no dynamic_cast in your program, the problem is in the library or in the way is is compiled or linked.
- riviere
- Site Admin
- Posts: 1361
- Joined: Tue Jan 06, 2004 12:21 pm
- Location: CEA NeuroSpin, Saint Aubin, France
- Contact:
The -D options seem OK to me (compared to what I have using build-config), except that you have -DAIMS twice, but this is not a problem.
I would rather suspect a system compiler/libaries incompatibility if you have compiled on two different machines, as Yann suggested.
You can check some basic problems using ldd:
ldd test
if you see several libstdc++ (with different version numbers), don't look further: that's the problem.
Denis
I would rather suspect a system compiler/libaries incompatibility if you have compiled on two different machines, as Yann suggested.
You can check some basic problems using ldd:
ldd test
if you see several libstdc++ (with different version numbers), don't look further: that's the problem.
Denis