|
Post by Pjot on Oct 18, 2023 6:03:14 GMT 1
Thanks Paulov,
Weird thing is, when I start a Debian10 with XFCE live CD, and compile BaCon, everything works out-of-the-box. You can verify this yourself. I do not even need to install additional dependencies to make something work.
Therefore it makes sense to conclude that the problem does not relate to Debian itself, but to something in your environment.
The IMPORT statement tries to see if 'gtk_init' is available in the GTK2 library. I know in some systems the function 'gtk_init' is defined as a macro. In such case, HUG cannot find GTK2. Maybe you have installed GTK2 from somewhere else.
Can you see with this command if 'gtk_init' exists?
nm -D /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 | grep init
Also, could I see the output of this command:
pkg-config --cflags --libs gtk+-2.0
This should point to the exact location where GTK2 resides.
Lastly, does your shell have the variable LD_LIBRARY_PATH explicitly defined? If so, the IMPORT only looks there to find GTK2. Can we therefore see the LD_LIBRARY_PATH variable?
# echo $LD_LIBRARY_PATH
Note that all dependencies must be satisfied, e.g. the command 'ldd /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0' must satisfy all dependencies for GTK2, and for all those dependencies, their subsequent dependencies also must be satisfied, and so on. So if you're missing a library in the GTK2 framework then we will see the same error.
A vanilla Debian-10 installation fulfills all these dependencies though, but please make sure your system has them as well.
HTH Peter
|
|
|
Post by paulov on Oct 18, 2023 12:05:30 GMT 1
Hi Peter, Thank you very much for your patience and time. I suspect that perhaps the reason has been found, when I do a: echo $LD_LIBRARY_PATH The output is empty. Now apparently this is common in some Debian releases, so I don't know how other pgms are compiled. Just out of interest, that Live Debian CD that you tried out, what was it's $LD_LIBRARY_PATH? Please see: StackExchange-about-LD_LIB_PATH-DebianSo now I'm confused, what do I need to do that will not possibly affect other pgms? I'm a bit sceptical of adding it to my .bashrc file as that will make it system wide. I don't mind having to run a small Bash script to "export" a required $LD_LIBRARY_PATH before using Bacon. This way, it's only valid until a restart. What exactly should an "export" command contain? (where should it point to for bacon to compile correctly?) I did try /usr/lib/x86_64-linux-gnu/ but that had no effect. As for the other cmds you asked me to run: paulo@lenovo:~$ nm -D /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 | grep init U atk_object_initialize U cairo_matrix_init U FcInitReinitialize U g_datalist_init U g_hash_table_iter_init U g_initially_unowned_get_type U g_once_init_enter U g_once_init_leave U g_test_init 0000000000255b90 T gtk_decorated_window_init 0000000000130770 T gtk_init 0000000000130d50 T gtk_init_add 0000000000130750 T gtk_init_check 0000000000130560 T gtk_init_with_args 00000000002a5a10 T gtk_preview_uninit 00000000001bbbc0 T gtk_test_init 000000000023f250 T gtk_type_init 000000000025d300 T gtk_window_reshow_with_initial_size U g_type_init U g_type_init_with_debug_flags U g_value_init U g_variant_iter_init paulo@lenovo:~$ pkg-config --cflags --libs gtk+-2.0 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -
I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -
I/usr/include/libmount -I/usr/include/blkid -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -
I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -I/usr/include/freetype2 -
I/usr/include/libpng16 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0
-lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype
|
|
|
Post by Pjot on Oct 18, 2023 18:40:41 GMT 1
Hi Paulov, The Debian LiveCD I am using can be found here. You'll see that installing BaCon and compiling the HUG program works out of the box. Regarding the LD_LIBRARY_PATH variable, to my understanding it is a good thing is does not contain any value. The environment variable also is empty in the Debian-10 LiveCD. The output of pkg-config is the same on the LiveCD, so that also looks OK. To verify the dependencies, we can use the tool "lddtree" from the package "pax-utils". If you have this package installed, then simply run: user@debian:~$ lddtree /lib/x86_64-linux-gnu/libgtk-x11-2.0.so libgtk-x11-2.0.so => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so (interpreter => none) libgdk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
This lists all the related dependencies in a tree format, and also the subsequent dependencies of dependencies etc. Everything should be satisfied there. Could you check the same on your system? If this is fine then I am kind of running out of ideas. You may need to compare the Debian LiveCD environment with your environment and look for differences. However, I can suggest some alternatives: - forum member Alex has ported HUG to the GTK3 framework. You can find his endeavor here. - you can use the native GUI functions from BaCon, though you need to rewrite your code. Nevertheless, you might find the result very satisfying as it will narrow down the amount of lines tremendously, as it will omit the HUG file altogether. For example, your demo program could look like this: OPTION GUI TRUE PRAGMA GUI gtk2 PRAGMA OPTIONS -DGLIB_DISABLE_DEPRECATION_WARNINGS
id = GUIDEFINE(" \ { type=WINDOW name=window callback=delete-event title=\"Test GUI 1\" width-request=800 height-request=400 window-position=1 } \ { type=VBOX name=vbox parent=window } \ { type=SCROLLED_WINDOW name=swin parent=vbox height-request=370 } \ { type=TEXT_VIEW name=view parent=swin buffer=NULL } \ { type=HBUTTON_BOX name=bbox parent=vbox layout-style=GTK_BUTTONBOX_END } \ { type=BUTTON name=button parent=bbox callback=clicked label=\"Exit\" }")
CALL gtk_text_buffer_set_text(gtk_text_view_get_buffer(GTK_TEXT_VIEW(GUIWIDGET(id, "view"))), EXEC$("ls"), -1)
WHILE TRUE event$ = GUIEVENT$(id)
SELECT event$ CASE "window", "button" END ENDSELECT WEND
- another alternative is to embed the GTK functions straight into your BaCon code, as in fact happens in the previous example as well (see the CALL). I hope you'll find BaCon useful for your purposes! BR Peter
|
|
|
Post by paulov on Oct 18, 2023 19:44:39 GMT 1
Thank you Peter.
OK, so it's been established that an empty LD_LIBRARY_PATH is not a bad thing, I'm glad.
As to lddtree on my system, everything looks in order:
paulo@lenovo:~$ lddtree /lib/x86_64-linux-gnu/libgtk-x11-2.0.so
libgtk-x11-2.0.so => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so (interpreter => none) libgdk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 I have also tried the example you gave and it compiled and ran perfectly. However, I'm not too fond of the syntax, it looks like a mix of C and Lisp and with multiple buttons and other "widgets", it will very quickly become rather error prone.
Also don't want to have to learn a whole bunch of new declarations like "gtk_text_buffer_set_text", etc, so will continue to look for a possible solution (also comparing to the Live CD) when time permits.
For now, will just use Bacon to compile CLI pgms and use gtkdialog (with easier xml syntax structure) to wrap around the cli pgms when needed.
Thanks again for trying to help out.
|
|
|
Post by alexfish on Oct 18, 2023 23:02:56 GMT 1
Hi paulov
as mentioned , can not help with debugging but in respect of
as a point to a possible problem can look here with reference to can happen when concatting , ie when 2 ascii chars meet and gtk2 text buffer sees them as utf* or a miss alignment
area of interest hug gcode thread
Now to the GUI
need to see if can get a hug window first
from your code
INCLUDE "hug.bac" ' ------------------------------------------------------------- ' Create main window sized 1280 X 720 in this case ' -------------------------------------------------------------
Mainwin = WINDOW("Test GUI 1", 1280,720) DISPLAY
if this window shows
then
INCLUDE "hug.bac" ' ------------------------------------------------------------- ' Create main window sized 1280 X 720 in this case ' -------------------------------------------------------------
Mainwin = WINDOW("Test GUI 1", 1280,720)
' ------------------------------------------------------------- ' Attach a textbox sized 1238 X 242 at position 20,20 ' -------------------------------------------------------------
TEXT1 = EDIT(1238, 242) ATTACH(Mainwin, TEXT1, 20, 20)
' ------------------------------------------------------------- ' Attach a button sized 220 X 118 at position 500,560 ' -------------------------------------------------------------
BUTTON1 = STOCK("gtk-quit", 220, 118) ATTACH(Mainwin, BUTTON1, 500, 560) CALLBACK(BUTTON1, QUIT)
DISPLAY
if show's then type some text
BR Alex
in response gtk bits posted
#include <gtk/gtk.h>
static int counter = 0;
void greet( GtkWidget *widget, gpointer data ) { g_print ("Hi there! Welcome to GTK\n"); g_print ("%s clicked %d times\n", (char*)data, ++counter); }
void destroy( GtkWidget *widget,gpointer data ) { gtk_main_quit (); }
int main( int argc,char *argv[] ) {
GtkWidget *window; GtkWidget *button; gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (window, "destroy", G_CALLBACK (destroy), NULL);
gtk_container_set_border_width (GTK_CONTAINER (window), 20);
button = gtk_button_new_with_label ("Click Me!");
g_signal_connect (GTK_OBJECT(button), "clicked",G_CALLBACK (greet), "button");
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show_all(window);
gtk_main ();
return 0; }
|
|
|
Post by alexfish on Oct 18, 2023 23:19:17 GMT 1
Thought would add
only buffer identified to date is gtk2
sourceview buffer gtk2 & gtk3 = OK
have not test hug gtk3 since in process of finalizing hug3.5.3 the hug3.5.2 had my own fix bits mention in the thread(rare bug) and to be removed in the hug3.5.3
yep was in process of until I saw This
BR Alex
|
|
|
Post by paulov on Oct 19, 2023 1:22:33 GMT 1
UPDATE:
Got it to work!!!
Out of desperation, had a look at "hug.bac" again in more detail and noticed lines like 111, where I thought "what if for some reason, the script is not appending the correct value to variable STR$(hug_sequence)"?
IF NOT(INSTR(hug_lib$, "dylib")) AND NOT (INSTR(hug_lib$, "dll")) THEN hug_lib$ = CONCAT$("libgtk-x11-2.0.so", STR$(hug_sequence)) So I changed that line to:
IF NOT(INSTR(hug_lib$, "dylib")) AND NOT (INSTR(hug_lib$, "dll")) THEN hug_lib$ = "libgtk-x11-2.0.so.0" I also changed the following lines:
143 => "libgdk-x11-2.0.so.0" 175 => "libgdk_pixbuf-2.0.so.0" 208 => "libglib-2.0.so.0" 240 => "libgobject-2.0.so.0" 272 => "libpango-1.0.so.0" 302 => "libgtkgl-2.0.so.0" 331 => "libgtkglext-x11-1.0.so.0" 377 => "libGL.so.1"
So now compiling with bacon mypgm.bac works perfectly. (BTW I'm using Bacon 4.7.1)
Not sure why the STR$(hug_sequence) part at the end of those lines are not working, but hey, I'm happy.
|
|
|
Post by Pjot on Oct 19, 2023 6:05:36 GMT 1
Thanks Paulov,
That is good news! The fix you have applied would be the very last place where I would be looking.
But if the versioning construct does not work, how does it look like then?
I know this issue has been dragging along for too long, but I would like to ask one favor, if you have time.
In the original HUG file, could you add a simple line of code between line 111 and 112 (so just before the IMPORT) as follows:
PRINT hug_lib$
Then, compile as follows:
# bacon -p mypgm.bac
Please run the program. I am curious to see the output generated on your system. My suspicion is there's something going on with the deprecated CONCAT$ function.
The '-p' flag will preserve the generated C code. Could you also please tar the generated sources and post them here?
Thanks again, Peter
|
|
|
Post by paulov on Oct 19, 2023 11:27:56 GMT 1
Hi Peter,
No bother at all. I have done the tests as you requested but, the resulting tar file is close to 1.9MB and the forum limit is 1MB per file.
However here is some console output that may help you without the need of the .tar file:
paulo@lenovo:~/Downloads/Bacon/bacon-4.7.1/Paulo/TestForPeter$ bacon -p gui1.bac Converting 'gui1.bac'... done, 3028 lines were processed in 0.260 seconds. Creating lexical analyzer using flex... done. Applying indentation... indent: ./hug.hug_Get_Gtk__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Gdk__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Gdkpixbuf__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Glib__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Gobject__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Pango__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_GtkGlArea__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_GtkGlExt__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Goocanvas__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
indent: ./hug.hug_Get_Gl__b2c__string_var.h:9: Warning:old style assignment ambiguity in "=-". Assuming "= -"
done. Compiling 'gui1.bac'... cc -c gui1.bac.c cc -o gui1 gui1.bac.o -ldl -lm Done, program 'gui1' ready. Running the compiled pgm gives the error but the inserted "PRINT hug_lib$" reveals something interesting:
paulo@lenovo:~/Downloads/Bacon/bacon-4.7.1/Paulo/TestForPeter$ ./gui1 libgtk-x11-2.0.so0 libgtk-x11-2.0.so1 libgtk-x11-2.0.so2 libgtk-x11-2.0.so3
...... etc etc ......
libgtk-x11-2.0.so47 libgtk-x11-2.0.so48 libgtk-x11-2.0.so49 Gtk library not found! So it looks like a simple period "." after the "so" on those lines, may do the trick:
IF NOT(INSTR(hug_lib$, "dylib")) AND NOT (INSTR(hug_lib$, "dll")) THEN hug_lib$ = CONCAT$("libgtk-x11-2.0.so.", STR$(hug_sequence)) Will do another test with the original HUG.bac file modified in that way and revert back.
=============================================================================== EDIT: ===============================================================================
OK found the problem.... It's only Line 111 (of the original HUG.bac) that does not have a period after the "so".
Once I added it, all is good, the pgm compiles and runs perfectly. I think we can put this mystery behind us.
paulo@lenovo:~/Downloads/Bacon/bacon-4.7.1/Paulo/TestForPeterTwo$ bacon gui1.bac Converting 'gui1.bac'... done, 3028 lines were processed in 0.255 seconds. Creating lexical analyzer using flex... done. Compiling 'gui1.bac'... cc -c gui1.bac.c cc -o gui1 gui1.bac.o -ldl -lm Done, program 'gui1' ready. paulo@lenovo:~/Downloads/Bacon/bacon-4.7.1/Paulo/TestForPeterTwo$ ./gui1 libgtk-x11-2.0.so.0 libgtk-x11-2.0.so.0 paulo@lenovo:~/Downloads/Bacon/bacon-4.7.1/Paulo/TestForPeterTwo$
|
|
|
Post by Pjot on Oct 19, 2023 15:10:20 GMT 1
Thanks paulov, Indeed, the period sign seems to be missing! Strange? It is strange, because the original HUG file from the BaCon website does show the period sign is there. That leads to the question: from where you did get the HUG include file in the first place? If it is from the BaCon website then it could have been scrambled by an erroneous download. But if it is part of some Debian package then I can contact the packager to have it corrected. Anyway, it is good news that HUG now is working for you. Thanks for your patience, and do not hesitate to come back to this forum in case you need more help. Best regards Peter
|
|
|
Post by paulov on Oct 19, 2023 15:55:01 GMT 1
I definitely got HUG.bac from your website as per your link.
It is indeed very weird, the chances of a corrupt download only affecting that one character are infinitesimally small. I certainly did not edit the file until yesterday as I previously posted.
Cannot explain it.
I have had Bacon downloaded on my drive for quite some time (originally ver 3.7) but haven't used it until a few days before I started this thread, once I encountered the problems. It was at the same time that I must have downloaded HUG.bac as well (when I downloaded ver 3.7).
When I updated to 4.7.1, I simply copied the original HUG.bac to the same folder as mypgm.bac to be compiled with 4.7.1
Thanks again for all your time and patience.
|
|