[Gambas-devel] More cygwin

[Brandon Bergren]

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

> 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)

Ok, here's what I've found.

I can't see any realistic way to beat the  GB_DESC *GB_CLASSES[] into
submission.
The {class description} sections aren't being constructed properly.

Cygwin apparently doesn't like a pointer to an array made of extern elements in
a shared library.  I don't blame it.

I have an idea for a workaround, but it's not finished yet.  Thinking of a way
to implement it without changing the class declaration syntax.

On a positive note, the GB structure seems to work OK.  I've been running tests
in a hacked-up gbi.c in gdb, and was able to write to GB from a gbi stackframe.
:)

Also, malloc() doesn't seem to allocate memory that can cross DLL boundaries.
I got bla = (type*)GlobalAlloc(GPTR,size) to work fine. Another windows-ism.

Hopefully, after all that, it'll just be small fixes.

--Brandon