[fdo-users] PostGIS provider undefined symbols
Greg
aquarius1975 at gmail.com
Mon Dec 14 11:24:24 EST 2009
There's just the name of the library file as is the case with the
other providers:
<LibraryPath>libPostGISProvider.so</LibraryPath>
I also tried
<LibraryPath>./libPostGISProvider.so</LibraryPath>
and
<LibraryPath>/usr/local/fdo-3.4.0/lib/libPostGISProvider.so</LibraryPath>
None of these works...
Greg
On Mon, Dec 14, 2009 at 5:11 PM, Traian Stanev
<traian.stanev at autodesk.com> wrote:
>
> What does your providers.xml file entry for PostGIS say? Note, providers.xml is located in the same place as libFDO and contains the location of your libPostGIS.so. If that location is wrong, it will try to load the wrong so.
>
> Traian
>
>
>
>
> -----Original Message-----
> From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Greg
> Sent: Monday, December 14, 2009 5:17 AM
> To: fdo-users at lists.osgeo.org
> Subject: Re: [fdo-users] PostGIS provider undefined symbols
>
> Hi
>
> I made a step ahead, I managed to link libPostGIS provider correctly
> without missing references to other libraries.
> I realized that the dynamic linker (ld.so) doesn't take into account
> the current directory of a given library implicitly
> (as Windows does), it has to be listed in ld.so.conf or in LD_LIBRARY_PATH.
> I also had to tweak Makefile.am to add libExpressionEngine.so and the
> Postgres client library libpg.a
> (but in this case I used the library of my Postgres installation, not
> the internal one),
> and then ldd yielded a squeaky clean output.
> I happily proceeded to test the new build of the library, but still no
> joy - the same message was in the log file:
> CLNT_8_UNABLE_TO_LOAD_LIBRARY...
> Then I tracked down the spot in the source code where the error happened.
> I found out that it was a call to dlopen, so I wrote a little test
> program consisting of a few lines of code
> just to load the problematic provider with dlopen, and it loaded perfectly fine.
> I tried to put some fprintf calls to log what path dlopen is actually
> called with,
>
> // Fdo/Unmanaged/Src/Fdo/ClientServices/ConnectionManager.cpp
>
> FdoRegistryUtility::GetLibraryLocation(providerName, libraryLocation);
> addPath (libraryLocation);
> FdoStringP temp = libraryLocation.c_str();
> providerLibrary = dlopen(temp, RTLD_NOW);
> if (providerLibrary == NULL)
> {
> char *errmsg = dlerror();
> FILE *fp = fopen("/tmp/fdo.log", "a");
> fprintf(fp, "temp=%s\tdlerror=%s\n", temp, errmsg);
> fflush(fp);
> fclose(fp);
> throw
> FdoClientServiceException::Create(FdoClientServiceException::NLSGetMessage
> (FDO_NLSID(CLNT_8_UNABLE_TO_LOAD_LIBRARY), errmsg));
> }
>
> but fprinf doesn't seem to work, I tried to log in /tmp/fdo.log and fdo.log
> in case Mapguide was put in a chroot jail or something, but it didn't
> work anyway.
> It's so irritating when simple things don't work. Why doesn't fprintf work?
> It works fine in a test program which I tried in case I'd forgotten
> how to open a file to write in C.
> Syslog doesn't work either...
> I initially thought that wchar_t was the problem, so I tried to log
> just errmsg without the path in temp, it didn't work either...
> When a program works as a daemon STDIN/STDOU/STDERR are closed or
> redirected, but writing to normal files should be OK.
> Could someone tell me how to make fprintf do what it's supposed to?
> Alternatively, what are the logging/debugging functions in FDO?
>
> Regards, Greg
>
>
> On Wed, Dec 9, 2009 at 9:39 AM, Greg1975 <aquarius1975 at gmail.com> wrote:
>>
>>
>> Yes, they do exist in the same directory as the Postgis provider. There's no
>> reference in libPostGISProvider.so to libExpressionEngine-3.4.0.so, so I
>> guess libtool failed but at the moment
>> I know next to nothing about libtool to fix it myself, if someone
>> knowledgeable took a look at the build scripts the problem probably would be
>> solved straight away by a simple tweak.
>> I'm looking forward to your reply. Thanks.
>>
>> Greg
>>
>>
>>
>> Greg Boone wrote:
>>>
>>> Did you actually rebuild the FDO Expression Engine on Linux? Does the
>>> following exist?
>>>
>>> libExpressionEngine-3.4.0.so
>>> libExpressionEngine.la
>>>
>>> Greg
>>>
>>> -----Original Message-----
>>> From: fdo-users-bounces at lists.osgeo.org
>>> [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Greg
>>> Sent: Tuesday, December 08, 2009 4:16 AM
>>> To: fdo-users at lists.osgeo.org
>>> Subject: [fdo-users] PostGIS provider undefined symbols
>>>
>>> Hello
>>>
>>> I've just built Mapguide 2.1 along with FDO 3.4 on a Linux box which
>>> was a bit tricky - to say the least.
>>> Now I have a problem with the PostGIS provider, I came across a
>>> similar case in another thread, but it was left unresolved and it's an
>>> old thread,
>>> I hope someone will be able to help now, I get some undefined symbols
>>> for the provider.
>>> I checked on the other FDO libraries with nm and it turned out that
>>> the functions _ZN*CreateEv are actually defined in the library called
>>> libExpressionEngine.so.
>>> So why aren't they resolved correctly? Isn't the function "crypt" the
>>> standard Unix function?
>>> I could dig into the source code and come up with an answer but it
>>> would probably take me a few weeks as I'm rusty on Linux programming,
>>> and I'm in a bit of a hurry.
>>> Could someone please help me out on this problem? Thanks in advance.
>>>
>>> Regards, Greg
>>>
>>> --
>>>
>>> ldd -r libPostGISProvider.so
>>>
>>> linux-gate.so.1 => (0xffffe000)
>>> libPostGISOverrides-3.4.0.so =>
>>> /srv/software/fdo/lib/libPostGISOverrides-3.4.0.so (0xb7f39000)
>>> libFDO-3.4.0.so => /srv/software/fdo/lib/libFDO-3.4.0.so (0xb7c00000)
>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7b0b000)
>>> libm.so.6 => /lib/libm.so.6 (0xb7ae5000)
>>> libc.so.6 => /lib/libc.so.6 (0xb7998000)
>>> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb798d000)
>>> libxalan-c.so => /srv/software/fdo/lib/libxalan-c.so (0xb7689000)
>>> libxalanMsg.so.17 => /srv/software/fdo/lib/libxalanMsg.so.17 (0xb7681000)
>>> libxerces-c.so.25 => /srv/software/fdo/lib/libxerces-c.so.25 (0xb72eb000)
>>> libpthread.so.0 => /lib/libpthread.so.0 (0xb72d3000)
>>> libdl.so.2 => /lib/libdl.so.2 (0xb72cf000)
>>> /lib/ld-linux.so.2 (0xb80c5000)
>>> undefined symbol: _ZN12FdoFunctionZ6CreateEv (./libPostGISProvider.so)
>>> undefined symbol: _ZN12FdoFunctionX6CreateEv (./libPostGISProvider.so)
>>> undefined symbol: _ZN12FdoFunctionY6CreateEv (./libPostGISProvider.so)
>>> undefined symbol: _ZN12FdoFunctionM6CreateEv (./libPostGISProvider.so)
>>> undefined symbol: crypt (./libPostGISProvider.so)
>>> undefined symbol:
>>> _ZN19FdoExpressionEngine20GetStandardFunctionsEv (./libPostGISProvider.so)
>>> _______________________________________________
>>> fdo-users mailing list
>>> fdo-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>>> _______________________________________________
>>> fdo-users mailing list
>>> fdo-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>>>
>>>
>>
>> --
>> View this message in context: http://n2.nabble.com/PostGIS-provider-undefined-symbols-tp4131328p4138127.html
>> Sent from the FDO Users mailing list archive at Nabble.com.
>> _______________________________________________
>> fdo-users mailing list
>> fdo-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>>
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
More information about the fdo-users
mailing list