What's supposed to happen is that 'make' runs 'setup' to create 'Makefile.config' and an empty 'hostinfo.h'. The empty 'hostinfo.h' is enough to create the dependencies. Later, 'hostinfo.h' is recreated (after building 'htype') and running the script 'hostinfo'.
I see I put in a comment THIS DOES NOT WORK in the Makefile, just above the Makefile.config target.
What happens, I think, is that modern machines are so quick that the empty 'hostinfo.h' appears to have the same timestamp as the built 'htype'. For the moment, try 'touch htype' and them 'make'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that on Debian 5 and Mac OS X -lpythonm.n calls in a shared library, which calls in other libraries at run time without further ado. (Interestingly, on the Mac it's called libpython2.6.a but is in fact a dynamic library!!!). On OpenSUSE you're getting the static library. I see that on Debian 5 /usr/lib/python2.5/config contains both static and dynamic libraries; what to you see?
Anyway, looks as though you need to specify the other libraries that Python needs: -lm -lpthread -ldl ????
Or should we remove the -L completely? /usr/lib seems to have a perfectly good libpython.so, so we could just say -lpython; no fuss, no muss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attempting to run it produces the following error.
alex@opensuse-vm:~/Projects/c2ada/trunk> ./c2ada
Fatal Python error: Interpreter not initialized (version mismatch?)
Aborted
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that rather than redefining LINKER, one should define EXTRA_LIBS.
Afraid I don't know enough about embedding Python to comment on the Fatal Python error; it seems unlikely to be a version mismatch since you're using a static library? Might it work better if you could beat it into using a dynamic library?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, if the -L is removed from PYTHONLIBS, the dynamic library libpython2.7.so in /usr/lib is used. No extra libraries need to be specified. Result is as follows ...
make log
makefile (edited)
makefile config
What's supposed to happen is that 'make' runs 'setup' to create 'Makefile.config' and an empty 'hostinfo.h'. The empty 'hostinfo.h' is enough to create the dependencies. Later, 'hostinfo.h' is recreated (after building 'htype') and running the script 'hostinfo'.
I see I put in a comment THIS DOES NOT WORK in the Makefile, just above the Makefile.config target.
What happens, I think, is that modern machines are so quick that the empty 'hostinfo.h' appears to have the same timestamp as the built 'htype'. For the moment, try 'touch htype' and them 'make'.
log of make after touch htype
Yes, thanks, that gets rid of the file-not-found errors. I'm still getting the undefined references though (second log uploaded).
Changed linker line in makefile to ...
LINKER = gcc -lm -ldl -lpthread -lutil
I'm still getting two undefined references (third log uploaded).
log of make after addition of library link directives
It seems that on Debian 5 and Mac OS X -lpythonm.n calls in a shared library, which calls in other libraries at run time without further ado. (Interestingly, on the Mac it's called libpython2.6.a but is in fact a dynamic library!!!). On OpenSUSE you're getting the static library. I see that on Debian 5 /usr/lib/python2.5/config contains both static and dynamic libraries; what to you see?
Anyway, looks as though you need to specify the other libraries that Python needs: -lm -lpthread -ldl ????
Or should we remove the -L completely? /usr/lib seems to have a perfectly good libpython.so, so we could just say -lpython; no fuss, no muss.
in_word_set() is defined in c_perf.c
cpp_keyword() is defined in cpp_perf.c
Both are generated using gperf. I have GNU gperf 3.0.3 here.
Delete the generated files and rebuild?
Thanks Simon. That did it. I now have a c2ada executable.
Attempting to run it produces the following error.
alex@opensuse-vm:~/Projects/c2ada/trunk> ./c2ada
Fatal Python error: Interpreter not initialized (version mismatch?)
Aborted
I think that rather than redefining LINKER, one should define EXTRA_LIBS.
Afraid I don't know enough about embedding Python to comment on the Fatal Python error; it seems unlikely to be a version mismatch since you're using a static library? Might it work better if you could beat it into using a dynamic library?
Yes, if the -L is removed from PYTHONLIBS, the dynamic library libpython2.7.so in /usr/lib is used. No extra libraries need to be specified. Result is as follows ...
alex@opensuse-vm:~/Projects/c2ada/trunk> ./c2ada
Illegal invocation
Usage: ./c2ada [flags] input files
flags:
-Dname[=value]
Define a macro with an optional value. By default
macros will be defined with the value 1.
-Uname
Undefine a builtin macro.
-Idir
Add a search path for finding include files.
-S
Add a search path for system include files
-builtin
Display all predefined macros.
-fun
Flag all union declarations.
-cs
Add sizeof and alignof comments for all decls.
-erc
Always gen enum rep clauses.
-exp
Export functions, variables from .c file to Ada spec.
-sih
Suppress import declarations from included headers.(default)
-rrc
Always gen record rep clauses.
-src
Suppress all record rep clauses.(default)
-ap
Automatic packaging. (default)
-C
Attempt to retain C comments in the translation.
-noref
No reference comments from Ada back to C.
-mwarn
Warnings about untranslated macros.(default)
-rational | -vads | -gnat | -icc
Rational | VADS | GNAT(default) | Irvine as target compiler.
-95
Output Ada 95 (default).
-pp
Predefined package name, default is C.
-mf
Map file cbind.map used to map unit names.
-Pfilename
project configuration file name
-Opathname
output directory (default=bindings)
I don't know what was happening with the static library.