[Gambas-devel] [FWD]Re: Possible cygwin port

[Brandon Bergren]

Quoting Brandon Bergren <bdragon at ...185...>:

> Looked into the problem some more.

OK, this is why it is crashing:

Program received signal SIGSEGV, Segmentation fault.
0x610d3941 in strlen () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x610d3941 in strlen () from /usr/bin/cygwin1.dll
#1  0x610d740f in wmemset () from /usr/bin/cygwin1.dll
#2  0x610d6e88 in wmemset () from /usr/bin/cygwin1.dll
#3  0x6108db9f in cygwin1!aclcheck () from /usr/bin/cygwin1.dll
#4  0x0040220b in analyze_class (desc=0x406040) at gbi.c:407
#5  0x00402317 in analyze (
    path=0x4094b0 "/opt/gambas/lib/gambas/lib.gb.net.la") at gbi.c:472
#6  0x004024ca in main (argc=2, argv=0xa053768) at gbi.c:610
(gdb) up
#1  0x610d740f in wmemset () from /usr/bin/cygwin1.dll
(gdb) up
#2  0x610d6e88 in wmemset () from /usr/bin/cygwin1.dll
(gdb) up
#3  0x6108db9f in cygwin1!aclcheck () from /usr/bin/cygwin1.dll
(gdb) up
#4  0x0040220b in analyze_class (desc=0x406040) at gbi.c:407
407         print("#%s\n", name);
(gdb) up
#5  0x00402317 in analyze (
    path=0x4094b0 "/opt/gambas/lib/gambas/lib.gb.net.la") at gbi.c:472
472           analyze_class(*desc);
(gdb) print desc
$10 = (GB_DESC **) 0x686000
(gdb) print *desc
$11 = (GB_DESC *) 0x406040
(gdb) print *desc
$12 = (GB_DESC *) 0x406040
(gdb) print **desc
$13 = {name = 0x8ec8300 <Address 0x8ec8300 out of bounds>, val1 = -349954935,
  val2 = -1869573932, val3 = -1869574000, val4 = -1312545281,
  val5 = -1869610944}

Reminded me of something I saw in the Autotools book:
(http://euler.aero.iitb.ac.in/docs/Programming/autobook/autobook_251.html)
---------------------------------
Windows' DLLs, are very different to their nearest equivalent on Unix: shared
libraries. This makes Libtool's job of hiding both behind the same abstraction
extremely difficult -- it is not fully implemented at the time of writing. As a
package author that wants to use DLLs on Windows with Libtool, you must
construct your packages very carefully to enable them to build and link with
DLLs in the same way that they build and link with shared libraries on Unix.

Some of the difficulties that must be addressed follow:

    * At link time, a DLL effectively consists of two parts; the DLL itself
which contains the shared object code, and an import library which consists of
the stub(65) functions which are actually linked into the executable, at a rate
of one stub per entry point. Unix has a run time loader which links shared
libraries into the main program as it is executed, so the shared library is but
a single file.

    * Pointer comparisons do not always work as expected when the pointers cross
a DLL boundary, since you can be comparing the addresses of the stubs in the
import library rather than the addresses of the actual objects in the DLL. GCC
provides the __declspec extension to alleviate this problem a little.

    * The search algorithm for the runtime library loader is very different to
the algorithms typically used on Unix; I'll explain how to dela with this in
25.4.5 Runtime Loading of DLLs.

    * All of the symbols required by a DLL at runtime, must be resolved at link
time. With some creative use of import libraries, it is usually possible to
work around this shortcoming, but it is easy to forget this limitation if you
are developing on a modern system which has lazy symbol resolution. Be sure to
keep it at the back of your mind if you intend to have your package portable to
Windows.

    * Worst of all, is that it is impossible to reference a non-pointer item
imported from a DLL. In practice, when you think you have exported a data item
from a DLL, you are actually exporting it's address (in fact the address of the
address if you take the import library into consideration), and it is necessary
to add an extra level of indirection to any non-pointers imported from a DLL to
take this into account. The GNU gcc __declspec extension can handle this
automatically too, at the expense of obfuscating your code a little. 
-----------------------

Namely, the last one.

(I could be wrong, I'm still learning most of this stuff.)

--Brandon