Building XFCE on Cygwin

Brian J. Tarricone bjt23 at
Tue Jul 13 23:35:38 CEST 2004

interesting... i compiled this as-is on linux, and it works fine.  seems 
like gcc doesn't mind the .def file being there on the commandline.


p.s.  next time, please don't have your tarball unpack into the current 
directory =/

Maarten Boekhold wrote:

> Hi all,
> I've been mucking around trying to come up with an easy way to get the 
> various plugins of XFCE to compile/link properly under Cygwin, but 
> haven't found the best solution yet.
> 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.
> The most promising approach is described in the below mail, which I 
> sent to the cygwin list, but have not received any reply to yet. I 
> figured I'd forward it here, on the off-chance that it rings a bell 
> for somebody.
> -------- Original Message --------
> Subject: Re: Building DLL
> Date: Mon, 12 Jul 2004 19:52:49 +0400
> From: Maarten Boekhold <boekhold at>
> To: cygwin at
> References: <18b27f187b2a.187b2a18b27f at>
> Hi all,
> Sorry to keep going on about this, I really want to get this working.
> I've made *some* progress in how to build "plugin libraries". I have
> attached my test case to this mail in case somebody is willing to have a
> look at it. Let me describe it first.
> 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 (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.
> 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 -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
> So instead I editted the generated 'libtool' (after running
> 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"
> Note the "plugin.def" at the end. Now 'make' succeeds. If anybody knows
> how I can pass the "plugin.def" to the GCC command line, I'd be very
> interested to know.
> Run 'make install', and then:
>     /usr/local/bin/plugintest /usr/local/lib/
> This now gives:
> $ /usr/local/bin/plugintest.exe /usr/local/lib/
> ** 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 file).
> Kind regards,
> Maarten
>Unsubscribe info:
>Problem reports:
>Xfce4-dev mailing list
>Xfce4-dev at

More information about the Xfce4-dev mailing list