[redland-dev] Problems with Tcl interface...

[Dave Beckett]

On Thu, 25 Mar 2004 19:55:34 +0200, "Georgios Petasis" <petasis at iit.demokritos.gr> wrote:

> Well, I also posted a relevant question on comp.lang.tcl, but no
> one seems to have used it :-) But if things go well, perhaps more
> people will use the Tcl API:-) I am evaluating redland for possible
> inclusion into the Ellogon language engineering platform
> (http://www.ellogon.org). I really liked the fact that a lot of
> languages are supported through swig, exactly as Ellogon does :-)

Yes, that turned out as consequence rather than something I
deliberately aimed Redland to do.

> We plan to integrate ontology management support into Ellogon and
> we are evaluating available tools to see if they can cover our
> needs, before we start re-inventing the wheel.  So far, the only
> negative point is the lack of support for windows :-) (but I have
> red your opinion about this, so I am not asking for it :-))

I don't run windows or have any software development environment for
it.  If someone wishes to pay me to do so, that's when I would be
able to buy the necessary new hardware and software and justify
spending the time to learn that environment.  It would be easier if
somebody already with the MS experience and tools did this, since
I would be hard pressed to support this.

Raptor is already used in several windows applications so I don't
think Redland would be *that* hard to build (and I don't mean under
cygwin - it works fine under that right now).

<snip/>

> No, the stubs mechanism exists since 8.1, back in 1997 I think. To
> my knowledge, Tcl is the only language that has this very
> convinient interface. Once you link with stubs enabled, you can run
> on any system, with any Tcl >= 8.1...
> Since I know Tcl fairly well, I can provide a patch that adds stubs
> support :-) Its really easy...

Patches would be great.

> > At compile time it finds it because of
> >  > -L/disk2b/local/sources/Development/XML/redland-0.9.16/librdf/.libs
> >  > -lrdf
> >
> > but if you then try to run the program, or use ldd without setting
> > the run-time library path, you'll get failure.
> >
> >
> > >         libcrypto.so.4 => /lib/libcrypto.so.4 (0x0099e000)
> > >         libdb-4.1.so => /usr/lib/tls/libdb-4.1.so (0x00111000)
> > >         libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10
> > > (0x002ce000)
> > >         libz.so.1 => /usr/lib/libz.so.1 (0x00712000)
> > >         libcrypt.so.1 => /lib/libcrypt.so.1 (0x0041f000)
> > >         libnsl.so.1 => /lib/libnsl.so.1 (0x00fd8000)
> > >         libm.so.6 => /lib/tls/libm.so.6 (0x00384000)
> > >         libraptor.so.1 => not found
> > >         libcurl.so.2 => /usr/lib/libcurl.so.2 (0x001d2000)
> > >         libssl.so.4 => /lib/libssl.so.4 (0x001fb000)
> > >         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00230000)
> > >         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00243000)
> > >         libcom_err.so.2 => /lib/libcom_err.so.2 (0x00e11000)
> > >         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00338000)
> > >         libresolv.so.2 => /lib/libresolv.so.2 (0x00530000)
> > >         libdl.so.2 => /lib/libdl.so.2 (0x002aa000)
> > >         libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00542000)
> > >         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00b3f000)
> > >         libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x003a6000)
> > >         libc.so.6 => /lib/tls/libc.so.6 (0x00723000)
> > >         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0035d000)
> > > undefined symbol: librdf_version_string (./Redland.so)
> > > undefined symbol: librdf_version_minor  (./Redland.so)
> > > undefined symbol: librdf_version_decimal        (./Redland.so)
> > > undefined symbol: librdf_version_release        (./Redland.so)
> > > undefined symbol: librdf_copyright_string       (./Redland.so)
> > > undefined symbol: librdf_version_major  (./Redland.so)
> > > undefined symbol: librdf_short_copyright_string (./Redland.so)
> >
> > Those are the few external statics refered to in Redland.so, so
> > failure to find librdf.so would give that.
>
> I really don't know what is going on :-) This output is from "ldd
> -d Redland.so". I am looking inside the redland shared library. If
> these symbols are undefined inside the library, they will not be
> satisfied even if the library is found.  I don't remember if
> librdf.so was also built, but it is not mentioned at all in the ldd
> output...  I have tried everything, like puting the directory
> librdf.so lives in LD_LIBRARY_PATH or event putting symbolic links
> in common places, like /usr/lib. I was never able to load the tcl
> bindings, as all symbols (variables & functions) were undefined. I
> even preloaded the redland library into the Tcl interpreter, but
> again with no results. What is even more strange, is that I linked
> the Tcl bindings with the static redland library, and again *all*
> the redland library symbols (and raptors I suppose) were undefined.

The symbols are in the library as public statics, I'm puzzled why it
isn't linking them correctly.

> To my understanding, there is something wrong in the way the
> library is linked. I usually use the -fPIC gcc flag, even during
> linking (which is missing from the way redland is build). It is
> possible that this is the cause for all these. I will test it and
> report if it solves the problem :-) I finally managed to get the
> bindings to load in Tcl, but I link to the object files directly
> (by placing all the *.o files instead of the libraries).

I think -fPIC isn't right for static C libraries, only shared ones
(unix, linux).  I wouldn't go around adding -fPIC to normal compiles
without thinking about it carefully.  I try to let libtool worry
about all that stuff since it can be very different between systems.

<snip/>

> The problem is that the symbols are not in the library, as I explained
> for the output of ldd above. It would be interesting to check if the same
> problem occurs also for other bindings. Is there a application that I can
> call from the terminal to see if it is working? (or a script in python/perl
> that loads redland?)

There's a utility program called rdfproc in the utils directory.  If
you do 'make' at the top level, it should get built and can be used
to test the library.  Or try the python unit tests - 'cd python; make check'

Dave