>Boy, that sure looks like a library format problem. What does
> nm libforms.a
>say? How about
$ nm libforms.a | grep intialize
00001554 T fl_initialize
(it also finds a U and T of fl_initialize_program_visual, but that's
irrelevant...)
My knowledge of library internals is a bit fuzzy, is the "T" (and the fact
it's there at all) a good sign? ;-)
And as for the file command:
$ file libforms.a
libforms.a current ar archive
Someone also suggested adding an explicit extern "C" prototype to the top
of my dummy test file, which I did:
extern "C"
{
Display *fl_initialize(int *, char *[], const char *, FL_CMD_OPT *, int);
}
...it did not balk at this, but the link error to fl_initialize remained...
I apologize for waxing tedious on the issues of linking and OS libs, but
this is approaching the bizarre now that I cannot even compile without
relinking or changing the order of things. I swear I have not altered nor
defamed the glibc's nor libforms.*'s on my system in any way. Let me know
what else you guys come up with, and thanks for the responses so far.
+--------------------------------------------------------------+
| Todd C. Zino todd@lacemaker.com |
+--------------------------------------------------------------+
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/