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?
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.)
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:
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
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
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.
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.
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.