Ah, that would explain it. I don't think either Francis or I are currently using the new preprocessing code at all. Currently we mainly use cheap for XML RMRS ^_^ One day I would like to put together a nice test set for cheap so that we can catch this kind of stuff earlier. Eric <div>On 11/6/06, Ben Waldron <<a href="mailto:bmw20@cl.cam.ac.uk">bmw20@cl.cam.ac.uk</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Eric Nichols wrote: > Are PPCRE functions currently being used in PET? If not, that would > explain why > this problem wasn't noticed earlier. Even if the change does cause the > linker to > favor rmrs over PPCRE, this still doesn't sound like a permanent > solution. I think > I will continue to persue a solution on the ECL/PET side of things. I don't know why the problem wasn't noticed (or perhaps didn't occur?) earlier. PPCRE is used heavily in the preprocessor (activated via "-tok=fsr"). I don't use PET regularly, but when I last tested it with RMRS output (in the process of integrating the FSR preprocessor) I didn't observe the current problem. Most people will be using an official PET release, which will be older than the contents of the current SVN... Note also that something is broken in the current ERG with respect to cfrom/cto on EPs (the values get lost, at least when running under the LKB). I have no idea if this is relevant... - Ben </blockquote> </div> -- --Eric Nichols