Building XFCE on Cygwin

[Brian J. Tarricone]

On Tue, 13 Jul 2004, Maarten Boekhold wrote:

> I do have a way, but it involves adding various 
> '__atribute__((__dllexport__))' and '__attribute__((__dllimport__))' 
> statements at various places in the source code, and I'd like to try to 
> avoid that.

don't the macros G_MODULE_EXPORT and G_MODULE_IMPORT essentially expand 
to that on win32?  they can be safely added to the code without any 
ill effects for unix builds.

> I did some reading on the libtool documentation, and according to that,
> libtool 1.5.6 has specific support for dlopen'ed libraries (which is
> what glib/gmodule uses under the hood if I'm not mistaken). The trick is
> an extra macro to your configure.ac (AC_LIBTOOL_DLOPEN) and two
> additional flags to libtool: -module and -export-dynamic. Now, I'm not
> sure if that support is supposed to work on cygwin. But together with a
> "plugin.def" file that defines to the library that a symbol is exported
> by the executable, I can now get things to compile.

-module and -export-dynamic are well known to me (and are onthing new 
for 1.5.6).  i've never heard of AC_LIBTOOL_DLOPEN - what does it do, 
specifically?

> Caveat: I cannot get the 'plugin.def' file passed to the gcc command
> line when linking:
> 
> /bin/bash ./libtool --mode=link gcc  -g -O2   -o libplugin.la -rpath
> /usr/local/lib -no-undefined -module plugin.def libplugin_la-plugin.lo
> -lgobject-2.0 -lglib-2.0 -lintl -liconv
> gcc -shared  .libs/libplugin_la-plugin.o  -L/usr/lib
> /usr/lib/libgobject-2.0.dll.a /usr/lib/libglib-2.0.dll.a
> /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a  -o .libs/cygplugin-0.dll
> -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libplugin.dll.a

couldn't you do this in the "whatever_LDFLAGS" line in Makefile.am?  
another option (not as nice) would be to override the linker command 
itself in Makefile.am to include the .def file (see the automake manual; 
i was just reading about this last night actually - i think it's the 
"whatever_LINK" variable).

> So instead I editted the generated 'libtool' (after running autogen.sh)
> and added it manually:
> 
> # Commands used to build and install a shared archive.
> archive_cmds="\$CC -shared \$libobjs \$deplibs \$compiler_flags -o
> \$output_objdir/\$soname \${wl}--image-base=0x10000000
> \${wl}--out-implib,\$lib plugin.def"

yeah, this definitely isn't a viable solution ^_~.

> Run 'make install', and then:
> 	/usr/local/bin/plugintest /usr/local/lib/libplugin.la
> 
> This now gives:
> 
> $ /usr/local/bin/plugintest.exe /usr/local/lib/libplugin.la
> 
> ** ERROR **:  1627507512s not a valid Win32 application.
> aborting...
> Aborted (core dumped)
> 
> Is this expected, and is there a way to fix this? Has anybody seen this
> before? (note: for people not familiar with gmodule, the g_module_open()
> function explicitly tests whether this is a libtool library, and if so
> retrieves the actual DLL name from the libplugin.la file).

looking at the .la file (it's just text), does it actually point to the 
proper .dll file?  it should be the "dlname=" line.  if you want me to 
look at it further, i'd have to see the source of your 'plugintest.exe' 
binary.  the test plugin itself and a makefile would be nice too ^_~.

	-brian