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

[Brandon Bergren]

Looked into the problem some more.


Quoting Brandon Bergren <bdragon at ...185...>:
> > > You must use -no-undefined when using libtool in link mode.  Here's the
> > > autoconf macro for telling autotools that the libraries are cygwin
> ready:
> > >
> > 
> > OK, I added this flag in "LDFLAGS".
> 
> Err, using -no-undefined is only needed on Cygwin shared libs.  Other
> platforms
> support "lazy loading", but Cygwin doesn't, as the implementation is
> currently
> a hack using Win32 DLLs (which require all imports and exports to be
> explicitly
> stated -- The win32 runtime linker is way different than the GNU one.)
> 
> Actually, using this flag would probabaly break builds.  Having a configure
> option to enable this would be nice.
> 
> 
> 
> > 
> > > ------------------------------
> > > AC_LIBTOOL_WIN32_DLL
> > >     This macro should be used if the package has been ported to build
> > clean
> > > dlls on win32 platforms. Usually this means that any library data items
> > are
> > > exported with __declspec(dllexport) and imported with
> > > __declspec(dllimport). If this macro is not used, libtool will assume
> that
> > > the package libraries are not dll clean and will build only static
> > > libraries on win32 hosts.
> > >
> > >     This macro must be called before AC_PROG_LIBTOOL, and provision must
> > be
> > > made to pass `-no-undefined' to libtool in link mode from the package
> > > Makefile. Naturally, if you pass `-no-undefined', you must ensure that
> all
> > > the library symbols really are defined at link time!
> > > --------------------------------
> > >
> > 
> > OK, I added the call to this macro.
> 
> Of course, this will break compiling on Cygwin until the libraries are
> actually
> ported, but it's not like anyone is really USING gambas on cygwin yet, eh?

I was able to coax gb.net to compile and link a DLL.  GBI segfaults trying to
generate info, though. I guess libtool defaults to exporting all symbols,
unless you tell it not to.

I think the segfault might have to do something with pointers crossing dll
boundaries.  I'm going to look into that later.

> > Can you be more explicit please ? What should I change ?
> > 
> 
> It's more a concept, really.
> 
> Is there already a record of what a library exports, symbol wise?
> 
> Those symbols need to be declared with __declspec(dllexport) when the library
> is
> being compiled, and __declspec(dllimport) when the library is being used. 
> (Think of it as a really weird extern)
> 
> So, imagine this:
> 
> foo.h:
> ...
> #ifdef _CYGWIN_
> #ifdef FOO_C
> #define magic __declspec(dllexport)
> #else
> #define magic __declspec(dllimport)
> #endif
> #else
> #define magic
> #endif
> 
> magic void thesymbol(void)
> 
> foo.c:
> #define FOO_C
> #include "foo.h"
> 
> void thesymbol()
> {
>   /* stuff */
> }
> 
> bar.c:
> #include "foo.h"
> 
> ...
> 
> /* call thesymbol() */
> thesymbol();
> 
> This example is oversimplified, but I hope you get the general idea.
> 
> It's easiest to do if you already know exactly what a library provides, and
> what
> it uses.  You need to "forward import" all symbols a win32 shared library
> calls
> directly. It's too stupid to think ahead.

Ignore the stuff on importing, linking with the import library is enough.

All this was off the top of my head.


> 
> Static libraries on Windows work similar to Unix.
> 
> Of course, static libraries are useless when you're trying to run gbi.
> 
> I think I'll see if I can get the SDL component ported to this paradigm.  If
> that works OK, I'll write up some general guidelines of how this stuff
> works.
> 
> The main thing to do is make sure that library headers get passed a symbol
> that
> they can use to tell if they're being used to compile the library, or using
> the
> library. Having a libwhatever.c file for each library containing
> #define LIBWHATEVER_COMPILE
> #include "all_the_header_files_for_this_library"
> 
> would cause the dll import/export map to be dumped into libwhatever.o.
> 
> The big thing is keeping track of exactly what a library exports. (and
> imports,
> but with -no-undefined, you'll catch that sooner, because it won't link.)
> 
> 
> Actually, some newer ELF stuff is using a similar method, so having this
> system
> in place would make it trivial to get Gambas working nicely on the new ELF
> symbol versioning/hiding stuff. (Which is a pretty slick system -- smaller
> libraries, less conflicts, better defined interfaces.)
> 
> > >
> > > The QT frontend compiled fine for the kde-cygwin QT port, so no work to
> be
> > > done there, at least. :)
> > 
> > Good news :-) There are X11 calls in the QT component, how are they solved
> ?
> > 
> 
> X11 runs on Cygwin too. ;)
> 
> Yes, I am running X11 QT/Free on Windows. That's why it works.
> 
> I'm also contemplating writing a FOX toolkit frontend. I've got to have a
> working Cygwin port first, though.
> 
> > >
> > > Any concerns?
> > >
> > > --Brandon Bergren
> > 
> > Thanks for your patch, and talk about your work on the devel mailing-list.
> 
> > Other people might be interested.
> 
> No problem. Roll back the -no-undefined part though, I have a feeling it
> will
> break stuff on Unix.

Now that I think about it, having -no-undefined might actually help stuff NOT be
broken -- it requires all symbols to be found at compile time -- if there are
missing symbols, you would get a runtime crash instead.