GTK problem with FreeBasic 1.05

[VANYA]

Hi all!

It took GTK library for one project. In Linux all ok. In Windows with the compiler 1.05, an error is displayed when compiling:

FbTemp.o:fake:(.text+0x267): undefined reference to `g_mutex_unlock'

I tried to compile using compiler 1.03, everything works fine. Is this the problem of the compiler or the headers or import libraries? Who will advise what?

[jj2007]

Try defining a global variable g_mutex_unlock. Sometimes that helps.

[TJF]

FbTemp.o:fake:(.text+0x267): undefined reference to `g_mutex_unlock'

It's no compiler error, it' comming from the linker (input .o, not .bas).

Just for curiosity: which source code throughs this error? (You'll never need this function, unless you create your own widgets, multithreaded at low level GLib programming.)

[VANYA]

Try defining a global variable g_mutex_unlock. Sometimes that helps.

With any ad, the compiler reports a double add (Duplicated definition...)

Just for curiosity: which source code throughs this error? (You'll never need this function, unless you create your own widgets, multithreaded at low level GLib programming.)

Absolutely ANY code displays this error message. Maybe this error is due to the fact that I'm using GTK 2.24.10 ? Just how I put this version many years ago, I did not change it. Compilers of freebasic versions: up to 1.03 worked without problems , version 1.04 did not try, and version 1.05 highlights an error on any source code

added last:

If in the file inc\glib.bi, in the procedure g_mutex_locker_free comment g_mutex_unlock, then the error disappears:

Code: Select all

Private sub g_mutex_locker_free(byval locker as GMutexLocker ptr)
   g_mutex_unlock(cptr(GMutex ptr, locker))
end sub

But this is wrong, but suddenly this function will be needed...

[TJF]

Absolutely ANY code displays this error message. Maybe this error is due to the fact that I'm using GTK 2.24.10 ? Just how I put this version many years ago, I did not change it. Compilers of freebasic versions: up to 1.03 worked without problems , version 1.04 did not try, and version 1.05 highlights an error on any source code

It seems to be a problem in the GLib-2.0.bi header. Try headers from GNOME Header Set (32/64 bit). (Direct download: https://www.freebasic-portal.de/dlfiles ... ers-1.0.7z)

The headers install into a Gir folder in your include directory, so you can have both, original and Gir headers on your system. Just change in your code

Code: Select all

#INCLUDE ONCE "Gtk/Gtk-2.0.bi"
' to
#INCLUDE ONCE "Gir/Gtk-2.0.bi"

[caseih]

Try defining a global variable g_mutex_unlock. Sometimes that helps.

No. g_mutex_unlock is an internal part of glib. If the linker can't find it something isn't quite right between the header files and the actual shared library, and things may not function as they should if you just make that symbol up in your own code. Better to solve the actual problem.

[VANYA]

[quote=TJF]Try headers from GNOME Header Set (32/64 bit).[/quote]

Are these headers for Windows? At me at compilation demands linux libraries:

ld.exe: cannot find -lgdk-x11-2.0
ld.exe: cannot find -lgtk-x11-2.0

[TJF]

Are these headers for Windows? At me at compilation demands linux libraries:

ld.exe: cannot find -lgdk-x11-2.0
ld.exe: cannot find -lgtk-x11-2.0

Ups, sorry. The old naming in Gtk2 isn't prepared for GObject introspection. You can fix it:

Code: Select all

' file Gdk-2.0.bi line 2804 [EXTERN "C" LIB "gdk-x11-2.0"] becomes
#IFDEF __FB_UNIX__
  EXTERN "C" LIB "gdk-x11-2.0"
#ELSE
  EXTERN "C" LIB "gdk-win32-2.0"
#ENDIF


and

Code: Select all

' file Gtk-2.0.bi line 1633 [EXTERN "C" LIB "gtk-x11-2.0"] becomes
#IFDEF __FB_UNIX__
  EXTERN "C" LIB "gtk-x11-2.0"
#ELSE
  EXTERN "C" LIB "gtk-win32-2.0"
#ENDIF


[VANYA]

It seems that everything turned out well. I did not test much, but the source file that I needed was compiled and started. Thank you TJF!

[jj2007]

Try defining a global variable g_mutex_unlock. Sometimes that helps.

No. g_mutex_unlock is an internal part of glib. If the linker can't find it something isn't quite right between the header files and the actual shared library, and things may not function as they should if you just make that symbol up in your own code. Better to solve the actual problem.

You are absolutely right, of course - I should not have proposed that hack. Nonetheless, the internet is full of such cases. I had myself some "missing" variables in C/C++ libraries. When I hunted them down, I arrived at routines that just returned nothing and were never called. So I added an empty proc to my own source, and everything was fine. Until the next version of the library comes out, of course. You have no idea what kind of crap gets produced by C/C++ compilers.

[caseih]

Off topic here. I know you think pretty highly of your own assembly skills, but compilers are much better than you give them credit for. I watched a really cool talk recently about using C++17 with advanced features like object-oriented programming and templates to make a game that compiled down to incredibly optimized 6502 assembly for a C64 (pretty much as good as any human could do). Just a fascinating look at how good compilers really are in 90% of cases.