This problem has been worked out on Icarus Verilog. For example,
the code generators are dynamic loaded and obviously the DLLs that
the core loads uses symbols in the main program.
The way that works is you make a pseudo-library using a .def file
and dlltool. For example, there is an ivl.def file that lists all
the symbols that the program exports to its loaded objects. You
do a preliminary link with gcc, then use dlltool to make a libivl.a
and ivl.exp, then you relink the main program with the ivl.exp to
make the exports used by the libivl.a.
DLLs that are loaded dynamically into the ivl program use libivl.a
to resolve (at DLL link time) the symbols that are in the ivl core.
Then at run time, when the DLL (that uses libivl.a) is loaded, it
actually performs the link of the symbols that were previously resolved.
It's weird. It's wacky. It's Windows.
The Icarus Verilog Makefiles are a little opaque, but they do work
for mingw32. There are clear mingw32 build instructions on the
iverilog.wikia.com WIKI site as well as the mingw.txt file included
with the source. Following those instructions will get you configured
makefiles that are a little easier to read then the Makefile.in files
that they come from.
al davis wrote:
> I still can't figure out how to make it work.
>
> Consider the file "foo.cc"
> =========
> extern int bar();
> int foo(int q)
> {
> return q*bar();
> }
> =========
>
>
> On Linux, to make a native .so I can do:
> g++ -fPIC --shared foo.cc
> and it builds an appropriate file, such that "bar" will be resolved later.
>
>
> The problem is if I do:
> i586-mingw32msvc-g++ --shared foo.cc
> It responds with:
> ========
> /tmp/cch3JG6k.o:foo.cc:(.text+0x7): undefined reference to `bar()'
> collect2: ld returned 1 exit status
> ========
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
