After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 700445 - BURN THE DEF FILES!
Product: gtk+
Classification: Platform
Component: Backend: Win32
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
: 702860 711191 (view as bug list)
Depends on:
Reported: 2013-05-16 11:01 UTC by LRN
Modified: 2017-10-26 11:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Removes references to .def files from the buildsystem (6.34 KB, patch)
2013-05-16 11:02 UTC, LRN
reviewed Details | Review
Add missing include to get visibility right (715 bytes, patch)
2013-05-16 11:03 UTC, LRN
reviewed Details | Review
Alters .def references in the buildsystem (3.81 KB, patch)
2013-08-23 14:20 UTC, LRN
none Details | Review
ms-lib generation and patches to build on cygwin (9.11 KB, patch)
2014-01-28 09:03 UTC, Ake Rehnman
none Details | Review

Description LRN 2013-05-16 11:01:58 UTC
.def files were removed from the source tree and are not used to control symbol visibility anymore. Yet references to them persist throughout the buildsystem. THEY MUST BE KILLED WITH FIRE!

Seriously. Without that `make' fails.
Comment 1 LRN 2013-05-16 11:02:27 UTC
Created attachment 244389 [details] [review]
Removes references to .def files from the buildsystem
Comment 2 LRN 2013-05-16 11:03:41 UTC
Created attachment 244390 [details] [review]
Add missing include to get visibility right

Now that visibility is controlled by the prototype, we MUST let implementation see the prototype, otherwise it won't have the right visibility.
Comment 3 Emmanuele Bassi (:ebassi) 2013-05-16 11:22:15 UTC
Review of attachment 244389 [details] [review]:

the commit preamble seems to be broken. did you use `git format-patch` to generate it?
Comment 4 Emmanuele Bassi (:ebassi) 2013-05-16 11:22:43 UTC
Review of attachment 244390 [details] [review]:

looks okay, but the commit preamble seems broken as well.
Comment 5 Matthias Clasen 2013-05-16 23:57:21 UTC
Review of attachment 244390 [details] [review]:

Comment 6 Martin Schlemmer 2013-07-31 15:12:18 UTC
Review of attachment 244389 [details] [review]:

::: gdk/
@@ +274,3 @@
+gdk-win32-$(GTK_API_VERSION).lib: libgdk-win32-$(GTK_API_VERSION).la
+	lib -machine:@LIB_EXE_MACHINE_FLAG@ -name:libgdk-win32-$(GTK_API_VERSION)-@LT_CURRENT_MINUS_AGE@.dll -out:$@

These bits are wrong, as lib.exe will not generate the .lib if -def is not specified.

Either the MS_LIB_AVAILABLE logic should be totally removed, or the .def should be generated by LD via adding "-Wl,--output-def,$(srcdir)/gdk.def" to *_LDFLAGS.

I can supply changes if needed should MS_LIB_AVAILABLE logic stay.

I am not sure about the makefile.msc changes, as I rarely use nmake.
Comment 7 LRN 2013-08-23 14:20:09 UTC
Created attachment 252869 [details] [review]
Alters .def references in the buildsystem

The .def file REBURNED!

Instead of just removing it altogether, i've removed it only from the list of dependencies of the .la files (so that .dlls can be built without it - as they should be), and added rules for generating .def files from .dll files (using objdump and sed).
Comment 8 LRN 2013-09-09 22:41:41 UTC
Just to make sure this is not lost for future reference:
There's a bug in sed regex. "\s\+" (one or more characters of 'space' class) should be changed to "\s*" (zero or more characters of 'space' class).

Compared to the def that ld outputs (when called with --output-def), objdump-produced def lacks DATA directives and ordinal numbers.

Ordinal numbers do not matter, but i'm not sure about DATA directives.
Comment 9 Timothy Arceri 2013-10-01 03:33:54 UTC
*** Bug 702860 has been marked as a duplicate of this bug. ***
Comment 10 tarnyko 2013-11-25 11:29:38 UTC
This fix looks better than duplicates ( - e.g.) because it takes care of generating the .def files, too.

I will generate .lib files using this method and --output-def, compare and report back.
Comment 11 Ake Rehnman 2014-01-28 09:00:47 UTC
Building on windows (cygwin) is still broken. The default names for cygwin dlls are cygxxx.dll. For mingw it's libxxx.dll . Further, if ms-lib is available on the system for cygwin target build fails becase of OS_WIN32 exclusions in the makefiles. I've changed the makefiles to only look at MS_LIB_AVAILABLE. Even though it's now possible to generate ms libs under cygwin, I have changed the configure script to disable ms-lib for cygwin targets because win32 programs are not likely (I think) to use cygwin libraries anyway.

Add ms-lib files to CLEANFILES.

Don't try to run ms-lib if disable-shared, or build is failing. 

ms-lib .exp files are not installed.

Build is also failing if compiling for cygwin target with windows backend enabled. Configure is checking for windres only on win32_os builds. I believe it should be for all windows platforms (PLATFORM_WIN32).

Building for cygwin target with win32 backend enabled configure should set have_gio_unix=yes

INITGUID is not defined for cygwin target in gdk/win32/gdkdnd-win32.c. Add if defined (__CYGWIN__).

gailutil.def seem to be part of distribution. Remove?
Comment 12 Ake Rehnman 2014-01-28 09:03:59 UTC
Created attachment 267385 [details] [review]
ms-lib generation and patches to build on cygwin
Comment 13 Domenico Ferrari 2014-03-28 08:56:26 UTC
I have the same problem when cross-compiling Gtk 3.12.0 on Fedora with mingw32.
mingw32-make complains about missing rule to make target gdk.def.
I have removed all the references to gdk.def in gdk/Makefile but now there is a linking problem: missing linking object '-o'.
There errors is in the command for CCLD.

Any chance to cross-compile Gtk 3.12?

Comment 14 Jehan 2014-03-28 13:13:15 UTC
On bug 711772, I attached a patch with which I successfully cross-compiled GTK+ master.
Well I haven't retried lately, but hopefully it would still work well.
Comment 15 Domenico Ferrari 2014-03-28 13:42:46 UTC
Thank Jehan.
I will try it and report here.
I think it should be pushed in master and close this bug.
Comment 16 Domenico Ferrari 2014-03-28 20:07:03 UTC
The patch worked for gdk.def but I can't compile gtk.
I have this error

/usr/bin/ld: native_update_icon_cache-updateiconcache.o: undefined reference to symbol 'g_str_has_prefix'

To compile, I applied the patch and I issued

Comment 17 Jehan 2014-03-28 21:30:56 UTC
Hi Domenico,

I'll have a look and see if I can reproduce this issue and if the patch should be updated.

Without having tested yet though, I can already tell that's a strange error. g_str_has_prefix() is available since glib 2.2 and glib required version by GTK+ is higher. In any case, my patch does not add any actual code. So this error has likely another cause.
Anyway I'll check soon.
Comment 18 Domenico Ferrari 2014-03-29 21:22:57 UTC
If it can help you...
I compiled glib from sources because for gtk+-3.12.0 it is required to be >=2.39 and my mingw32-glib version is 2.38.
I downloaded glib-2.40.0 and then
mingw32-make install

I noticed that in gtk/native/Makefile there's this line
GLIB_CFLAGS_FOR_BUILD = -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include

It seems wrong to me, I'm compiling with mingw32 and not for my linux system.
Other lines have mingw32 paths.
GDK_PIXBUF_LIBS = -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl

I changed the line to
GLIB_CFLAGS_FOR_BUILD = -mms-bitfields -I/usr/i686-w64-mingw32/sys-root/mingw/include -I-I/usr/i686-w64-mingw32/sys-root/mingw/lib/glib-2.0/include

but now I have a bunch of weird errors

                 from /usr/i686-w64-mingw32/sys-root/mingw/include/glib-2.0/glib.h:30,
                 from ./../updateiconcache.c:36:
/usr/i686-w64-mingw32/sys-root/mingw/include/glib-2.0/glib/gtypes.h:474:33: warning: return type defaults to ‘int’ [-Wreturn-type]
 #        define GLIB_VAR extern __declspec(dllimport)
/usr/i686-w64-mingw32/sys-root/mingw/include/glib-2.0/glib/gmem.h:289:1: note: in expansion of macro ‘GLIB_VAR’
 GLIB_VAR gboolean g_mem_gc_friendly;

Comment 19 Jehan 2014-03-30 07:07:37 UTC
Hi Domenico,

Well, if not mistaken (it's been quite a few months I checked this code), the "native" tools are compiled for your native system, not for the target system, which explains why they were using the native glib. Thus it would not have been a bug. They are intermediary tools compiled to be used later on during compilation.

Anyway I'll have a look. Thanks for the info.
Comment 20 Domenico Ferrari 2014-03-30 10:47:06 UTC
About my error on comment 16 using the native build system (Fedor Linux x86_64).
Let me report the whole error.

make[3]: Entering directory `/root/gtk+-3.12.0/gtk/native'
  CC       native_update_icon_cache-updateiconcache.o
  CCLD     native-update-icon-cache.exe
/usr/bin/ld: native_update_icon_cache-updateiconcache.o: undefined reference to symbol 'g_str_has_prefix'
/usr/bin/ld: note: 'g_str_has_prefix' is defined in DSO /lib64/ so try adding it to the linker command line
/lib64/ could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

As for your comment, native-update-icon-cache should build and run on linux to complete tasks at compile-time.

1. the makefile is trying to compile an exe file (not a native executable)
2. my glib for mingw is 2.40 but in fedora I have 2.38.2

do mingw32-glib and fedora-glib have to be the same version?
Comment 21 Andrey Gursky 2014-06-30 16:52:02 UTC
Please mark as duplicate the bug report

By the way, why the status of this bug is still UNCONFIRMED? The bugzilla is full of bugs. The mentioned bug report without any comments and this one with some progress can't be distinguished while searching.

Comment 22 Hans Breuer 2014-07-01 05:40:52 UTC
*** Bug 711191 has been marked as a duplicate of this bug. ***
Comment 23 Ignacio Casal Quinteiro (nacho) 2014-07-14 13:21:42 UTC
I pushed this patch. Please try it out and let us know if it is OK.
Comment 24 LRN 2014-07-31 15:51:21 UTC
There are stray lines left in gtk/ They don't affect anything, just hang there, reminding us that .def files existed.

Also, libgail-util still uses a .def file to export (at least it supplies a .def file; whether the functions actually rely on that or have modern gtk macro wizardry to mark exported functions, i know not).
Comment 25 Fan, Chun-wei 2014-08-13 08:46:44 UTC
Hello LRN,

> Also, libgail-util still uses a .def file to export...

libgail-util still exports its symbols via the .def files, its headers don't have the export decoration macros, so, yes, that .def file is still used for Windows.

My takes on this, with blessings.
Comment 26 LRN 2015-04-06 07:30:00 UTC
Close it, maybe?
Comment 27 Matthias Clasen 2017-10-26 11:19:11 UTC
no longer relevant in master