Dave Beckett

Hosted by

since 2005.


(See DOAP Project)

Redland librdf RDF API Library - Porting Hints

0. Introduction

This document contains porting hints for porting Redland, especially, to make it run on Win32. It already works under cygwin, so don't use these tips for build that. This is my recording of what I've heard from others who have successfully built the redland libraries under Win32. I've not tried it myself since I don't develop for MS Windows.
-- Dave

1. Starting - Requirements

First get the sources. Either find the latest listed on the main Redland site, or the browse the source distribution area.

You will also need an XML parser and I recommend the newest libxml2 you can find (2.6.x) or expat if you want something small.

The best place to start porting is with Raptor, since it's a required library needed by Redland and Rasqal.

2. Porting Raptor

For a windows build, the sources already include support so you need to compile with a define -DWIN32 so that the win32_raptor_config.h file gets included in C sources. You will also need to set -DRAPTOR_INTERNAL so that certain internal defines and headers are used. Then you just need to link all the C sources objects together to get the raptor.dll library. If it was a command line compile, it'd be something like:

  cc -DWIN32 -DRAPTOR_INTERNAL -I. *.c -o raptor.dll -lexpat

(This is a unix style compile illustrating the form; I don't know the exact invocation for such a command line under Win32).

Raptor needs as a minimum requirement, an XML parser - either expat or libxml2 (prefered) - see the raptor install document for full details. You might have to change the configuration depending on which one you want, the header file above is currently configured for expat. For raptor, There is some ancient and probably out of date win32/VC/VS project files in the win32 directory of the sources.

If you are feeling adventurous, you could add libcurl to the build so that it can retrieve WWW content, or use libxml2 and enable its mini-http and ftp functions. See for the defines needed - just add them to win32_raptor_config (with documentation!) or -DTHING to the compile command.

3. Porting Redland and Rasqal

Redland and Rasqal have similar configurations - a header win32_rdf_config.h (win32_rasqal_config.h) and a define -DWIN32 but I've not got all the win32 bits in a released version or with much confidence it all works.

You should use Redland 0.9.18 (or newer) since it has some win32 fixes. Redland 0.9.18 requires the Rasqal library for rdf querying from so, you'll have to build that before Redland.

Similarly, Rasqal has define and header files like the above and you should take the use 0.9.2 Rasqal or newer which has some initial win32 headers it needs based on the pattern above. This one has never been built for win32 so there are surely some gotchas, but it's pretty vanilla C, just depending on raptor. In pseudo:

  cc -DWIN32 -DRASQAL_INTERNAL -I. -I/path/to/raptor *.c -o raptor.dll

and at that point you can try to build redland:

  cd librdf
  cc -DWIN32 -DLIBRDF_INTERNAL -I. -I/path/to/raptor -I/path/to/rasqal *.c 
    -o raptor.dll -lraptor -lrasqal

4. MS VC++ Issues

To prevent problems with passing file handles over runtime boundaries and memory issues, Suzan Foster suggests:

When compiling with VC++ check that you're building all libraries with /MD for release and /MDd for debug, /MT and /MTd for the executable.

-- Susan Foster, mail to redland-dev 2004-10-14

And explains further:

Basicallly there are multiple runtimes which a Win32 application can link to in single-threaded and multi-threaded flavours. Passing pointers between different runtimes, which happens if dynamic libraries and applications are linked against different runtimes, causes memory access violations because one runtime is accessing memory which belongs to a different runtime. Using the right compiler switches forces all components to use the same runtime. /ML will force the single-threaded runtime, whilst /MT will force the double-threaded runtime. Appending a lower case d will force the single-threaded debug runtime and the multi-threaded runtime respectively. Using /LD will create a dynamic library (dll) and default to /MT if not overridden by /ML. Using /MD will create a dynamic library and force /MT.

My own set of dynamic libraries (raptor.dll, rasqal.dll and librdf.dll) were all compiled with the option /MDd and can safely pass memory amongst each other. N.B. libxml2.dll also needs to be linked to the same runtime, especially when using the rss-tag-soup parser.

A more extensive description of the compiler options can be found at:

-- Susan Foster, mail to redland-dev 2004-10-15

5. Porting Language Bindings - PHP

PHP here is used as an example

5.1. PHP Binding

Finally to the PHP API. I've just separated that out from the C source code, so it's in a new package, Redland Bindings. Go there and grab whatever's the latest release as a tarball. Then make the PHP API. That's compiling the one C file there, linking with the right PHP libraries and the redland ones. This is very much where I run out of ideas. Here's an edited version of roughly what is done using the configure-built makefiles:

    -I../librdf -I/usr/include/php -I/usr/include/php/main
    -I/usr/include/php/Zend -I/usr/include/php/TSRM -g -fPIC -DPIC
    redland_wrap.c -c -o
  gcc -g -L/usr/lib -lrdf -lrasqal -lraptor ... -shared -o

The -DREDLAND_POST_I etc. defines are required.

6. Feedback

Please get in contact with me with fixes to this document, thanks
-- Dave

Last Modified: $Date: 2004/10/15 13:08:07 $