search

gerbv / gerbv

Maintained fork of gerbv, carrying mostly bugfixes
https://gerbv.github.io/
GNU General Public License v2.0
120 stars 38 forks source link

porting to Windows and packaging #19

Open efa opened 3 years ago

efa commented 3 years ago

I had opened this issue just to discuss my tests and try to build current (and maybe old) sources to Win10 64 bit. In the past I had built v2.6.2 and v2.7.0 @32/64bit for Win7, and git sources till 2020 @32/64bit for Win10. I had made some tests now with github sources, I report here results and maybe ask solutions as not everything work as expected.

efa commented 3 years ago

the first thing I discovered was that v2.7.0 and next git built, do not generated "src/.libs/libgerbv-1.dll" (like happen on a Linux build with .so) and that installations maybe use the 2.6.2 version in the system, and luckily worked but has to be solved. Current github sources has the same problem, I cannot find libgerbv-1.dll, while binary is built. Will go into it to check dependencies and reasons

efa commented 3 years ago

I had an archive of the source and binaries I generated, I re-tested all, and get this results:

gerbv_date_______ver___bit____    libgerbv test     gvp+layer
gerbv_2017-03-25_2.6.2_32bit      YES      stable   NO        
gerbv_2017-03-25_2.6.2_64bit      YES      stable   NO        
gerbv_2017-03-25_2.6Agit_32bit    YES      stable   NO        
gerbv_2017-03-25_2.6Agit_64bit    YES      stable   NO        
gerbv_2018_07-26_2.6Agit_32bit    YES      stable   NO        
gerbv_2018_07-26_2.6Agit_64bit    YES      stable   NO        
gerbv_2018-11-26_2.6Agit_64bit    YES      unstable YES       
gerbv_2019-01-28_2.7.0_32bit      NO       unstable YES       
gerbv_2019-01-28_2.7.0_64bit      NO       unstable YES       
gerbv_2020-11-23_2.7Agit_32bit    NO       unstable YES       
gerbv_2020-11-23_2.7Agit_64bit    NO       unstable YES       
gerbv-2021-09-06_2.7Agit_64bit    NO       unstable YES       

gerbv-2021-09-06_2.7Agithub_64bit NO       unstable YES

so seems not related to libgerbv presence, as there is at least one version that generated it, but it is still unstable. Anyway I will check with ldd if those new version depend on the library. What happen is that opening a .gvp first time work, opening a second maybe, opening the 3th goes to Segmentation fault.

About last github sources ~bcc3ba, on Windows I cannot cannot open any .gvp also the first one, as goes to Segmentation fault. Opening layers single or multiple, work always stable.

To me seems related to the open dialog integration of layers and project patch, happened sometime in between 2.6.2 and 2.7.0 Interestingly on linux always work.

eyal0 commented 3 years ago

I used libgerbv in Windows with msys2 in the pcb2gcode project. It works well and passes all tests.

What is your goal for a windows build of gerbv? Do you want just the library or the GUI, too?

efa commented 3 years ago

we use the GUI. I updated the table showing which versions has the integrated open dialog gvp+layers.

I had to check anoyther thing, as I normally apply a patch to 'gerbv.h', I had to recompile those versions without, to be sure does not depend on that My build env is MSYS2

efa commented 3 years ago

the not generation of "src/.libs/libgerbv-1.dll" seems related to this build message:

/bin/sh ../libtool  --tag=CXX   --mode=link g++  -g -O2 -version-info 1:9:0 -no-undefined  -o libgerbv.la -rpath /mingw64/lib amacro.lo csv.lo draw-gdk.lo draw.lo drill.lo drill_stats.lo export-drill.lo export-geda-pcb.lo export-image.lo export-isel-drill.lo export-rs274x.lo gerb_file.lo gerb_image.lo gerb_stats.lo gerber.lo gerbv.lo pick-and-place.lo selection.lo tooltable.lo   -lm   -LD:/Programmi/msys64/mingw64/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdi32 -lmsimg32 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -LD:/Programmi/msys64/mingw64/lib -lcairo
libtool: link: rm -fr  .libs/libgerbv.a .libs/libgerbv.la .libs/libgerbv.lai

*** Warning: linker path does not have real file for library -limm32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libimm32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: D:/Programmi/msys64/mingw64/x86_64-w64-mingw32/lib/libimm32.a

*** Warning: linker path does not have real file for library -lole32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libole32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: D:/Programmi/msys64/mingw64/x86_64-w64-mingw32/lib/libole32.a

*** Warning: linker path does not have real file for library -lgdi32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgdi32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: D:/Programmi/msys64/mingw64/x86_64-w64-mingw32/lib/libgdi32.a

*** Warning: linker path does not have real file for library -lmsimg32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmsimg32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: D:/Programmi/msys64/mingw64/x86_64-w64-mingw32/lib/libmsimg32.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: ar cru .libs/libgerbv.a  amacro.o csv.o draw-gdk.o draw.o drill.o drill_stats.o export-drill.o export-geda-pcb.o export-image.o export-isel-drill.o export-rs274x.o gerb_file.o gerb_image.o gerb_stats.o gerber.o gerbv.o pick-and-place.o selection.o tooltable.o
D:\Programmi\msys64\mingw64\bin\ar.exe: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libgerbv.a
libtool: link: ( cd ".libs" && rm -f "libgerbv.la" && cp -pR "../libgerbv.la" "libgerbv.la" )
efa commented 3 years ago

with ldd I can confirm that gerbv versions that do not generated libgerbv DLL, do not depend on that external dependency while older one that generated the DLL, depend on that. For example:

user@host MINGW64 /d/installer/gerbv_2017-03-25_2.6Agit/Win64/gerbv_git2017-03-25_64bit/gerbv_git2017-03-25_64/bin
$ ldd gerbv.exe | grep libgerbv
        libgerbv-1.dll => /d/installer/gerbv_2017-03-25_2.6Agit/Win64/gerbv_git2017-03-25_64bit/gerbv_git2017-03-25_64/bin/libgerbv-1.dll (0x6de00000)
efa commented 3 years ago

without my patch the results are the same.

I rechecked the dependency with ldd, and all DLL are available, copyed from Mingw path: /d/Programmi/msys64//mingw64/bin or /d/Programmi/msys64//mingw32/bin

This is the installation directory:

gerbv_2021-09-06github_64bit
├── bin
│   ├── gerbv.exe
│   ├── libatk-1.0-0.dll
│   ├── libbrotlicommon.dll
│   ├── libbrotlidec.dll
│   ├── libbz2-1.dll
│   ├── libcairo-2.dll
│   ├── libdatrie-1.dll
│   ├── libexpat-1.dll
│   ├── libffi-7.dll
│   ├── libfontconfig-1.dll
│   ├── libfreetype-6.dll
│   ├── libfribidi-0.dll
│   ├── libgcc_s_seh-1.dll
│   ├── libgdk-win32-2.0-0.dll
│   ├── libgdk_pixbuf-2.0-0.dll
│   ├── libgio-2.0-0.dll
│   ├── libglib-2.0-0.dll
│   ├── libgmodule-2.0-0.dll
│   ├── libgobject-2.0-0.dll
│   ├── libgraphite2.dll
│   ├── libgtk-win32-2.0-0.dll
│   ├── libharfbuzz-0.dll
│   ├── libiconv-2.dll
│   ├── libintl-8.dll
│   ├── libpango-1.0-0.dll
│   ├── libpangocairo-1.0-0.dll
│   ├── libpangoft2-1.0-0.dll
│   ├── libpangowin32-1.0-0.dll
│   ├── libpcre-1.dll
│   ├── libpixman-1-0.dll
│   ├── libpng16-16.dll
│   ├── libstdc++-6.dll
│   ├── libthai-0.dll
│   ├── libwinpthread-1.dll
│   └── zlib1.dll
└── share
    └── gerbv
        └── scheme
            └── init.scm

any hint?

efa commented 3 years ago

I captured the crashlog of the current github sources build @64bit on Win10, happen opening every .gvp:

gerbv.exe caused an Access Violation at location 00007FF770BCA828 in module gerbv.exe Writing to location 000000008D2C87A0.

AddrPC           Params
00007FF770BCA828 0000000000001068 000002468CE73660 000002468B178AE0  gerbv.exe!alloc_cellseg  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/scheme.c @ 600]
   598:         last = newp + CELL_SEGSIZE - 1;
   599:           for (p = newp; p <= last; p++) {
>  600:                typeflag(p) = 0;
   601:                cdr(p) = p + 1;
   602:                car(p) = sc->NIL;
00007FF770BD2EE0 000002468CEA3150 000002468CE73660 000002468CE7368D  gerbv.exe!scheme_init_custom_alloc  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/scheme.c @ 4194]
  4192:   sc->interactive_repl=0;
  4193:   
> 4194:   if (alloc_cellseg(sc,FIRST_CELLSEGS) != FIRST_CELLSEGS) {
  4195:     sc->no_memory=1;
  4196:     return 0;
00007FF770BD3479 000002468CEA3150 000002468BC03030 00007FF770C0F9F6  gerbv.exe!scheme_init_new  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/scheme.c @ 4160]
  4158: 
  4159: int scheme_init(scheme *sc) {
> 4160:  return scheme_init_custom_alloc(sc,malloc,free);
  4161: }
  4162: 
00007FF770BC83A7 000002468CEE9BD0 0000000000000000 0000000000000000  gerbv.exe!read_project_file  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/project.c @ 990]
   988:     }
   989: 
>  990:     sc = scheme_init_new();
   991:     scheme_set_output_port_file(sc, stdout);
   992: 
00007FF770BC6A90 0000000000001001 0000000000000000 0000000000000000  gerbv.exe!main_open_project_from_filename  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/main.c @ 197]
   195: 
   196: dprintf("Opening project = %s\n", (gchar *) filename);
>  197: list = read_project_file(filename);
   198: 
   199: if (!list) {
00007FF770BB8446 0000000000000000 0000000000000001 0000000000000001  gerbv.exe!open_files.part.0
00007FF770BB862F 000002468B1DC110 00007FFC958C66FC 0000000000000000  gerbv.exe!callbacks_open_activate  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/callbacks.c @ 227]
   225: gint answer;
   226: 
>  227: if (filenames == NULL)
   228: return;
   229: 
00007FFCAC826ECE 0000024600000001 00000099747FECA0 00000099747FEDB0  libgobject-2.0-0.dll!g_closure_invoke
00007FFCAC838EF9 000002468B1E95A0 0000000000000000 000002468B1DE0C0  libgobject-2.0-0.dll!g_signal_handler_disconnect
00007FFCAC83EB84 000002468B1DE0C0 00000099747FF1E0 0000024600000000  libgobject-2.0-0.dll!g_signal_emit_valist
00007FFCAC83EFE8 000002468B1DE0C0 00007FFCC8EAEC1B 0000024600000000  libgobject-2.0-0.dll!g_signal_emit
00007FFC959D68EB 000002468B194E20 00007FFC958C4B74 000002468B1F5100  libgtk-win32-2.0-0.dll!gtk_widget_activate
00007FFC958C701D 000002468B1C9CD0 00007FFC958BCC58 00000099747FF1E0  libgtk-win32-2.0-0.dll!gtk_menu_shell_activate_item
00007FFC958C72DA 00000099747FF0D0 0000000000000000 0000000000000002  libgtk-win32-2.0-0.dll!gtk_menu_shell_activate_item
00007FFC958B40C3 000002468BC0CE00 0000000000000000 000002468BC0CE00  libgtk-win32-2.0-0.dll!gtk_marshal_VOID__UINT_STRING
00007FFCAC826ECE 0000009900000002 0000000000000000 00000099747FF170  libgobject-2.0-0.dll!g_closure_invoke
00007FFCAC838933 00000099747FF260 0000000000000000 00000099747FF398  libgobject-2.0-0.dll!g_signal_handler_disconnect
00007FFCAC83E854 000002468B1F5100 00007FFC959D757A 00007FFC00000000  libgobject-2.0-0.dll!g_signal_emit_valist
00007FFCAC83EFE8 00000099747FF498 00007FFC959D8ADA 00007FFC00000000  libgobject-2.0-0.dll!g_signal_emit
00007FFC959D7B05 0000024600000000 0000000000000000 0000024600000000  libgtk-win32-2.0-0.dll!gtk_widget_translate_coordinates
00007FFC958B2613 00007FFC9D2A0A00 00007FFCC9F1E299 0000000000003DFF  libgtk-win32-2.0-0.dll!gtk_propagate_event
00007FFC958B2A9B 00000099747FF510 0000000000000000 00007FFCC9F1E040  libgtk-win32-2.0-0.dll!gtk_main_do_event
00007FFC9D29C729 000002468B1B5A80 00007FFC975DB62D 0000000000000000  libgdk-win32-2.0-0.dll!gdk_win32_drawable_get_handle
00007FFC975D88F4 000002468BC1E0E0 00007FFC97636FBA 00007FF770C1F0A0  libglib-2.0-0.dll!g_clear_list
00007FFC975DBA46 00000001747FFB38 000002468B23FB10 000002468BC1E0E0  libglib-2.0-0.dll!g_main_context_check
00007FFC975DBF6C 000002468B1B51E0 0000000000000000 00000099747FFB50  libglib-2.0-0.dll!g_main_loop_run
00007FFC958B190A 00007FF700000003 00007FF770C1F0C0 0000000000000001  libgtk-win32-2.0-0.dll!gtk_main
00007FF770BC4143 00000000FFFFFFFF 00007FF7FFFFFFFF 00007FF770C0DA68  gerbv.exe!interface_create_gui  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/interface.c @ 1831]
  1829:                   G_CALLBACK (callbacks_sidepane_render_type_combo_box_changed),
  1830:                   NULL);
> 1831: gtk_main();
  1832: interface_save_accels ();
  1833: }
00007FF770C01EC0 0000000000000001 000002468B17B1F0 00007FF770C1F958  gerbv.exe!main  [C:/Users/vmessina/c/gerbv-2021-09-06github/src/main.c @ 1109]
  1107:     }
  1108:     gtk_init (&argc, &argv);
> 1109:     interface_create_gui (req_width, req_height);
  1110:     
  1111:     /* we've exited the GTK loop, so free all resources */
00007FF770BB13B1 0000000000000000 0000000000000000 0000000000000000  gerbv.exe!__tmainCRTStartup  [C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 321]
00007FF770BB14C6 0000000000000000 0000000000000000 0000000000000000  gerbv.exe!WinMainCRTStartup  [C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 176]
00007FFCCAC47034 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk
00007FFCCB542651 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart
efa commented 3 years ago

my configure command is: $ configure --enable-unit-mm --disable-update-desktop-database --prefix=/d/installer/gerbv-2021-09-06github

ooxi commented 3 years ago

Thank you very much for your effort in reproducing this bug and bringing it to our attention. I can confirm that opening a gvp project file multiple times seems to crash gerbv on Windows (tested using wine).

I'll try to reproduce this on linux since I'm not very familiar with debugging on windows. But crashing inside the scheme allocator does not look like it's a Windows only bug.

Yea this is very easy to reproduce on Ubuntu, too. I personally do not use the Gerbv project files just Gerber and Excellon. I'll try narrowing this down with valgrind.

ooxi commented 3 years ago

Valgrind is reporting a double free before the crash

==9051== Invalid free() / delete / delete[] / realloc()
==9051==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9051==    by 0x122CDE: callbacks_open_activate (callbacks.c:372)
==9051==    by 0x510F801: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x5123813: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512EBBD: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512F0F2: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x4C32FB1: gtk_widget_activate (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B2B12C: gtk_menu_shell_activate_item (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B2B3F8: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B18B9A: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x510F801: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x5122F95: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==  Address 0x90d67b0 is 0 bytes inside a block of size 47 free'd
==9051==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9051==    by 0x51CCC6F: g_slist_foreach (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==9051==    by 0x51CCC9E: g_slist_free_full (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==9051==    by 0x510F801: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x5123813: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512EBBD: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512F0F2: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x4C32FB1: gtk_widget_activate (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B2B12C: gtk_menu_shell_activate_item (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B2B3F8: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B18B9A: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x510F801: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==  Block was alloc'd at
==9051==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9051==    by 0x51B2E98: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==9051==    by 0x51CD153: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==9051==    by 0x4AB563D: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4AB686E: gtk_file_chooser_get_filenames (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x122CCB: callbacks_open_activate (callbacks.c:369)
==9051==    by 0x510F801: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x5123813: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512EBBD: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x512F0F2: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6400.6)
==9051==    by 0x4C32FB1: gtk_widget_activate (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==9051==    by 0x4B2B12C: gtk_menu_shell_activate_item (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)

@eyal0 might this be related https://sourceforge.net/p/gerbv/bugs/256/?

efa commented 3 years ago

I can confirm that opening a gvp project file multiple times seems to crash gerbv on Windows (tested using wine).

did you cross-compile on Linux to Windows using MXE?

Yea this is very easy to reproduce on Ubuntu, too

I cannot confirm this on Debian 10, I never got an exception, but valgrind show:

==8255== Invalid free() / delete / delete[] / realloc()
==8255==    at 0x48369AB: free (vg_replace_malloc.c:530)
==8255==    by 0x48AE093: gerbv_destroy_project (in /usr/lib/x86_64-linux-gnu/libgerbv.so.1.0.9)
==8255==    by 0x1194DC: main (main.c:1113)

and memory leak:

==8255== LEAK SUMMARY:
==8255==    definitely lost: 60,883 bytes in 787 blocks
==8255==    indirectly lost: 136,875 bytes in 3,756 blocks
==8255==      possibly lost: 5,327 bytes in 58 blocks
==8255==    still reachable: 3,723,864 bytes in 56,529 blocks
==8255==                       of which reachable via heuristic:
==8255==                         length64           : 12,648 bytes in 186 blocks
==8255==                         newarray           : 2,384 bytes in 69 blocks

but can depend on a smarter memory allocation, maybe the freed memory are not reused immediately (maybe for the anti-crack random allocation), so no exception. On Windows is deterministic, lot of exception

ooxi commented 3 years ago

did you cross-compile on Linux to Windows using MXE?

I cross compiled on Linux to Windows using mingw64 shipped with Fedora. Since cairo, glib and gtk are already packaged, I just had to switch configure to mingw64-configure.

I did not yet succeed in including dxflib, however.

I cannot confirm this on Debian 10, I never got an exception, but valgrind show:

This is strange. I'm also not entirely certain what causes the crash. Because when using valgrind, I can use the application without crashing, I just get a lot of errors regarding invalid memory access. But without valgrind, Ubuntu core dumps gerbv after opening the second gvp project.

ooxi commented 3 years ago

@efa could you confirm that replacing mainProject->path with a fixed path (like "/tmp") in callbacks.c line 365 hotfixes the crash on Windows, too?

efa commented 3 years ago

on my Linux I tested up to 6 gvp without crash. Will try to put /tmp in callbacks.c and recompile for Win. Will also test the @kitanokitsune patch at line 202: mainProject->path = g_strdup(project_filename);

efa commented 3 years ago

bad news. Both tests fail with same results. I also made a test with both patches together, same result.

I saw that Hiroshi Yoshikawa Sourceforge user: y-hiro and github user: kitanokitsune prosed many patches needed to compile gerbv for Windows without crash: https://github.com/kitanokitsune/gerbv_for_win that was never included in sourceforge sources. Will try also those one

efa commented 3 years ago

bingo, his version is stable on opening gvp files, I tested bith 32 and 64 bit versions. It is based on Sourceforge last commit http://git.geda-project.org/gerbv/tree/?id=b5f1eacd798f327ab319af939f89031db4b7c10a plus his 10 patches, and has github pushes of 18 days ago. More he supply already a Win package with all dependencies, as current 'make install' is quite unsufficient. I tryed the precompiled binaries, and try to compile myself in MinGW64 and packaged like a made for past versions and both are stable. I tryed to compile the sources on Linux too, also there is stable and Valgrind say no double free

efa commented 3 years ago

I also tested the git version of @eyal0 at https://github.com/eyal0/gerbv Compiled on Windows, it crash on first .gvp file opened. Compiled on Linux, work with no crash, but Valgrind show double free like current github

ooxi commented 3 years ago

bad news. Both tests fail with same results. I also made a test with both patches together, same result.

We still have invalid memory access and most likely Windows is stricter about this than Linux :(

bingo, his version is stable on opening gvp files, I tested bith 32 and 64 bit versions.

thats' great news! Did you by any chance happen to know which patches fixed the crashing? #77 Fix double-freeing memory looks promising.

I already tried reaching out to @kitanokitsune, however without luck :(

efa commented 3 years ago

the gerbv/gerbv on github, it is based on Sourceforge last git commit, plus which patches?

efa commented 3 years ago

most likely Windows is stricter about this than Linux :(

I think this is due the fact that MSYS2 supply gcc 10.2, while on Linux most of us still use gcc 8.x

Did you by any chance happen to know which patches fixed the crashing? #77 Fix double-freeing memory looks promising.

I'm just trying to compile with that and/or https://sourceforge.net/p/gerbv/patches/83/

efa commented 3 years ago

patch #83 Crash may occur on opening/saveing files was already applied to gerbv/gerbv patch #77 Fix double-freeing memory was partially applied and appling the missing part do not avoid the crash. Will check what other differences are there.

It would be very useful to know which patches have already been applyed to this gerbv/gerbv repository versus the Sourceforge one

efa commented 3 years ago

well, patch #81 Fix casting pointer to different size integer avoid crash on first .gvp open, while, patch #77 Fix double-freeing memory applying the missing part, avoid crash on next .gvp open

Anyway, seem to me that the other patches applied by @kitanokitsune can be useful, and other from Sourceforge patch list, like Gerber X2 support

efa commented 3 years ago

81 Fix casting pointer to different size integer

https://github.com/gerbv/gerbv/pull/20

efa commented 3 years ago

77 Fix double-freeing memory, the part that was not already applyed

https://github.com/gerbv/gerbv/pull/21

efa commented 3 years ago

those two PR are the minimum to have a gerbv working on Windows, like was release 2.6.2

ooxi commented 3 years ago

Thank you very much @efa for this analysis! The PR CI is currently running and I will then reintegrate your changes :-)

It would be very useful to know which patches have already been applyed to this gerbv/gerbv repository versus the Sourceforge one

This repository is based on the latest commit from git.geda-project.org (see commit b5f1eacd798f327ab319af939f89031db4b7c10a on geda-project and GitHub).

I have not yet applied that many patches since I am not yet knowledgeable enough for applying without the author's support. This is why I am very thankful for both your and @eyal0's support!

But I agree, it would be great if we have a list of already applied patched. I will amend the README with this information :-)

efa commented 3 years ago

The PR CI is currently running and I will then reintegrate your changes :-)

I saw your comment for #20, about uintptr_t used by kitanokitsune to change to size_t, I will propose a new PR with new type for the cast. UPDATE: I saw the prev PR is automatically updated considering my last push on my fork with 'size_t'. Please re-run CI, and maybe merge.

About #21 as now seems CI passed, so can be merged.

efa commented 3 years ago

'size_t' has the same size of 'uintptr_t' used by @kitanokitsune on all 32 and 64-bit systems I know, and it is still unsigned, but it is certainly better for a size like adj=sizeof()

efa commented 3 years ago

Just to be sure, I re-tested the PR20 with size_t also on a Linux 64, and still can open gvp files.

efa commented 3 years ago

do not forget PR https://github.com/gerbv/gerbv/pull/21

ooxi commented 3 years ago

@efa thank you very much for the preparation! I reintegrated both your commits :-) it would be great if you could verify whether or not the issue is now fixed on Windows.

I have verified using valgrind that no more invalid memory access occurs when opening a project

efa commented 3 years ago

Just built for Win32 and Win64, both work as expected opening the 1st and next .gvp files.

I do not understand why you did not merged the PR https://github.com/gerbv/gerbv/pull/21, but created a new patch https://github.com/gerbv/gerbv/pull/24 on your repo (that apparently was different than this), and committed that.

In particular the file on your fork require to patch both: src/callbacks.c src/gerb_file.c

While the files on https://github.com/gerbv/gerbv require to patch only: src/callbacks.c

This is why I wrote the patch from SourceForge patch #77 by Hiroshi Yoshikawa was already partially applyed to https://github.com/gerbv/gerbv

Anyway everything works now.

ooxi commented 3 years ago

Anyway everything works now.

Thank you very much for checking, that everything works now @efa!

Of cause I initially planned to just merge your PRs, however there were merge conflicts between them and I did not know how to clean up commits inside the GitHub GUI (e.g. 66079d92df2ab59ae6f95fae453088020a87fa04 where the commit message seems to be misleading and it uses unsigned long instead of size_t).

I hope you don't think this was an affront against you :-(

efa commented 3 years ago

thats OK, just curios. My PR https://github.com/gerbv/gerbv/pull/21 was composed by three commits on my fork, in those cases you should apply the merge of the three commits. The merge does not have conflicts. Next time I will try to commit a single modification per PR, so it is simpler for all.

I tryed to compile the last sources on Linux, and it work like before, and Valgrind is happy

efa commented 3 years ago

Now Gerbv is stable on Windows too. Anyway I think we should integrate other patches from Sourceforge to enhance the Windows support, I would keep this Issue open

ooxi commented 3 years ago

Anyway I think we should think to integrate other patches from Sourceforge to enhance the Windows support, I would keep this Issue open

If you could help with this, that would be great. I reopened the issue as suggested by you :-)

efa commented 3 years ago

As now the make install while work on Linux/Unix, on MinGW/MSYS/Windows is terribly incomplete, as need to package the GTK and many other libs too for gerbv to run on Windows.

I saw in the sources there is a 'win32' directory, with build/package instructions inside, but to me seems very old instructions. Someone know what is the procedure to generate a self contained 'current' Win package?

If not, I want to add a simple bash script I use to create the gerbv package for my company with all deps (created by ldd) once compiled. This is well tested and work. The part I do not test is the localization, as we use english.

spe-ciellt commented 3 years ago

When I ran the project I had a third party person doing the packaging of Windows releases. I think he used an all Linux toolchain. I don't think there has been any Windows releases since then (actually no release at all, but that is another story). From my perspective you can nuke all old Windows building stuff and start fresh with the latest and greatest. If you already have a functioning system it would be a shame to not use it.

efa commented 3 years ago

I regularly yearly release a gerbv Win version for my company. As now for gerbv I use MinGW/MSYS2 on a real Win10 64 bit, but for other projects and my git repo I also used MXE and OSXcross to cross-generate for Win and macOS on my Debian. Crosscompiling work well but require lot of space on HDD as you need to have many libs version: linux32, linux64, win32, win64, macOS ... tens of gigabytes. Having a real Win10 with license payd by my company, seems me simpler to use MinGW/MSYS2. Will PR the simple script.

efa commented 3 years ago

BTW I'm not a software developer but an hardware engineer. As now my work consist of designing CPU motherboard and image processing card for space application, so I need to know something about software and compilation, at least to low level test my boards.

efa commented 3 years ago

I cross compiled on Linux to Windows using mingw64 shipped with Fedora. Since cairo, glib and gtk are already packaged, I just had to switch configure to mingw64-configure

I'm curious what packages exist for Fedora. Did they supply Windows libraries as DLL to install on Linux as RPM package? Nothing similar exist for Debian, so while I can cross-compile with mingw64-configure, the generated binary miss most of deps and do not start (in Wine or real Win). Or maybe did you statically generated GTK to link all in a single exe? I tryed many times that, but never success.

ooxi commented 2 years ago

I saw in the sources there is a 'win32' directory, with build/package instructions inside, but to me seems very old instructions. Someone know what is the procedure to generate a self contained 'current' Win package?

@efa we already have cross compilation working on CI, it uses mingw64-configure :-) I would love to gerbv.github.io to be the procedure to get a self contained current win package.

Unfortunately I have not yet succeeded in including dxlib.

With regards to the win32 directory, I think we should delete it since it might confuse new users.

I'm curious what packages exist for Fedora. Did they supply Windows libraries as DLL to install on Linux as RPM package? Nothing similar exist for Debian, so while I can cross-compile with mingw64-configure, the generated binary miss most of deps and do not start (in Wine or real Win). Or maybe did you statically generated GTK to link all in a single exe? I tryed many times that, but never success.

Yes, that's exactly right! Fedora provides a couple of libraries for cross compilation together with windows DLLs.