GNOME Bugzilla – Bug 675895
Docs for certain functions are built unconditionally
Last modified: 2012-05-17 04:05:23 UTC
The following functions are not compiled on W32, and gtkdoc-scan fails due to them being undefined: gtk_plug_get_type gtk_print_unix_dialog_get_type gtk_page_setup_unix_dialog_get_type gtk_socket_get_type gtk_printer_get_type gtk_print_job_get_type Possible ways of fixing it: 1) Do not put these functions into gtk3.types when compiling on platforms where these functions are not available 2) Only ifdef bodies of these functions (i.e. stub them on non-UNIX platforms). That way gtkdoc won't have problems with them.
Created attachment 213877 [details] [review] Make some gtk3 types conditional This fixes the bug by using the first approach: makes gtk3.types pre-processable, and doesn't put certain functions into it on W32.
Right now gtk-doc does this: $TYPES_FILE = $TYPES_FILE ? $TYPES_FILE : "$OUTPUT_DIR/$MODULE.types"; open (TYPES, $TYPES_FILE) || die "Cannot open $TYPES_FILE: $!\n"; open (OUTPUT, ">$MODULE-scan.c") || die "Cannot open $MODULE-scan.c: $!\n"; ... # write a C program to scan the types $includes = ""; @types = (); for (<TYPES>) { if (/^#include/) { $includes .= $_; } elsif (/^gnome_keyring_item_info_get_type$/) { # HACK: This isn't really a GObject type so skip it. next; } elsif (/^%/) { next; } elsif (/^\s*$/) { next; } else { chomp; push @types, $_; } } That is, it does not support any kind of conditions, so 1) is only implementable via gtk3.types.in (one way or another). Since number of problematic functions is small, it should be possible to try 2). I'll see if i can concoct something...
OK, while i was able to make stubs of _get_type functions, i haven't been able to coerce ld into NOT cutting them out after linking libgtk together. Or maybe something else has gone wrong, i don't know. But symbols just aren't there - neither gtkdoc-scan, nor nm can find them.
Created attachment 213910 [details] [review] Don't use .def to export symbols Found the reason why i was missing symbols in the library - a .def file was used to define exported symbols and, of course, it didn't have the new functions in it. If you like .def so much, maybe you should marry it? WELL, I WON'T LET YOU!!! How does that feel? Seriously though: keep updating it, if you think you must, but keep it away from MinGW. If some non-static symbols shouldn't be exported, use -export-regex or something like that.
Created attachment 213911 [details] [review] Add stubs for several _get_type() functions These stubs are there only to please gtk-doc.
Created attachment 213930 [details] [review] Make some gtk3 types conditional (GStreamer-style)
OK, pre-processed (GStreamer-style) gtk3.types.in is the way to go (at least, that is what Company thinks is best). Thus i'm obsoleting the stub-patch. It pre-processed gtk3.types.in works without the anti-.def patch. However, i still think that using a .def is not really appropriate for GTK+, and that def should be abandoned in favour of -export-symbols-regex, so i'll keep the patch.
Comment on attachment 213930 [details] [review] Make some gtk3 types conditional (GStreamer-style) Looks good.
The following fix has been pushed: 5eb286b Make certain gtk3 types conditional (GST-style)
Created attachment 214231 [details] [review] Make certain gtk3 types conditional (GST-style)