strauman at slac.stanford.edu
Mon Oct 8 21:30:41 UTC 2007
Nickolay Kolchin wrote:
> What is current Cexp status? Version 1.5 looks broken at present time.
Yeah, it's a little outdated. I should post a new release -- it's a
finding the time. I'll send you a current snapshot in private mail and would
appreciate your comments.
> 1. Cexp don't compile out-of-box.
> - on 64-bit machine libtecla configure.in <http://configure.in> need
I think that is resolved. The demo builds fine on my x86_64 RHEL4 machine.
> - on all system regexp/regexp.c have a bogus "malloc" definition.
Should be fixed. For a while 'regexp.c' has been including <stdlib.h> to
get the declaration of malloc().
> 2. cexp is a predefined function now.
Yep. Mea culpa - bad idea to create a name clash with a standardized
The respective routine has been renamed 'cexpsh' a while ago.
> ../cexp.h:312: warning: conflicting types for built-in function 'cexp'
> This is not a bug, it just shows how old Cexp public version is.
> 3. Test example don't work
> Unresolved symbol: printf
> 0x00000000 (0)
This is a problem with the symbol table of the demo program.
Since it is (most likely) dynamically linked 'printf' is actually
undefined in the system symbol table.
You either have to find a way to generate a complete symbol
table file or you should try to link the C-library statically.
Unfortunately, I had problems when I tried to enforce a completely
static link (-Wl,-Bdynamic) because on my system no static
version of libgcc seems to be available. In order not to
brake the build-process I left the linker flags alone. Support
for the 'demo' program doesn't have a high priority...
> Tested on:
> - linux 2.6.22 (x86_64 and i686)
> - GCC 4.2.0 (x86_64 and i686)
> - binutils-2.18
> - GLIBC 2.6.1
> I'm not sure is Cexp completely broken, or we just need to update bfd
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users