GTK problem with FreeBasic 1.05

External libraries (GTK, GSL, SDL, Allegro, OpenGL, etc) questions.
Post Reply
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

GTK problem with FreeBasic 1.05

Post by 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
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: GTK problem with FreeBasic 1.05

Post by jj2007 »

Try defining a global variable g_mutex_unlock. Sometimes that helps.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: GTK problem with FreeBasic 1.05

Post by TJF »

VANYA wrote:
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
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: GTK problem with FreeBasic 1.05

Post by VANYA »

jj2007 wrote:Try defining a global variable g_mutex_unlock. Sometimes that helps.
With any ad, the compiler reports a double add (Duplicated definition...)

TJF wrote: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
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: GTK problem with FreeBasic 1.05

Post by TJF »

VANYA wrote: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
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: GTK problem with FreeBasic 1.05

Post by caseih »

jj2007 wrote: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
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: GTK problem with FreeBasic 1.05

Post by VANYA »

TJF wrote:Try headers from GNOME Header Set (32/64 bit).
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
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: GTK problem with FreeBasic 1.05

Post by TJF »

VANYA wrote: 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
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: GTK problem with FreeBasic 1.05

Post by 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
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: GTK problem with FreeBasic 1.05

Post by jj2007 »

caseih wrote:
jj2007 wrote: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
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: GTK problem with FreeBasic 1.05

Post by 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.
Post Reply