Hi Norm,
My loadable has several parts so I start by compiliing each with gcc 3.3.2
and no -e. This produces a bunch of object files, extension .o. Using nm
on these, I find the symbol "DXEntry" without the underscore in the
appropriate file.
Then, all the pieces are combined into a shared object, extension .so,
using gcc with the options "-shared -e DXEntry". I think gcc is actually
just calling the loader ld. Again, nm finds the symbol 'DXEntry" without
the underscore in the output file.
The man page for ld says that -e declares the place at which execution
should begin. It also says that -shared is supported only on ELF, XCOFF and
SunOS.
Hope this helps.
Kent
--On Thursday, June 03, 2004 02:49:21 PM -0400 "Norman W. Schaeffler"
<[EMAIL PROTECTED]> wrote:
I think the underscore in the symbol table is the problem. After looking
at the dev-archives again, it seem that specifying an entry point is not
even required in the current version, dx will always look for a DXEntry
function in any module that it loads.
The dev-archives pointed me to the file in the source that actually loads
the module, loader.c. I took a look at that and, for my case, it seems
like the module is opened, but the symbol DXEntry (without the
underscore) is not found. So dx outputs the error message.
I am using gcc 3.1. and there does not seem to be a way to get the
compiler not add the leading underscore on function names in the symbol
table. -fno-leading-underscore as a cc option does not appear to work.
Based on the output of nm, all of the symbol names in dxexec have leading
underscores too. So it seems that removing the underscores from the new
module may not be the way to go. Unless I could remove it just from the
DXEntry symbol.
Thanks,
Norm
