it did] Hi! I am using Lahey's fortran 95 to produce some of my code. It got to the point where the useability of f95 is no longer required (i.e., I want to do a GUI with GTK+). So I decided to interface the f9x stuff to C. This is simple, as I have a few "wrapper" functions in f9x that do most of the work for me. However, these functions are inside "modules" (in the f9x parlance). That should not be a problem, as I can compile a module into an object file. Therefore, I should be able to link my C program to that object file and use whatever functions are defined therein. That's in theory. In practice, things are otherwise. According to my compiler's manual (Lahey F95 Express Linux), the functions are exported with the traditional underscore PLUS the module name in this fashion: module@function_() If I define the function in the C program as extern void module [at] function_(int *); /*as an example*/ the program won't compile, with assembler messages: Error: bad reloc specifier in expression Error: ignoring junk 'function_' after expression This leads me to think that the compiler thinks the " [at] " is an assembler token. It looks as if the pre-processor doesn't get fooled, and has a call module [at] myfunction_ in it. I have also looked into the object files with nm. I have noticed that the functions appear with a module.function_ name. However, gcc cannot have the function definition with the ".", as it probably gets confused with struct fields. Of course, gcc might have ways around this, but I haven't found them, so to sum up: (i) if I use the [at] (as seen in the manual), what do I have to do so that gcc understands it as part of the name and not as something arcane? (ii) same as (i), but instead of " [at] " read "." (iii) can I be sure of what the source code has? How can I print the available functions in an object file (only the names, I know the types. But knowing the types would be a plus) so they can then be used by another program linked to it? Thank you, and please excuse my cluelessness when it comes to compilers and the such. Regards, José -- José L Gómez Dans PhD student Radar & Communications Group Department of Electronic Engineering University of Sheffield UK --------------------------------------------------------------------- Sheffield Linux User's Group - http://www.sheflug.co.uk To unsubscribe from this list send mail to - <sheflug-request [at] vuw.ac.nz> - with the word "unsubscribe" in the body of the message. GNU the choice of a complete generation.