OSGeo.org › OSGeo Software and Data Projects › Feature Data Objects (FDO) › FDO Users

FDO Compile error (libxalan-c)

43 messages

1 2 3

kernel_panic

FDO Compile error (libxalan-c)

Reply Threaded

Im trying to compile mapguide, but Im having problems compiling FDO

I have followed the procedures from mapguide's and fdo's respective sites, step by step.

I have tried this in two different virtual machines using virtualbox:

Host:XP Guest:Kubuntu 9.04

Host: kubuntu 9.04 Guest: kubuntu 9.04

I have been able to compile apache and, tomcat and php from the aptinstaller tarball, but the problem starts when I compile FDO, and for what I have seen, its a fairly common problem:

Building of the Thirdparty/GDAL libraries has been skipped. Environment

variable FDOGDAL points to a previously installed version of GDAL at .
This version of GDAL will be used to build the FDO WMS and GDAL
providers.
make[1]: se ingresa al directorio `/opt/OpenSource/Thirdparty'
make[1]: *** No hay ninguna regla para construir el objetivo
`apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
Alto.
make[1]: se sale del directorio `/opt/OpenSource/Thirdparty'
make: *** [install-recursive] Error 1

That's from: http://lists.osgeo.org/pipermail/fdo-users/2009-January/001367.html

I have triied the following:

- Change the setenvironment.sh to point FDOGDAL to the place where it is (fdo/gdal i think is the default), as suggested here:  http://lists.osgeo.org/pipermail/fdo-users/2009-January/001367.html

- Install gdal using synaptic (both gdal, libgdal and dev versions), then change FDOGDAL to point to the location where gdal was installed by synaptic (usr/include/gdal in my case)

The same error occurs in both cases.

Also, I noticed that on apache/xml-xalan/c/ folder, before I run the build_thirdparty script, there isnt a lib folder, when the script fails, the apache/xml-xalan/c/ has a lib folder, with three files, all three related to libxalanmsg.so, however, there is not any libxalanc...

I read in another forum, related to the compilation of libxalan, that one needed to change de XALANCROOT path, to solve that same error, however, I tried export XALANCROOT= to the path where xalan is (.../xml-xalan/c/) with no success...

This happens with FDO from subversion (fdo 3.3.1), and also if I download the tarballs from fdo.osgeo download section, versions 3.4.1 RC1, 3.4.0 3.3.2 and 3.3.1)

Any help would be REALLY appreciated!!!

Extra: related posts regarding this error:

http://lists.osgeo.org/pipermail/fdo-users/2009-January/001365.html

http://lists.osgeo.org/pipermail/fdo-users/2009-January/001365.html

http://lists.osgeo.org/pipermail/fdo-users/attachments/20090626/6d044d8f/attachment.html

http://lists.osgeo.org/pipermail/fdo-users/attachments/20090630/3e99e394/attachment.html

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

john spitzer

Re: FDO Compile error (libxalan-c)

Reply Threaded

Hi,
I had some issues trying to build FDO from source on Ubuntu. I rescued
these comments from my old internal
emails:

The First(FDO) stage requires for gdl, sdf, shp, ogr some fixes in
xml-xalan - looks like something you get for free with visual studio
has to be spelled out in gcc (#include <cstring>) in a number of
places in the code. Also in the gdal sub-build there some issues with
passing environment variables between shell scripts - a well known
trap which can cause grief - I did a hack to get it to work - I do not
remember what the optimal solution is as it was a long time ago.

NB It is essential that gcc/g++ 4.1 be used ortherwise serious other
grief occurs. The default on Ubuntu 9.04 is 4.3 .

Cheers,
John

On Tue, Oct 6, 2009 at 8:34 AM, kernel_panic
<[hidden email]> wrote:

> Hi
> Im trying to compile mapguide, but Im having problems compiling FDO
> I have followed the procedures from mapguide's and fdo's respective sites,
> step by step.
> I have tried this in two different virtual machines using virtualbox:
> Host:XP Guest:Kubuntu 9.04
> Host: kubuntu 9.04 Guest: kubuntu 9.04
> I have been able to compile apache and, tomcat and php from the aptinstaller
> tarball, but the problem starts when I compile FDO, and for what I have
> seen, its a fairly common problem:
> Building of the Thirdparty/GDAL libraries has been skipped. Environment
>
> variable FDOGDAL points to a previously installed version of GDAL at .
> This version of GDAL will be used to build the FDO WMS and GDAL
> providers.
> make[1]: se ingresa al directorio `/opt/OpenSource/Thirdparty'
> make[1]: *** No hay ninguna regla para construir el objetivo
> `apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
> Alto.
> make[1]: se sale del directorio `/opt/OpenSource/Thirdparty'
> make: *** [install-recursive] Error 1
>
> That's from:
> http://lists.osgeo.org/pipermail/fdo-users/2009-January/001367.html
>
> I have triied the following:
>
> - Change the setenvironment.sh to point FDOGDAL to the place where it is
> (fdo/gdal i think is the default), as suggested here:
> http://lists.osgeo.org/pipermail/fdo-users/2009-January/001367.html
>
> - Install gdal using synaptic (both gdal, libgdal and dev versions), then
> change FDOGDAL to point to the location where gdal was installed by synaptic
> (usr/include/gdal in my case)
>
> The same error occurs in both cases.
>
> Also, I noticed that on apache/xml-xalan/c/ folder, before I run the
> build_thirdparty script, there isnt a lib folder, when the script fails, the
> apache/xml-xalan/c/ has a lib folder, with three files, all three related to
> libxalanmsg.so, however, there is not any libxalanc...
>
> I read in another forum, related to the compilation of libxalan, that one
> needed to change de XALANCROOT path, to solve that same error, however, I
> tried export XALANCROOT= to the path where xalan is (.../xml-xalan/c/) with
> no success...
>
> This happens with FDO from subversion (fdo 3.3.1), and also if I download
> the tarballs from fdo.osgeo download section, versions 3.4.1 RC1, 3.4.0
> 3.3.2 and 3.3.1)
>
> Any help would be REALLY appreciated!!!
>
> Extra: related posts regarding this error:
>
> http://lists.osgeo.org/pipermail/fdo-users/2009-January/001365.html
>
> http://lists.osgeo.org/pipermail/fdo-users/2009-January/001365.html
>
> http://lists.osgeo.org/pipermail/fdo-users/attachments/20090626/6d044d8f/attachment.html
>
> http://lists.osgeo.org/pipermail/fdo-users/attachments/20090630/3e99e394/attachment.html
>
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

Hi, John

When you say

"The First(FDO) stage requires for gdl, sdf, shp, ogr some fixes in
xml-xalan - looks like something you get for free with visual studio
has to be spelled out in gcc (#include <cstring>) in a number of
places in the code. Also in the gdal sub-build there some issues with
passing environment variables between shell scripts - a well known
trap which can cause grief - I did a hack to get it to work - I do not
remember what the optimal solution is as it was a long time ago."

What kind of stuff are you talking about, regarding to visual studio, gcc and the passing environment variables issues?

I mean, you dont have to tell me "do this, do that and done", but if you can give me a hint (or anyone else :p) on what to look for and where, I might get a greater insight on this, and perhaps, find a solution by narrowing the possible causes of this problem.

Heh, for a "well known" problem, solution remains "unknown", because this is the second time I read that someone has fixed this, cant dont remember how :p:p

Thanks for the reply!

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

john spitzer

Re: FDO Compile error (libxalan-c)

Reply Threaded

Hi,
When building FDO from source on Ubuntu I got the following g++
compile time issue:
g++ -O2 -DNDEBUG -fno-elide-constructors -Wall -fPIC -DLINUX
-D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c
-I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src
-I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/include
-I../../nls/include
-I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/src/
-I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/xercesc
-I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/ -o
../../obj/XalanDOMString.o
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
In member function ‘xalanc_1_7::XalanDOMString&
xalanc_1_7::XalanDOMString::assign(const xalanc_1_7::XalanDOMString&,
size_t, size_t)’:
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:281:
error: ‘memmove’ is not a member of ‘std’
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
In static member function ‘static size_t
xalanc_1_7::XalanDOMString::length(const char*)’:
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:825:
error: ‘strlen’ is not a member of ‘std’
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
In function ‘bool xalanc_1_7::doTranscodeFromLocalCodePage(const
char*, size_t, bool, xalanc_1_7::XalanDOMCharVectorType&, bool)’:
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:1154:
error: ‘strncpy’ is not a member of ‘std’
make[1]: *** [../../obj/XalanDOMString.o] Error 1
make[1]: Leaving directory
`/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc'
make: *** [all] Error 2

This was fixed by including in the source of
/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
the following include directive :

#include <cstring>

There are quite a few cases where this is necessary to achieve a clean
compile of xml-xalan.
gcc/g++ is the standard compiler on Linux.
The passage of environment variables between shell script is a famous
Unix gotcha. I did not bother to Google it, but you can give it a try
to get some background on this issue.
What really causes most grief in migrating systems developed under
Windows onto Unix is case-sensitivites of system names(File names etc)
- windows is case insensitive while unix is case sensitive.

Hope this is of some assistance,
Cheers,
John

On Tue, Oct 6, 2009 at 4:08 PM, kernel_panic
<[hidden email]> wrote:

> Hi, John
>
> When you say
>>
>> "The First(FDO) stage requires for gdl, sdf, shp, ogr some fixes in
>> xml-xalan - looks like something you get for free with visual studio
>> has to be spelled out in gcc (#include <cstring>) in a number of
>> places in the code. Also in the gdal sub-build there some issues with
>> passing environment variables between shell scripts - a well known
>> trap which can cause grief - I did a hack to get it to work - I do not
>> remember what the optimal solution is as it was a long time ago."
>>
>
> What kind of stuff are you talking about, regarding to visual studio, gcc
> and the passing environment variables issues?
>
> I mean, you dont have to tell me "do this, do that and done", but if you can
> give me a hint (or anyone else :p) on what to look for and where, I might
> get a greater insight on this, and perhaps, find a solution by narrowing the
> possible causes of this problem.
>
> Heh, for a "well known" problem, solution remains "unknown", because this is
> the second time I read that someone has fixed this, cant dont remember how
> :p:p
>
> Thanks for the reply!
>
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

Well, Im not having this particular issue:

2009/10/6, john spitzer <[hidden email]>:

> Hi,
> When building FDO from source on Ubuntu I got the following g++
> compile time issue:
> g++ -O2 -DNDEBUG -fno-elide-constructors -Wall -fPIC -DLINUX
> -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c
> -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src
> -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/include
> -I../../nls/include
> -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/src/
> -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/xercesc
> -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/ -o
> ../../obj/XalanDOMString.o
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> In member function ‘xalanc_1_7::XalanDOMString&
> xalanc_1_7::XalanDOMString::assign(const xalanc_1_7::XalanDOMString&,
> size_t, size_t)’:
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:281:
> error: ‘memmove’ is not a member of ‘std’
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> In static member function ‘static size_t
> xalanc_1_7::XalanDOMString::length(const char*)’:
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:825:
> error: ‘strlen’ is not a member of ‘std’
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> In function ‘bool xalanc_1_7::doTranscodeFromLocalCodePage(const
> char*, size_t, bool, xalanc_1_7::XalanDOMCharVectorType&, bool)’:
> /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:1154:
> error: ‘strncpy’ is not a member of ‘std’
> make[1]: *** [../../obj/XalanDOMString.o] Error 1
> make[1]: Leaving directory
> `/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc'
> make: *** [all] Error 2
>"

But adding #include <cstring> on all .cpp files on
/Thirdparty/gdal/frmts/ilwis/ made another (unnoticed :p) error go
away, regarding libgdal.so not being created.

However, Im still getting the xalan error :S

"make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty/gdal/apps'
make[1]: se ingresa al directorio `/opt/fdo-3.3.1/Thirdparty'
make[1]: *** No hay ninguna regla para construir el objetivo
`apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
Alto.
make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty'
make: *** [install-recursive] Error 1"

I was thinking on what you said about passing variables between
scripts, but I dont know how the scripts are run :p, I mean, I dont
know who calls who, so I dont know where to look for...

Does anyone know in which order the scripts are run, or how can I
figure out that?
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

Hi,

If you are using the latest Ubuntu and the latest FDO sources, your best bet is probably to try the CMake build system instead of the automake based one. That of course depends on which FDO providers you need, since some of them don't have CMake files yet.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of kernel_panic
> Sent: Tuesday, October 06, 2009 4:42 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> Well, Im not having this particular issue:
>
> 2009/10/6, john spitzer <[hidden email]>:
> > Hi,
> > When building FDO from source on Ubuntu I got the following g++
> > compile time issue:
> > g++ -O2 -DNDEBUG -fno-elide-constructors -Wall -fPIC -DLINUX
> > -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c
> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src
> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/include
> > -I../../nls/include
> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/src/
> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/xercesc
> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/ -o
> > ../../obj/XalanDOMString.o
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> > In member function 'xalanc_1_7::XalanDOMString&
> > xalanc_1_7::XalanDOMString::assign(const xalanc_1_7::XalanDOMString&,
> > size_t, size_t)':
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:281:
> > error: 'memmove' is not a member of 'std'
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> > In static member function 'static size_t
> > xalanc_1_7::XalanDOMString::length(const char*)':
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:825:
> > error: 'strlen' is not a member of 'std'
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> > In function 'bool xalanc_1_7::doTranscodeFromLocalCodePage(const
> > char*, size_t, bool, xalanc_1_7::XalanDOMCharVectorType&, bool)':
> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:1154:
> > error: 'strncpy' is not a member of 'std'
> > make[1]: *** [../../obj/XalanDOMString.o] Error 1
> > make[1]: Leaving directory
> > `/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc'
> > make: *** [all] Error 2
> >"
>
> But adding #include <cstring> on all .cpp files on
> /Thirdparty/gdal/frmts/ilwis/ made another (unnoticed :p) error go
> away, regarding libgdal.so not being created.
>
> However, Im still getting the xalan error :S
>
> "make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty/gdal/apps'
> make[1]: se ingresa al directorio `/opt/fdo-3.3.1/Thirdparty'
> make[1]: *** No hay ninguna regla para construir el objetivo
> `apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
> Alto.
> make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty'
> make: *** [install-recursive] Error 1"
>
> I was thinking on what you said about passing variables between
> scripts, but I dont know how the scripts are run :p, I mean, I dont
> know who calls who, so I dont know where to look for...
>
> Does anyone know in which order the scripts are run, or how can I
> figure out that?
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

Well, right now Im using 3.3.1, but I might give 3.4.0 a go :)

Now, I have some more questions :)

a) Have you compiled FDO succesfully on ubuntu (or anything
debian-based)? if so, which version, and how did you do it?
b) Do you know which FDO providers work with CMake build system?
c) How do I try using CMake? :p. Never been there, never done that :p

2009/10/6, Traian Stanev <[hidden email]>:

>
> Hi,
>
> If you are using the latest Ubuntu and the latest FDO sources, your best bet
> is probably to try the CMake build system instead of the automake based one.
> That of course depends on which FDO providers you need, since some of them
> don't have CMake files yet.
>
> Traian
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:fdo-users-
>> [hidden email]] On Behalf Of kernel_panic
>> Sent: Tuesday, October 06, 2009 4:42 PM
>> To: FDO Users Mail List
>> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>>
>> Well, Im not having this particular issue:
>>
>> 2009/10/6, john spitzer <[hidden email]>:
>> > Hi,
>> > When building FDO from source on Ubuntu I got the following g++
>> > compile time issue:
>> > g++ -O2 -DNDEBUG -fno-elide-constructors -Wall -fPIC -DLINUX
>> > -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c
>> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src
>> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/include
>> > -I../../nls/include
>> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/src/
>> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/xercesc
>> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/ -o
>> > ../../obj/XalanDOMString.o
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
>> > In member function 'xalanc_1_7::XalanDOMString&
>> > xalanc_1_7::XalanDOMString::assign(const xalanc_1_7::XalanDOMString&,
>> > size_t, size_t)':
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:281:
>> > error: 'memmove' is not a member of 'std'
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
>> > In static member function 'static size_t
>> > xalanc_1_7::XalanDOMString::length(const char*)':
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:825:
>> > error: 'strlen' is not a member of 'std'
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
>> > In function 'bool xalanc_1_7::doTranscodeFromLocalCodePage(const
>> > char*, size_t, bool, xalanc_1_7::XalanDOMCharVectorType&, bool)':
>> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
>> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:1154:
>> > error: 'strncpy' is not a member of 'std'
>> > make[1]: *** [../../obj/XalanDOMString.o] Error 1
>> > make[1]: Leaving directory
>> > `/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc'
>> > make: *** [all] Error 2
>> >"
>>
>> But adding #include <cstring> on all .cpp files on
>> /Thirdparty/gdal/frmts/ilwis/ made another (unnoticed :p) error go
>> away, regarding libgdal.so not being created.
>>
>> However, Im still getting the xalan error :S
>>
>> "make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty/gdal/apps'
>> make[1]: se ingresa al directorio `/opt/fdo-3.3.1/Thirdparty'
>> make[1]: *** No hay ninguna regla para construir el objetivo
>> `apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
>> Alto.
>> make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty'
>> make: *** [install-recursive] Error 1"
>>
>> I was thinking on what you said about passing variables between
>> scripts, but I dont know how the scripts are run :p, I mean, I dont
>> know who calls who, so I dont know where to look for...
>>
>> Does anyone know in which order the scripts are run, or how can I
>> figure out that?
>> _______________________________________________
>> fdo-users mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

I meant 3.5, not 3.4. :)

I have compiled successfully on Ubuntu using both automake and CMake, but I don't remember all the hacks I had to do to make it work using the automake build (it was a while back). The pain you are seeing with Thirdparty is that the versions of the components in /Thirparty are old and will not compile with newer g++. The CMake build uses the versions of those libraries installed by Ubuntu itself (using apt-get), so it does not have to compile /Thirparty at all. There is a file in /trunk/ called CMake__README.txt which explains how to do it.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of kernel_panic
> Sent: Tuesday, October 06, 2009 4:55 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> Well, right now Im using 3.3.1, but I might give 3.4.0 a go :)
>
> Now, I have some more questions :)
>
> a) Have you compiled FDO succesfully on ubuntu (or anything
> debian-based)? if so, which version, and how did you do it?
> b) Do you know which FDO providers work with CMake build system?
> c) How do I try using CMake? :p. Never been there, never done that :p
>
> 2009/10/6, Traian Stanev <[hidden email]>:
> >
> > Hi,
> >
> > If you are using the latest Ubuntu and the latest FDO sources, your best
> bet
> > is probably to try the CMake build system instead of the automake based
> one.
> > That of course depends on which FDO providers you need, since some of them
> > don't have CMake files yet.
> >
> > Traian
> >
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:fdo-users-
> >> [hidden email]] On Behalf Of kernel_panic
> >> Sent: Tuesday, October 06, 2009 4:42 PM
> >> To: FDO Users Mail List
> >> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> >>
> >> Well, Im not having this particular issue:
> >>
> >> 2009/10/6, john spitzer <[hidden email]>:
> >> > Hi,
> >> > When building FDO from source on Ubuntu I got the following g++
> >> > compile time issue:
> >> > g++ -O2 -DNDEBUG -fno-elide-constructors -Wall -fPIC -DLINUX
> >> > -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c
> >> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src
> >> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/include
> >> > -I../../nls/include
> >> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/src/
> >> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> xerces/c/include/xercesc
> >> > -I/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xerces/c/include/ -o
> >> > ../../obj/XalanDOMString.o
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> >> > In member function 'xalanc_1_7::XalanDOMString&
> >> > xalanc_1_7::XalanDOMString::assign(const xalanc_1_7::XalanDOMString&,
> >> > size_t, size_t)':
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:281:
> >> > error: 'memmove' is not a member of 'std'
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> >> > In static member function 'static size_t
> >> > xalanc_1_7::XalanDOMString::length(const char*)':
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:825:
> >> > error: 'strlen' is not a member of 'std'
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:
> >> > In function 'bool xalanc_1_7::doTranscodeFromLocalCodePage(const
> >> > char*, size_t, bool, xalanc_1_7::XalanDOMCharVectorType&, bool)':
> >> > /home/jjs/OpenSource_FDO/Thirdparty/apache/xml-
> >> xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:1154:
> >> > error: 'strncpy' is not a member of 'std'
> >> > make[1]: *** [../../obj/XalanDOMString.o] Error 1
> >> > make[1]: Leaving directory
> >> > `/home/jjs/OpenSource_FDO/Thirdparty/apache/xml-xalan/c/src/xalanc'
> >> > make: *** [all] Error 2
> >> >"
> >>
> >> But adding #include <cstring> on all .cpp files on
> >> /Thirdparty/gdal/frmts/ilwis/ made another (unnoticed :p) error go
> >> away, regarding libgdal.so not being created.
> >>
> >> However, Im still getting the xalan error :S
> >>
> >> "make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty/gdal/apps'
> >> make[1]: se ingresa al directorio `/opt/fdo-3.3.1/Thirdparty'
> >> make[1]: *** No hay ninguna regla para construir el objetivo
> >> `apache/xml-xalan/c/lib/libxalan-c.so.17.0', necesario para `all-am'.
> >> Alto.
> >> make[1]: se sale del directorio `/opt/fdo-3.3.1/Thirdparty'
> >> make: *** [install-recursive] Error 1"
> >>
> >> I was thinking on what you said about passing variables between
> >> scripts, but I dont know how the scripts are run :p, I mean, I dont
> >> know who calls who, so I dont know where to look for...
> >>
> >> Does anyone know in which order the scripts are run, or how can I
> >> figure out that?
> >> _______________________________________________
> >> fdo-users mailing list
> >> [hidden email]
> >> http://lists.osgeo.org/mailman/listinfo/fdo-users
> > _______________________________________________
> > fdo-users mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/fdo-users
> >
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

Well, I tried what you suggested about using cmake instead of automake.

I followed instructions from Cmake_readme, but encountered a few
problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
that werent found. I fixed that by editing the cmake files on ogr and
gdal/src/provider/, adding libgdal1.5.0.so to each linked library
section, like this:

target_link_libraries( GRFPProvider
GRFPOverrides
ProvidersCommon
FDO
libgdal1.5.0.so
)

After that, the cmake command ran with no errors, but when I ran the
make command I get A LOT of this:

CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x34): undefined reference to
`CppUnit::Test::checkIsValidIndex(int) const'
CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x38): undefined reference to
`CppUnit::TestLeaf::doGetChildTestAt(int) const'
CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTIN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[typeinfo
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
for CppUnit::TestCase'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
CppUnit::TestPath&) const'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::findTestPath(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
CppUnit::TestPath&) const'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Message::Message(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
CppUnit::SourceLine const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Message::Message(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
CppUnit::SourceLine const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) const'
collect2: ld devolvió el estado de salida 1
make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all] Error 2
make: *** [all] Error 2

As long as the terminal screen can "remember" :p

Did it happen to you? (both) What do you think the problem may be with SHP? :P

2009/10/6, Traian Stanev <[hidden email]>:

>
> I meant 3.5, not 3.4. :)
>
> I have compiled successfully on Ubuntu using both automake and CMake, but I
> don't remember all the hacks I had to do to make it work using the automake
> build (it was a while back). The pain you are seeing with Thirdparty is that
> the versions of the components in /Thirparty are old and will not compile
> with newer g++. The CMake build uses the versions of those libraries
> installed by Ubuntu itself (using apt-get), so it does not have to compile
> /Thirparty at all. There is a file in /trunk/ called CMake__README.txt which
> explains how to do it.
>
> Traian
>

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

Did you use the "internal" cppunit library or the one that comes by doing apt-get -- i.e. what did you pass to cmake on the command line when you first called it?

I did have some issue with cmake not finding the libgdal since it has a different name on Debian than the cmake module that searches for it expects, but I thought Helio had fixed that recently so I didn't mention it. Personally I did my own build of gdal 1.6 which I used, so I deviated from the official stuff there a bit.

The SHP provider in trunk as compiled by cmake works fine for me on Ubuntu 9.04 64 bit. I assume 32 bit works as well, since that's better tested than the 64 bit. For reading SHP files you can also use the OGR provider, which also works fine for me on 9.04 64 bit.

Traian

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of kernel_panic [[hidden email]]
Sent: Wednesday, October 07, 2009 7:55 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] FDO Compile error (libxalan-c)

Well, I tried what you suggested about using cmake instead of automake.

I followed instructions from Cmake_readme, but encountered a few
problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
that werent found. I fixed that by editing the cmake files on ogr and
gdal/src/provider/, adding libgdal1.5.0.so to each linked library
section, like this:

target_link_libraries( GRFPProvider
GRFPOverrides
ProvidersCommon
FDO
libgdal1.5.0.so
)

After that, the cmake command ran with no errors, but when I ran the
make command I get A LOT of this:

CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x34): undefined reference to
`CppUnit::Test::checkIsValidIndex(int) const'
CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x38): undefined reference to
`CppUnit::TestLeaf::doGetChildTestAt(int) const'
CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTIN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[typeinfo
for CppUnit::TestCaller<FdoExpressionFunctionTest,
CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
for CppUnit::TestCase'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
CppUnit::TestPath&) const'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::findTestPath(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
CppUnit::TestPath&) const'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Message::Message(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
CppUnit::SourceLine const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Message::Message(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
CppUnit::SourceLine const&)'
../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) const'
collect2: ld devolvió el estado de salida 1
make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all] Error 2
make: *** [all] Error 2

As long as the terminal screen can "remember" :p

Did it happen to you? (both) What do you think the problem may be with SHP? :P

2009/10/6, Traian Stanev <[hidden email]>:

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

> Did you use the "internal" cppunit library or the one that comes by doing
> apt-get -- i.e. what did you pass to cmake on the command line when you
> first called it?

Yes, I used the internal cppunit library, as instructed in the cmake
readme file.

BTW, I forgot to post the command line that I used :p :

cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
-DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
-DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE

(I was already root)

If I run make (not cmake) for a second time, this is what I get:

[ 0%] Built target mkcatdefs
[ 3%] Built target sqlite3fdo
[ 3%] Built target FileToHdr
[ 3%] Built target SchemaFromInternal
[ 3%] Built target McToMsf
[ 3%] Built target FDOMessage
[ 3%] Built target ProcessedFiles
[ 20%] Built target FDO
[ 20%] Built target XsdInstallPaths
[ 20%] Built target Internal_Cppunit
[ 22%] Built target UnitTest
[ 23%] Built target ProvidersCommon
[ 24%] Built target TestCommon
[ 29%] Built target ExpressionEngine
[ 31%] Built target FdoOws
[ 31%] Built target SMMessage
[ 32%] Built target SmPhRd
[ 32%] Built target SmOverrides
[ 34%] Built target SmLogicalPhysical
[ 34%] Built target SmPhCfg
[ 34%] Built target SmPhMt
[ 35%] Built target SmPhRb
[ 41%] Built target SmPhysical
[ 41%] Built target SchemaMgr
[ 42%] Built target SQLiteInterface
[ 42%] Built target fdordbmsmsg
[ 47%] Built target FdoRdbms
[ 48%] Built target Gdbi
[ 48%] Built target LTManager
[ 49%] Built target LockManager
[ 49%] Built target geometry_fgf
[ 51%] Built target mysqldr
[ 51%] Built target FdoRdbmsMySQL_Fdo
[ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
[ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
[ 54%] Built target FdoRdbmsMySQL_SchemaMgr
[ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
[ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
[ 59%] Built target rdbi
[ 60%] Built target SmLpGrd
[ 61%] Built target SchemaMgr_OV
[ 61%] Built target SmGrd
[ 61%] Built target SmPhCfgGrd
[ 61%] Built target SmPhRdGrd
[ 62%] Built target SmPhGrd
[ 63%] Built target genericrdbms_util
[ 63%] Built target FdoMySQL
[ 66%] Built target FdoODBCDriver
[ 66%] Built target FdoRdbmsODBC_SchemaMgr
[ 67%] Built target FdoRdbmsODBC_Fdo
[ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
[ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
[ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
[ 70%] Built target FdoODBC
[ 70%] Built target PostGisMessage
[ 71%] Built target PostGISOverrides
[ 74%] Built target PostGISProvider
[ 74%] Built target ShpMessage
[ 74%] Built target SHPOverrides
[ 76%] Built target SHPRead
[ 77%] Built target SHPSpatialIndex
[ 80%] Built target SHPProvider
Linking CXX executable UnitTest

And after that, "the puke" comes on...

> The SHP provider in trunk as compiled by cmake works fine for me on Ubuntu
> 9.04 64 bit. I assume 32 bit works as well, since that's better tested than
> the 64 bit. For reading SHP files you can also use the OGR provider, which
> also works fine for me on 9.04 64 bit.
>

If the OGR provider can deal with SHP files, then, why is there a SHP
provider? :P Are there any limitations? :p

> ________________________________________
> From: [hidden email] [[hidden email]]
> On Behalf Of kernel_panic [[hidden email]]
> Sent: Wednesday, October 07, 2009 7:55 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> Well, I tried what you suggested about using cmake instead of automake.
>
> I followed instructions from Cmake_readme, but encountered a few
> problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
> that werent found. I fixed that by editing the cmake files on ogr and
> gdal/src/provider/, adding libgdal1.5.0.so to each linked library
> section, like this:
>
> target_link_libraries( GRFPProvider
> GRFPOverrides
> ProvidersCommon
> FDO
> libgdal1.5.0.so
> )
>
> After that, the cmake command ran with no errors, but when I ran the
> make command I get A LOT of this:
>
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
> for CppUnit::TestCaller<FdoExpressionFunctionTest,
> CppUnit::NoExceptionExpected>]+0x34): undefined reference to
> `CppUnit::Test::checkIsValidIndex(int) const'
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTVN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[vtable
> for CppUnit::TestCaller<FdoExpressionFunctionTest,
> CppUnit::NoExceptionExpected>]+0x38): undefined reference to
> `CppUnit::TestLeaf::doGetChildTestAt(int) const'
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZTIN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEEE[typeinfo
> for CppUnit::TestCaller<FdoExpressionFunctionTest,
> CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
> for CppUnit::TestCase'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
> CppUnit::TestPath&) const'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Test::findTestPath(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> CppUnit::TestPath&) const'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Message::Message(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&)'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
> CppUnit::SourceLine const&)'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Message::Message(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&, std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&)'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
> CppUnit::SourceLine const&)'
> ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&) const'
> collect2: ld devolvió el estado de salida 1
> make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
> make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all]
> Error 2
> make: *** [all] Error 2
>
>
> As long as the terminal screen can "remember" :p
>
> Did it happen to you? (both) What do you think the problem may be with SHP?
> :P

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Greg Boone

RE: FDO Compile error (libxalan-c)

Reply Threaded

You can try and disable the unit test builds for now. They are optional unless you need to run them to verify a change.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of kernel_panic
Sent: Thursday, October 08, 2009 12:25 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] FDO Compile error (libxalan-c)

> Did you use the "internal" cppunit library or the one that comes by doing
> apt-get -- i.e. what did you pass to cmake on the command line when you
> first called it?

Yes, I used the internal cppunit library, as instructed in the cmake
readme file.

BTW, I forgot to post the command line that I used :p :

cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
-DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
-DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE

(I was already root)

If I run make (not cmake) for a second time, this is what I get:

[ 0%] Built target mkcatdefs
[ 3%] Built target sqlite3fdo
[ 3%] Built target FileToHdr
[ 3%] Built target SchemaFromInternal
[ 3%] Built target McToMsf
[ 3%] Built target FDOMessage
[ 3%] Built target ProcessedFiles
[ 20%] Built target FDO
[ 20%] Built target XsdInstallPaths
[ 20%] Built target Internal_Cppunit
[ 22%] Built target UnitTest
[ 23%] Built target ProvidersCommon
[ 24%] Built target TestCommon
[ 29%] Built target ExpressionEngine
[ 31%] Built target FdoOws
[ 31%] Built target SMMessage
[ 32%] Built target SmPhRd
[ 32%] Built target SmOverrides
[ 34%] Built target SmLogicalPhysical
[ 34%] Built target SmPhCfg
[ 34%] Built target SmPhMt
[ 35%] Built target SmPhRb
[ 41%] Built target SmPhysical
[ 41%] Built target SchemaMgr
[ 42%] Built target SQLiteInterface
[ 42%] Built target fdordbmsmsg
[ 47%] Built target FdoRdbms
[ 48%] Built target Gdbi
[ 48%] Built target LTManager
[ 49%] Built target LockManager
[ 49%] Built target geometry_fgf
[ 51%] Built target mysqldr
[ 51%] Built target FdoRdbmsMySQL_Fdo
[ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
[ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
[ 54%] Built target FdoRdbmsMySQL_SchemaMgr
[ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
[ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
[ 59%] Built target rdbi
[ 60%] Built target SmLpGrd
[ 61%] Built target SchemaMgr_OV
[ 61%] Built target SmGrd
[ 61%] Built target SmPhCfgGrd
[ 61%] Built target SmPhRdGrd
[ 62%] Built target SmPhGrd
[ 63%] Built target genericrdbms_util
[ 63%] Built target FdoMySQL
[ 66%] Built target FdoODBCDriver
[ 66%] Built target FdoRdbmsODBC_SchemaMgr
[ 67%] Built target FdoRdbmsODBC_Fdo
[ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
[ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
[ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
[ 70%] Built target FdoODBC
[ 70%] Built target PostGisMessage
[ 71%] Built target PostGISOverrides
[ 74%] Built target PostGISProvider
[ 74%] Built target ShpMessage
[ 74%] Built target SHPOverrides
[ 76%] Built target SHPRead
[ 77%] Built target SHPSpatialIndex
[ 80%] Built target SHPProvider
Linking CXX executable UnitTest

And after that, "the puke" comes on...

> The SHP provider in trunk as compiled by cmake works fine for me on Ubuntu
> 9.04 64 bit. I assume 32 bit works as well, since that's better tested than
> the 64 bit. For reading SHP files you can also use the OGR provider, which
> also works fine for me on 9.04 64 bit.
>

If the OGR provider can deal with SHP files, then, why is there a SHP
provider? :P Are there any limitations? :p

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

In reply to this post by kernel_panic

I did not use the internal cppunit. I just used the one that Ubuntu installs. So try that...

I did not need to use root until I called make install at the end.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of kernel_panic
> Sent: Thursday, October 08, 2009 12:25 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> > Did you use the "internal" cppunit library or the one that comes by doing
> > apt-get -- i.e. what did you pass to cmake on the command line when you
> > first called it?
>
> Yes, I used the internal cppunit library, as instructed in the cmake
> readme file.
>
> BTW, I forgot to post the command line that I used :p :
>
> cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
> -DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
> -DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE
>
> (I was already root)
>
> If I run make (not cmake) for a second time, this is what I get:
>
> [ 0%] Built target mkcatdefs
> [ 3%] Built target sqlite3fdo
> [ 3%] Built target FileToHdr
> [ 3%] Built target SchemaFromInternal
> [ 3%] Built target McToMsf
> [ 3%] Built target FDOMessage
> [ 3%] Built target ProcessedFiles
> [ 20%] Built target FDO
> [ 20%] Built target XsdInstallPaths
> [ 20%] Built target Internal_Cppunit
> [ 22%] Built target UnitTest
> [ 23%] Built target ProvidersCommon
> [ 24%] Built target TestCommon
> [ 29%] Built target ExpressionEngine
> [ 31%] Built target FdoOws
> [ 31%] Built target SMMessage
> [ 32%] Built target SmPhRd
> [ 32%] Built target SmOverrides
> [ 34%] Built target SmLogicalPhysical
> [ 34%] Built target SmPhCfg
> [ 34%] Built target SmPhMt
> [ 35%] Built target SmPhRb
> [ 41%] Built target SmPhysical
> [ 41%] Built target SchemaMgr
> [ 42%] Built target SQLiteInterface
> [ 42%] Built target fdordbmsmsg
> [ 47%] Built target FdoRdbms
> [ 48%] Built target Gdbi
> [ 48%] Built target LTManager
> [ 49%] Built target LockManager
> [ 49%] Built target geometry_fgf
> [ 51%] Built target mysqldr
> [ 51%] Built target FdoRdbmsMySQL_Fdo
> [ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
> [ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
> [ 54%] Built target FdoRdbmsMySQL_SchemaMgr
> [ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
> [ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
> [ 59%] Built target rdbi
> [ 60%] Built target SmLpGrd
> [ 61%] Built target SchemaMgr_OV
> [ 61%] Built target SmGrd
> [ 61%] Built target SmPhCfgGrd
> [ 61%] Built target SmPhRdGrd
> [ 62%] Built target SmPhGrd
> [ 63%] Built target genericrdbms_util
> [ 63%] Built target FdoMySQL
> [ 66%] Built target FdoODBCDriver
> [ 66%] Built target FdoRdbmsODBC_SchemaMgr
> [ 67%] Built target FdoRdbmsODBC_Fdo
> [ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
> [ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
> [ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
> [ 70%] Built target FdoODBC
> [ 70%] Built target PostGisMessage
> [ 71%] Built target PostGISOverrides
> [ 74%] Built target PostGISProvider
> [ 74%] Built target ShpMessage
> [ 74%] Built target SHPOverrides
> [ 76%] Built target SHPRead
> [ 77%] Built target SHPSpatialIndex
> [ 80%] Built target SHPProvider
> Linking CXX executable UnitTest
>
> And after that, "the puke" comes on...
>
> > The SHP provider in trunk as compiled by cmake works fine for me on Ubuntu
> > 9.04 64 bit. I assume 32 bit works as well, since that's better tested
> than
> > the 64 bit. For reading SHP files you can also use the OGR provider, which
> > also works fine for me on 9.04 64 bit.
> >
>
> If the OGR provider can deal with SHP files, then, why is there a SHP
> provider? :P Are there any limitations? :p
>
>
> > ________________________________________
> > From: [hidden email] [[hidden email]]
> > On Behalf Of kernel_panic [[hidden email]]
> > Sent: Wednesday, October 07, 2009 7:55 PM
> > To: FDO Users Mail List
> > Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> >
> > Well, I tried what you suggested about using cmake instead of automake.
> >
> > I followed instructions from Cmake_readme, but encountered a few
> > problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
> > that werent found. I fixed that by editing the cmake files on ogr and
> > gdal/src/provider/, adding libgdal1.5.0.so to each linked library
> > section, like this:
> >
> > target_link_libraries( GRFPProvider
> > GRFPOverrides
> > ProvidersCommon
> > FDO
> > libgdal1.5.0.so
> > )
> >
> > After that, the cmake command ran with no errors, but when I ran the
> > make command I get A LOT of this:
> >
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> E[vtable
> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > CppUnit::NoExceptionExpected>]+0x34): undefined reference to
> > `CppUnit::Test::checkIsValidIndex(int) const'
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> E[vtable
> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > CppUnit::NoExceptionExpected>]+0x38): undefined reference to
> > `CppUnit::TestLeaf::doGetChildTestAt(int) const'
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> IN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> E[typeinfo
> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
> > for CppUnit::TestCase'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
> > CppUnit::TestPath&) const'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Test::findTestPath(std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&,
> > CppUnit::TestPath&) const'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Message::Message(std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&,
> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> > const&)'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
> > CppUnit::SourceLine const&)'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Message::Message(std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&,
> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> > const&, std::basic_string<char, std::char_traits<char>,
> > std::allocator<char> > const&)'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
> > CppUnit::SourceLine const&)'
> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&) const'
> > collect2: ld devolvió el estado de salida 1
> > make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
> > make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all]
> > Error 2
> > make: *** [all] Error 2
> >
> >
> > As long as the terminal screen can "remember" :p
> >
> > Did it happen to you? (both) What do you think the problem may be with SHP?
> > :P
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

@ Traian:

I used ubuntu's cpp instead of the internal, now I didnt have the
error listed earlier, but I got this new one:

[ 91%] Built target GDALUnitTest
Scanning dependencies of target OGRProvider
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/OgrFdoUtil.cpp.o
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/OgrProvider.cpp.o
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp: In member function
‘FdoIFeatureReader* OgrConnection::Insert(FdoIdentifier*,
FdoPropertyValueCollection*)’:
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
‘%d’ espera el tipo ‘int’, pero el argumento 4 es de tipo ‘long int’
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
‘%d’ espera el tipo ‘int’, pero el argumento 4 es de tipo ‘long int’
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/ProjConverter.cpp.o
Linking CXX shared library libOGRProvider.so
[ 91%] Built target OGRProvider
Scanning dependencies of target SDFMessage
[ 91%] Generating SDFMessage.h ...
../../../../Thirdparty/linux/mkcatdefs/src/mkcatdefs: SDFMessage_msg.h created
cat: /opt/fdo-3.5_D032/Providers/SDF/Src/Message/SDFMessageStatic.h:
No existe el fichero ó directorio
make[2]: *** [Providers/SDF/Src/Message/Inc/SDFMessage.h] Error 1
make[1]: *** [Providers/SDF/Src/Message/CMakeFiles/SDFMessage.dir/all] Error 2
make: *** [all] Error 2

The commandline was the same, except for the internal cpp part.

@ Greg Boone:

How do I disable them? :p

2009/10/8, Traian Stanev <[hidden email]>:

>
> I did not use the internal cppunit. I just used the one that Ubuntu
> installs. So try that...
>
> I did not need to use root until I called make install at the end.
>
> Traian
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:fdo-users-
>> [hidden email]] On Behalf Of kernel_panic
>> Sent: Thursday, October 08, 2009 12:25 PM
>> To: FDO Users Mail List
>> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>>
>> > Did you use the "internal" cppunit library or the one that comes by
>> > doing
>> > apt-get -- i.e. what did you pass to cmake on the command line when you
>> > first called it?
>>
>> Yes, I used the internal cppunit library, as instructed in the cmake
>> readme file.
>>
>> BTW, I forgot to post the command line that I used :p :
>>
>> cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
>> -DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
>> -DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE
>>
>> (I was already root)
>>
>> If I run make (not cmake) for a second time, this is what I get:
>>
>> [ 0%] Built target mkcatdefs
>> [ 3%] Built target sqlite3fdo
>> [ 3%] Built target FileToHdr
>> [ 3%] Built target SchemaFromInternal
>> [ 3%] Built target McToMsf
>> [ 3%] Built target FDOMessage
>> [ 3%] Built target ProcessedFiles
>> [ 20%] Built target FDO
>> [ 20%] Built target XsdInstallPaths
>> [ 20%] Built target Internal_Cppunit
>> [ 22%] Built target UnitTest
>> [ 23%] Built target ProvidersCommon
>> [ 24%] Built target TestCommon
>> [ 29%] Built target ExpressionEngine
>> [ 31%] Built target FdoOws
>> [ 31%] Built target SMMessage
>> [ 32%] Built target SmPhRd
>> [ 32%] Built target SmOverrides
>> [ 34%] Built target SmLogicalPhysical
>> [ 34%] Built target SmPhCfg
>> [ 34%] Built target SmPhMt
>> [ 35%] Built target SmPhRb
>> [ 41%] Built target SmPhysical
>> [ 41%] Built target SchemaMgr
>> [ 42%] Built target SQLiteInterface
>> [ 42%] Built target fdordbmsmsg
>> [ 47%] Built target FdoRdbms
>> [ 48%] Built target Gdbi
>> [ 48%] Built target LTManager
>> [ 49%] Built target LockManager
>> [ 49%] Built target geometry_fgf
>> [ 51%] Built target mysqldr
>> [ 51%] Built target FdoRdbmsMySQL_Fdo
>> [ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
>> [ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
>> [ 54%] Built target FdoRdbmsMySQL_SchemaMgr
>> [ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
>> [ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
>> [ 59%] Built target rdbi
>> [ 60%] Built target SmLpGrd
>> [ 61%] Built target SchemaMgr_OV
>> [ 61%] Built target SmGrd
>> [ 61%] Built target SmPhCfgGrd
>> [ 61%] Built target SmPhRdGrd
>> [ 62%] Built target SmPhGrd
>> [ 63%] Built target genericrdbms_util
>> [ 63%] Built target FdoMySQL
>> [ 66%] Built target FdoODBCDriver
>> [ 66%] Built target FdoRdbmsODBC_SchemaMgr
>> [ 67%] Built target FdoRdbmsODBC_Fdo
>> [ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
>> [ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
>> [ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
>> [ 70%] Built target FdoODBC
>> [ 70%] Built target PostGisMessage
>> [ 71%] Built target PostGISOverrides
>> [ 74%] Built target PostGISProvider
>> [ 74%] Built target ShpMessage
>> [ 74%] Built target SHPOverrides
>> [ 76%] Built target SHPRead
>> [ 77%] Built target SHPSpatialIndex
>> [ 80%] Built target SHPProvider
>> Linking CXX executable UnitTest
>>
>> And after that, "the puke" comes on...
>>
>> > The SHP provider in trunk as compiled by cmake works fine for me on
>> > Ubuntu
>> > 9.04 64 bit. I assume 32 bit works as well, since that's better tested
>> than
>> > the 64 bit. For reading SHP files you can also use the OGR provider,
>> > which
>> > also works fine for me on 9.04 64 bit.
>> >
>>
>> If the OGR provider can deal with SHP files, then, why is there a SHP
>> provider? :P Are there any limitations? :p
>>
>>
>> > ________________________________________
>> > From: [hidden email]
>> > [[hidden email]]
>> > On Behalf Of kernel_panic [[hidden email]]
>> > Sent: Wednesday, October 07, 2009 7:55 PM
>> > To: FDO Users Mail List
>> > Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>> >
>> > Well, I tried what you suggested about using cmake instead of automake.
>> >
>> > I followed instructions from Cmake_readme, but encountered a few
>> > problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
>> > that werent found. I fixed that by editing the cmake files on ogr and
>> > gdal/src/provider/, adding libgdal1.5.0.so to each linked library
>> > section, like this:
>> >
>> > target_link_libraries( GRFPProvider
>> > GRFPOverrides
>> > ProvidersCommon
>> > FDO
>> > libgdal1.5.0.so
>> > )
>> >
>> > After that, the cmake command ran with no errors, but when I ran the
>> > make command I get A LOT of this:
>> >
>> >
>> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
>> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
>> E[vtable
>> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
>> > CppUnit::NoExceptionExpected>]+0x34): undefined reference to
>> > `CppUnit::Test::checkIsValidIndex(int) const'
>> >
>> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
>> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
>> E[vtable
>> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
>> > CppUnit::NoExceptionExpected>]+0x38): undefined reference to
>> > `CppUnit::TestLeaf::doGetChildTestAt(int) const'
>> >
>> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
>> IN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
>> E[typeinfo
>> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
>> > CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
>> > for CppUnit::TestCase'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
>> > CppUnit::TestPath&) const'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Test::findTestPath(std::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&,
>> > CppUnit::TestPath&) const'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Message::Message(std::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&,
>> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>> > const&)'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
>> > CppUnit::SourceLine const&)'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Message::Message(std::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&,
>> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>> > const&, std::basic_string<char, std::char_traits<char>,
>> > std::allocator<char> > const&)'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
>> > CppUnit::SourceLine const&)'
>> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
>> > reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&) const'
>> > collect2: ld devolvió el estado de salida 1
>> > make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
>> > make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all]
>> > Error 2
>> > make: *** [all] Error 2
>> >
>> >
>> > As long as the terminal screen can "remember" :p
>> >
>> > Did it happen to you? (both) What do you think the problem may be with
>> > SHP?
>> > :P
>> _______________________________________________
>> fdo-users mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

I did not get the problem with the message catalog file... I'll give it a try again and reply back if I find something.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of kernel_panic
> Sent: Thursday, October 08, 2009 1:32 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> @ Traian:
>
> I used ubuntu's cpp instead of the internal, now I didnt have the
> error listed earlier, but I got this new one:
>
> [ 91%] Built target GDALUnitTest
> Scanning dependencies of target OGRProvider
> [ 91%] Building CXX object
> Providers/OGR/CMakeFiles/OGRProvider.dir/OgrFdoUtil.cpp.o
> [ 91%] Building CXX object
> Providers/OGR/CMakeFiles/OGRProvider.dir/OgrProvider.cpp.o
> /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp: In member function
> 'FdoIFeatureReader* OgrConnection::Insert(FdoIdentifier*,
> FdoPropertyValueCollection*)':
> /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
> '%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
> /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
> '%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
> [ 91%] Building CXX object
> Providers/OGR/CMakeFiles/OGRProvider.dir/ProjConverter.cpp.o
> Linking CXX shared library libOGRProvider.so
> [ 91%] Built target OGRProvider
> Scanning dependencies of target SDFMessage
> [ 91%] Generating SDFMessage.h ...
> ../../../../Thirdparty/linux/mkcatdefs/src/mkcatdefs: SDFMessage_msg.h
> created
> cat: /opt/fdo-3.5_D032/Providers/SDF/Src/Message/SDFMessageStatic.h:
> No existe el fichero ó directorio
> make[2]: *** [Providers/SDF/Src/Message/Inc/SDFMessage.h] Error 1
> make[1]: *** [Providers/SDF/Src/Message/CMakeFiles/SDFMessage.dir/all] Error
> 2
> make: *** [all] Error 2
>
> The commandline was the same, except for the internal cpp part.
>
> @ Greg Boone:
>
> How do I disable them? :p
>
> 2009/10/8, Traian Stanev <[hidden email]>:
> >
> > I did not use the internal cppunit. I just used the one that Ubuntu
> > installs. So try that...
> >
> > I did not need to use root until I called make install at the end.
> >
> > Traian
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:fdo-users-
> >> [hidden email]] On Behalf Of kernel_panic
> >> Sent: Thursday, October 08, 2009 12:25 PM
> >> To: FDO Users Mail List
> >> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> >>
> >> > Did you use the "internal" cppunit library or the one that comes by
> >> > doing
> >> > apt-get -- i.e. what did you pass to cmake on the command line when you
> >> > first called it?
> >>
> >> Yes, I used the internal cppunit library, as instructed in the cmake
> >> readme file.
> >>
> >> BTW, I forgot to post the command line that I used :p :
> >>
> >> cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
> >> -DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
> >> -DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE
> >>
> >> (I was already root)
> >>
> >> If I run make (not cmake) for a second time, this is what I get:
> >>
> >> [ 0%] Built target mkcatdefs
> >> [ 3%] Built target sqlite3fdo
> >> [ 3%] Built target FileToHdr
> >> [ 3%] Built target SchemaFromInternal
> >> [ 3%] Built target McToMsf
> >> [ 3%] Built target FDOMessage
> >> [ 3%] Built target ProcessedFiles
> >> [ 20%] Built target FDO
> >> [ 20%] Built target XsdInstallPaths
> >> [ 20%] Built target Internal_Cppunit
> >> [ 22%] Built target UnitTest
> >> [ 23%] Built target ProvidersCommon
> >> [ 24%] Built target TestCommon
> >> [ 29%] Built target ExpressionEngine
> >> [ 31%] Built target FdoOws
> >> [ 31%] Built target SMMessage
> >> [ 32%] Built target SmPhRd
> >> [ 32%] Built target SmOverrides
> >> [ 34%] Built target SmLogicalPhysical
> >> [ 34%] Built target SmPhCfg
> >> [ 34%] Built target SmPhMt
> >> [ 35%] Built target SmPhRb
> >> [ 41%] Built target SmPhysical
> >> [ 41%] Built target SchemaMgr
> >> [ 42%] Built target SQLiteInterface
> >> [ 42%] Built target fdordbmsmsg
> >> [ 47%] Built target FdoRdbms
> >> [ 48%] Built target Gdbi
> >> [ 48%] Built target LTManager
> >> [ 49%] Built target LockManager
> >> [ 49%] Built target geometry_fgf
> >> [ 51%] Built target mysqldr
> >> [ 51%] Built target FdoRdbmsMySQL_Fdo
> >> [ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
> >> [ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
> >> [ 54%] Built target FdoRdbmsMySQL_SchemaMgr
> >> [ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
> >> [ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
> >> [ 59%] Built target rdbi
> >> [ 60%] Built target SmLpGrd
> >> [ 61%] Built target SchemaMgr_OV
> >> [ 61%] Built target SmGrd
> >> [ 61%] Built target SmPhCfgGrd
> >> [ 61%] Built target SmPhRdGrd
> >> [ 62%] Built target SmPhGrd
> >> [ 63%] Built target genericrdbms_util
> >> [ 63%] Built target FdoMySQL
> >> [ 66%] Built target FdoODBCDriver
> >> [ 66%] Built target FdoRdbmsODBC_SchemaMgr
> >> [ 67%] Built target FdoRdbmsODBC_Fdo
> >> [ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
> >> [ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
> >> [ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
> >> [ 70%] Built target FdoODBC
> >> [ 70%] Built target PostGisMessage
> >> [ 71%] Built target PostGISOverrides
> >> [ 74%] Built target PostGISProvider
> >> [ 74%] Built target ShpMessage
> >> [ 74%] Built target SHPOverrides
> >> [ 76%] Built target SHPRead
> >> [ 77%] Built target SHPSpatialIndex
> >> [ 80%] Built target SHPProvider
> >> Linking CXX executable UnitTest
> >>
> >> And after that, "the puke" comes on...
> >>
> >> > The SHP provider in trunk as compiled by cmake works fine for me on
> >> > Ubuntu
> >> > 9.04 64 bit. I assume 32 bit works as well, since that's better tested
> >> than
> >> > the 64 bit. For reading SHP files you can also use the OGR provider,
> >> > which
> >> > also works fine for me on 9.04 64 bit.
> >> >
> >>
> >> If the OGR provider can deal with SHP files, then, why is there a SHP
> >> provider? :P Are there any limitations? :p
> >>
> >>
> >> > ________________________________________
> >> > From: [hidden email]
> >> > [[hidden email]]
> >> > On Behalf Of kernel_panic [[hidden email]]
> >> > Sent: Wednesday, October 07, 2009 7:55 PM
> >> > To: FDO Users Mail List
> >> > Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> >> >
> >> > Well, I tried what you suggested about using cmake instead of automake.
> >> >
> >> > I followed instructions from Cmake_readme, but encountered a few
> >> > problems regarding to GDAL libraries being linked by OGR, GDAL and WMS
> >> > that werent found. I fixed that by editing the cmake files on ogr and
> >> > gdal/src/provider/, adding libgdal1.5.0.so to each linked library
> >> > section, like this:
> >> >
> >> > target_link_libraries( GRFPProvider
> >> > GRFPOverrides
> >> > ProvidersCommon
> >> > FDO
> >> > libgdal1.5.0.so
> >> > )
> >> >
> >> > After that, the cmake command ran with no errors, but when I ran the
> >> > make command I get A LOT of this:
> >> >
> >> >
> >>
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> >>
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> >> E[vtable
> >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> >> > CppUnit::NoExceptionExpected>]+0x34): undefined reference to
> >> > `CppUnit::Test::checkIsValidIndex(int) const'
> >> >
> >>
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> >>
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> >> E[vtable
> >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> >> > CppUnit::NoExceptionExpected>]+0x38): undefined reference to
> >> > `CppUnit::TestLeaf::doGetChildTestAt(int) const'
> >> >
> >>
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> >>
> IN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> >> E[typeinfo
> >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> >> > CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
> >> > for CppUnit::TestCase'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
> >> > CppUnit::TestPath&) const'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Test::findTestPath(std::basic_string<char,
> >> > std::char_traits<char>, std::allocator<char> > const&,
> >> > CppUnit::TestPath&) const'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Message::Message(std::basic_string<char,
> >> > std::char_traits<char>, std::allocator<char> > const&,
> >> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> >> > const&)'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
> >> > CppUnit::SourceLine const&)'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Message::Message(std::basic_string<char,
> >> > std::char_traits<char>, std::allocator<char> > const&,
> >> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> >> > const&, std::basic_string<char, std::char_traits<char>,
> >> > std::allocator<char> > const&)'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
> >> > CppUnit::SourceLine const&)'
> >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> >> > reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
> >> > std::char_traits<char>, std::allocator<char> > const&) const'
> >> > collect2: ld devolvió el estado de salida 1
> >> > make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
> >> > make[1]: *** [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all]
> >> > Error 2
> >> > make: *** [all] Error 2
> >> >
> >> >
> >> > As long as the terminal screen can "remember" :p
> >> >
> >> > Did it happen to you? (both) What do you think the problem may be with
> >> > SHP?
> >> > :P
> >> _______________________________________________
> >> fdo-users mailing list
> >> [hidden email]
> >> http://lists.osgeo.org/mailman/listinfo/fdo-users
> > _______________________________________________
> > fdo-users mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/fdo-users
> >
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

OK, if I do a clean and then compile SDF, I get this error. Then, I ran make again and it disappeared... I guess it fixes itself somehow when you run make the second time... Weird.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of Traian Stanev
> Sent: Thursday, October 08, 2009 1:49 PM
> To: FDO Users Mail List
> Subject: RE: [fdo-users] FDO Compile error (libxalan-c)
>
>
> I did not get the problem with the message catalog file... I'll give it a
> try again and reply back if I find something.
>
> Traian
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:fdo-users-
> > [hidden email]] On Behalf Of kernel_panic
> > Sent: Thursday, October 08, 2009 1:32 PM
> > To: FDO Users Mail List
> > Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> >
> > @ Traian:
> >
> > I used ubuntu's cpp instead of the internal, now I didnt have the
> > error listed earlier, but I got this new one:
> >
> > [ 91%] Built target GDALUnitTest
> > Scanning dependencies of target OGRProvider
> > [ 91%] Building CXX object
> > Providers/OGR/CMakeFiles/OGRProvider.dir/OgrFdoUtil.cpp.o
> > [ 91%] Building CXX object
> > Providers/OGR/CMakeFiles/OGRProvider.dir/OgrProvider.cpp.o
> > /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp: In member function
> > 'FdoIFeatureReader* OgrConnection::Insert(FdoIdentifier*,
> > FdoPropertyValueCollection*)':
> > /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
> > '%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
> > /opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
> > '%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
> > [ 91%] Building CXX object
> > Providers/OGR/CMakeFiles/OGRProvider.dir/ProjConverter.cpp.o
> > Linking CXX shared library libOGRProvider.so
> > [ 91%] Built target OGRProvider
> > Scanning dependencies of target SDFMessage
> > [ 91%] Generating SDFMessage.h ...
> > ../../../../Thirdparty/linux/mkcatdefs/src/mkcatdefs: SDFMessage_msg.h
> > created
> > cat: /opt/fdo-3.5_D032/Providers/SDF/Src/Message/SDFMessageStatic.h:
> > No existe el fichero ó directorio
> > make[2]: *** [Providers/SDF/Src/Message/Inc/SDFMessage.h] Error 1
> > make[1]: *** [Providers/SDF/Src/Message/CMakeFiles/SDFMessage.dir/all]
> Error
> > 2
> > make: *** [all] Error 2
> >
> > The commandline was the same, except for the internal cpp part.
> >
> > @ Greg Boone:
> >
> > How do I disable them? :p
> >
> > 2009/10/8, Traian Stanev <[hidden email]>:
> > >
> > > I did not use the internal cppunit. I just used the one that Ubuntu
> > > installs. So try that...
> > >
> > > I did not need to use root until I called make install at the end.
> > >
> > > Traian
> > >
> > >
> > >> -----Original Message-----
> > >> From: [hidden email] [mailto:fdo-users-
> > >> [hidden email]] On Behalf Of kernel_panic
> > >> Sent: Thursday, October 08, 2009 12:25 PM
> > >> To: FDO Users Mail List
> > >> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> > >>
> > >> > Did you use the "internal" cppunit library or the one that comes by
> > >> > doing
> > >> > apt-get -- i.e. what did you pass to cmake on the command line when
> you
> > >> > first called it?
> > >>
> > >> Yes, I used the internal cppunit library, as instructed in the cmake
> > >> readme file.
> > >>
> > >> BTW, I forgot to post the command line that I used :p :
> > >>
> > >> cmake /opt/fdo-3.5_D032/ -DINTERNAL_CPPUNIT=TRUE -DWITH_GDAL=TRUE
> > >> -DWITH_GENERICRDBMS=TRUE -DWITH_OGR=TRUE -DWITH_POSTGIS=TRUE
> > >> -DWITH_SDF=TRUE -DWITH_SHP=TRUE -DWITH_WFS=TRUE -DWITH_WMS=TRUE
> > >>
> > >> (I was already root)
> > >>
> > >> If I run make (not cmake) for a second time, this is what I get:
> > >>
> > >> [ 0%] Built target mkcatdefs
> > >> [ 3%] Built target sqlite3fdo
> > >> [ 3%] Built target FileToHdr
> > >> [ 3%] Built target SchemaFromInternal
> > >> [ 3%] Built target McToMsf
> > >> [ 3%] Built target FDOMessage
> > >> [ 3%] Built target ProcessedFiles
> > >> [ 20%] Built target FDO
> > >> [ 20%] Built target XsdInstallPaths
> > >> [ 20%] Built target Internal_Cppunit
> > >> [ 22%] Built target UnitTest
> > >> [ 23%] Built target ProvidersCommon
> > >> [ 24%] Built target TestCommon
> > >> [ 29%] Built target ExpressionEngine
> > >> [ 31%] Built target FdoOws
> > >> [ 31%] Built target SMMessage
> > >> [ 32%] Built target SmPhRd
> > >> [ 32%] Built target SmOverrides
> > >> [ 34%] Built target SmLogicalPhysical
> > >> [ 34%] Built target SmPhCfg
> > >> [ 34%] Built target SmPhMt
> > >> [ 35%] Built target SmPhRb
> > >> [ 41%] Built target SmPhysical
> > >> [ 41%] Built target SchemaMgr
> > >> [ 42%] Built target SQLiteInterface
> > >> [ 42%] Built target fdordbmsmsg
> > >> [ 47%] Built target FdoRdbms
> > >> [ 48%] Built target Gdbi
> > >> [ 48%] Built target LTManager
> > >> [ 49%] Built target LockManager
> > >> [ 49%] Built target geometry_fgf
> > >> [ 51%] Built target mysqldr
> > >> [ 51%] Built target FdoRdbmsMySQL_Fdo
> > >> [ 51%] Built target FdoRdbmsMySQL_SchemaMgr_Lp
> > >> [ 53%] Built target FdoRdbmsMySQL_SchemaMgr_Ov
> > >> [ 54%] Built target FdoRdbmsMySQL_SchemaMgr
> > >> [ 55%] Built target FdoRdbmsMySQL_SchemaMgr_Ph_Rd
> > >> [ 56%] Built target FdoRdbmsMySQL_SchemaMgr_Ph
> > >> [ 59%] Built target rdbi
> > >> [ 60%] Built target SmLpGrd
> > >> [ 61%] Built target SchemaMgr_OV
> > >> [ 61%] Built target SmGrd
> > >> [ 61%] Built target SmPhCfgGrd
> > >> [ 61%] Built target SmPhRdGrd
> > >> [ 62%] Built target SmPhGrd
> > >> [ 63%] Built target genericrdbms_util
> > >> [ 63%] Built target FdoMySQL
> > >> [ 66%] Built target FdoODBCDriver
> > >> [ 66%] Built target FdoRdbmsODBC_SchemaMgr
> > >> [ 67%] Built target FdoRdbmsODBC_Fdo
> > >> [ 67%] Built target FdoRdbmsODBC_SchemaMgr_Lp
> > >> [ 68%] Built target FdoRdbmsODBC_SchemaMgr_Ov
> > >> [ 70%] Built target FdoRdbmsODBC_SchemaMgr_Ph
> > >> [ 70%] Built target FdoODBC
> > >> [ 70%] Built target PostGisMessage
> > >> [ 71%] Built target PostGISOverrides
> > >> [ 74%] Built target PostGISProvider
> > >> [ 74%] Built target ShpMessage
> > >> [ 74%] Built target SHPOverrides
> > >> [ 76%] Built target SHPRead
> > >> [ 77%] Built target SHPSpatialIndex
> > >> [ 80%] Built target SHPProvider
> > >> Linking CXX executable UnitTest
> > >>
> > >> And after that, "the puke" comes on...
> > >>
> > >> > The SHP provider in trunk as compiled by cmake works fine for me on
> > >> > Ubuntu
> > >> > 9.04 64 bit. I assume 32 bit works as well, since that's better
> tested
> > >> than
> > >> > the 64 bit. For reading SHP files you can also use the OGR provider,
> > >> > which
> > >> > also works fine for me on 9.04 64 bit.
> > >> >
> > >>
> > >> If the OGR provider can deal with SHP files, then, why is there a SHP
> > >> provider? :P Are there any limitations? :p
> > >>
> > >>
> > >> > ________________________________________
> > >> > From: [hidden email]
> > >> > [[hidden email]]
> > >> > On Behalf Of kernel_panic [[hidden email]]
> > >> > Sent: Wednesday, October 07, 2009 7:55 PM
> > >> > To: FDO Users Mail List
> > >> > Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
> > >> >
> > >> > Well, I tried what you suggested about using cmake instead of
> automake.
> > >> >
> > >> > I followed instructions from Cmake_readme, but encountered a few
> > >> > problems regarding to GDAL libraries being linked by OGR, GDAL and
> WMS
> > >> > that werent found. I fixed that by editing the cmake files on ogr and
> > >> > gdal/src/provider/, adding libgdal1.5.0.so to each linked library
> > >> > section, like this:
> > >> >
> > >> > target_link_libraries( GRFPProvider
> > >> > GRFPOverrides
> > >> > ProvidersCommon
> > >> > FDO
> > >> > libgdal1.5.0.so
> > >> > )
> > >> >
> > >> > After that, the cmake command ran with no errors, but when I ran the
> > >> > make command I get A LOT of this:
> > >> >
> > >> >
> > >>
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> > >>
> >
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> > >> E[vtable
> > >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > >> > CppUnit::NoExceptionExpected>]+0x34): undefined reference to
> > >> > `CppUnit::Test::checkIsValidIndex(int) const'
> > >> >
> > >>
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> > >>
> >
> VN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> > >> E[vtable
> > >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > >> > CppUnit::NoExceptionExpected>]+0x38): undefined reference to
> > >> > `CppUnit::TestLeaf::doGetChildTestAt(int) const'
> > >> >
> > >>
> >
> CMakeFiles/SHPUnitTest.dir/FdoExpressionFunctionTest.cpp.o:(.data.rel.ro._ZT
> > >>
> >
> IN7CppUnit10TestCallerI25FdoExpressionFunctionTestNS_19NoExceptionExpectedEE
> > >> E[typeinfo
> > >> > for CppUnit::TestCaller<FdoExpressionFunctionTest,
> > >> > CppUnit::NoExceptionExpected>]+0x8): undefined reference to `typeinfo
> > >> > for CppUnit::TestCase'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Test::findTestPath(CppUnit::Test const*,
> > >> > CppUnit::TestPath&) const'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Test::findTestPath(std::basic_string<char,
> > >> > std::char_traits<char>, std::allocator<char> > const&,
> > >> > CppUnit::TestPath&) const'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Message::Message(std::basic_string<char,
> > >> > std::char_traits<char>, std::allocator<char> > const&,
> > >> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> > >> > const&)'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Asserter::fail(CppUnit::Message const&,
> > >> > CppUnit::SourceLine const&)'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Message::Message(std::basic_string<char,
> > >> > std::char_traits<char>, std::allocator<char> > const&,
> > >> > std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> > >> > const&, std::basic_string<char, std::char_traits<char>,
> > >> > std::allocator<char> > const&)'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Asserter::failIf(bool, CppUnit::Message const&,
> > >> > CppUnit::SourceLine const&)'
> > >> > ../../../../Utilities/TestCommon/libTestCommon.so.3.5.0: undefined
> > >> > reference to `CppUnit::Test::resolveTestPath(std::basic_string<char,
> > >> > std::char_traits<char>, std::allocator<char> > const&) const'
> > >> > collect2: ld devolvió el estado de salida 1
> > >> > make[2]: *** [Providers/SHP/Src/UnitTest/UnitTest] Error 1
> > >> > make[1]: ***
> [Providers/SHP/Src/UnitTest/CMakeFiles/SHPUnitTest.dir/all]
> > >> > Error 2
> > >> > make: *** [all] Error 2
> > >> >
> > >> >
> > >> > As long as the terminal screen can "remember" :p
> > >> >
> > >> > Did it happen to you? (both) What do you think the problem may be
> with
> > >> > SHP?
> > >> > :P
> > >> _______________________________________________
> > >> fdo-users mailing list
> > >> [hidden email]
> > >> http://lists.osgeo.org/mailman/listinfo/fdo-users
> > > _______________________________________________
> > > fdo-users mailing list
> > > [hidden email]
> > > http://lists.osgeo.org/mailman/listinfo/fdo-users
> > >
> > _______________________________________________
> > fdo-users mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/fdo-users
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Greg Boone

RE: FDO Compile error (libxalan-c)

Reply Threaded

In reply to this post by kernel_panic

Disabling Unit Tests... not an option, you would have to manually pull it out of the cmake files.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of kernel_panic
Sent: Thursday, October 08, 2009 1:32 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] FDO Compile error (libxalan-c)

@ Traian:

I used ubuntu's cpp instead of the internal, now I didnt have the
error listed earlier, but I got this new one:

[ 91%] Built target GDALUnitTest
Scanning dependencies of target OGRProvider
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/OgrFdoUtil.cpp.o
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/OgrProvider.cpp.o
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp: In member function
'FdoIFeatureReader* OgrConnection::Insert(FdoIdentifier*,
FdoPropertyValueCollection*)':
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
'%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
/opt/fdo-3.5_D032/Providers/OGR/OgrProvider.cpp:585: aviso: el formato
'%d' espera el tipo 'int', pero el argumento 4 es de tipo 'long int'
[ 91%] Building CXX object
Providers/OGR/CMakeFiles/OGRProvider.dir/ProjConverter.cpp.o
Linking CXX shared library libOGRProvider.so
[ 91%] Built target OGRProvider
Scanning dependencies of target SDFMessage
[ 91%] Generating SDFMessage.h ...
../../../../Thirdparty/linux/mkcatdefs/src/mkcatdefs: SDFMessage_msg.h created
cat: /opt/fdo-3.5_D032/Providers/SDF/Src/Message/SDFMessageStatic.h:
No existe el fichero ó directorio
make[2]: *** [Providers/SDF/Src/Message/Inc/SDFMessage.h] Error 1
make[1]: *** [Providers/SDF/Src/Message/CMakeFiles/SDFMessage.dir/all] Error 2
make: *** [all] Error 2

The commandline was the same, except for the internal cpp part.

@ Greg Boone:

How do I disable them? :p

2009/10/8, Traian Stanev <[hidden email]>:

kernel_panic

Re: FDO Compile error (libxalan-c)

Reply Threaded

In reply to this post by Traian Stanev

2009/10/8, Traian Stanev <[hidden email]>:
> OK, if I do a clean and then compile SDF, I get this error. Then, I ran make
> again and it disappeared... I guess it fixes itself somehow when you run
> make the second time... Weird.
>
> Traian

Confirmed. After running cmake for the second time, the previous noted
error did not appear, and the build was complete.

Now, FDO is completely installed? I mean, no more scripts like
buld_thirdparty and build_linux.sh
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

Yes, after running make successfully, just do a

sudo make install

and you should be all done. Check /usr/local/lib (or /usr/local/lib64) to make sure there is an fdo-3.5.0 directory in there.

Traian

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of kernel_panic [[hidden email]]
Sent: Thursday, October 08, 2009 7:13 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] FDO Compile error (libxalan-c)

2009/10/8, Traian Stanev <[hidden email]>:
> OK, if I do a clean and then compile SDF, I get this error. Then, I ran make
> again and it disappeared... I guess it fixes itself somehow when you run
> make the second time... Weird.
>
> Traian

Confirmed. After running cmake for the second time, the previous noted
error did not appear, and the build was complete.

Now, FDO is completely installed? I mean, no more scripts like
buld_thirdparty and build_linux.sh
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

Traian Stanev

RE: FDO Compile error (libxalan-c)

Reply Threaded

In reply to this post by kernel_panic

BTW, thanks for going through with this, I have updated the CMake readme file to say that the internal cppunit should no longer be used, so that the next person to attempt this will have an easier time.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:fdo-users-
> [hidden email]] On Behalf Of kernel_panic
> Sent: Thursday, October 08, 2009 7:13 PM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] FDO Compile error (libxalan-c)
>
> 2009/10/8, Traian Stanev <[hidden email]>:
> > OK, if I do a clean and then compile SDF, I get this error. Then, I ran
> make
> > again and it disappeared... I guess it fixes itself somehow when you run
> > make the second time... Weird.
> >
> > Traian
>
> Confirmed. After running cmake for the second time, the previous noted
> error did not appear, and the build was complete.
>
> Now, FDO is completely installed? I mean, no more scripts like
> buld_thirdparty and build_linux.sh
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

1 2 3