GNOME Bugzilla – Bug 700445
BURN THE DEF FILES!
Last modified: 2017-10-26 11:19:11 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.
Created attachment 244389 [details] [review] Removes references to .def files from the buildsystem
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.
Review of attachment 244389 [details] [review]: the commit preamble seems to be broken. did you use `git format-patch` to generate it?
Review of attachment 244390 [details] [review]: looks okay, but the commit preamble seems broken as well.
Review of attachment 244390 [details] [review]: yes
Review of attachment 244389 [details] [review]: ::: gdk/Makefile.am @@ +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.
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).
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.
*** Bug 702860 has been marked as a duplicate of this bug. ***
This fix looks better than duplicates (https://bugzilla.gnome.org/show_bug.cgi?id=702860 - https://bugzilla.gnome.org/show_bug.cgi?id=711772 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.
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?
Created attachment 267385 [details] [review] ms-lib generation and patches to build on cygwin
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? thanks!
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.
Thank Jehan. I will try it and report here. I think it should be pushed in master and close this bug.
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 mingw32-configure mingw32-make
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.
Hi. 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-configure mingw32-make 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. E.g. 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; Cheers, Domenico
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.
Hi. 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/libglib-2.0.so.0 so try adding it to the linker command line /lib64/libglib-2.0.so.0: 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?
Please mark as duplicate the bug report https://bugzilla.gnome.org/show_bug.cgi?id=711191. 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. Thanks, Andrey
*** Bug 711191 has been marked as a duplicate of this bug. ***
I pushed this patch. Please try it out and let us know if it is OK.
There are stray lines left in gtk/Makefile.am. 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).
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.
Close it, maybe?
no longer relevant in master