[TRE-general] [Felix-impl] Re: Weird bug

[skaller]

On Tue, 2006-05-16 at 22:23 +0300, Ville Laurikari wrote:
> On Mon, May 15, 2006 at 09:06:19PM +1000, skaller wrote:
> > Within one module yes. It's possible to link both with shared libs:
> > X links to tre and Y to gnu, A links to X and Y and passes data
> > between them without needing to link to either tre or gnu.
> 
> I tried this.  I made two dynamically linked libraries, X and Y.  X
> compiles a regex object using regcomp() and returns it.  Y runs a
> regexec() for a given compiled regex.  A gives a regex object made
> with X to Y.  X is explicitly linked with libtre.
> 
> Both the regcomp() and regexec() calls go to TRE if A is linked with
> libtre. 

>  If A is not linked with libtre, both calls go to libc.  So I
> was unable to get an inconsistent link like this.

Then

	tre_version()

will not reliably report that regcomp() being used is
the tre one?

> This seems to come down to the link order and the fact that symbols
> are bound by the dynamic loader for the entire program instead of
> separately for each loaded library.

That makes sense .. and is a SW engineering nightmare ;(

> Note that this was on Linux and glibc, think may work differently on
> other platforms...

Yes. Cygwin at least resolves all symbols at link time.
So does Win32. What gets loaded via the statically linked
thunks is another story.

For Win64, you can load two distinct versions
of the same library at the same time, using the new
'assemblies' things. In fact, there is no system C
library. You have to distribute the C library 
you linked against with every DLL or application you make.
Ditto for all other user libraries. 

Should create an interesting mess for non-reentrant
functions. Indeed this is ALSO the case for Win32
since you can link the C library statically AND
dynamically and thus get two copies of it.
[MS specifically warns against this]

BTW: yes there are linker controls. If everyone used
the Linux ELF linker, these problems could easily be
solved, since it is quite a powerful linker.

I hope the problem will be minimised though:
Felix works like this:

// Felix source code 
header tre_h = '#include "tre/regex.h"';

fun regcomp: ... = "regcomp(...)"
  requires tre_h, package tre
;

.. regcomp(...) ...

Here, using 'regcomp' drags in the right header
file automagically into the generated C code
via insertion 'tre_h'. The 'package tre' annotation
includes the line 'tre' in a file 'progname.resh'
which is inspected by the script linking the program,
which in turn looks for config/tre.fpc which contains
the line 

provides_dlib : -ltre

thus causing the program to be linked with libtre.so.

Provided all this is set up correctly the end user
just writes 'regcomp' etc and everything is fixed up
automatically. I see no reason to support GNU or system
regex since these are only going to be available on
Unix like platforms on which TRE will build easily.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net