Activity for Carlo Bramini
-
Carlo Bramini posted a comment on ticket #1470
The patch
-
[PATCH] Make FileSystemWatcher interface optional
-
It is still not fixed.
-
Recently, I didn't cross compile VICE, but that issue of autoconf is still open at Savannah, so I suspect that this is still valid.
-
This is a (incomplete) duplicate of patch #1295.
-
Thank you for the reply. Replacing all Q_OS_WINDOWS with Q_OS_WIN already fixed the issue on my build. I understand that Qt 5.9 branch is old, but I would like to say that nothing else needed to be changed besides using Q_OS_WIN instead of Q_OS_WINDOWS. Unfortunately, CYGWIN is shipped with Qt-5.9.4, which makes one of the above fixes the only solution. However, I can also provide a patch into my QSynth source package forCYGWIN, for making the build process possible.
-
Cannot compile anymore with QT5
-
All VICE emulators build fine again with SDL1. My executables for Windows 9x/Me/NT run again. Thank you very much.
-
SDL: fix wrong text in description.
-
To tell you the truth, I wouldn't agree with that choice. SDL2 cannot run on so many platforms like SDL1 and there are dozens of builds of VICE that cannot use the latest version of this library.
-
The patch.
-
PRINTER-DRV: fix crash when initializing 1520
-
SDL1UI: HWSCALE support is broken.
-
I think I found the cause of the problem, the bug is here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/arch/sdl/joy.c#l85 The macro is misspelled, it uses USE_SDLUI2 but it must be USE_SDL2UI instead. EDIT: however, fixing joy.c is not enough, all sources including joy.h crash with the same error, so the hack on simulating SDL_JoystickID on SDL1 needs to be moved elsewhere. EDIT2: SDL_JoystickGetDeviceInstanceID is also used, but it is available from SDL2. https://wiki.libsd...
-
I think I found the cause of the problem, the bug is here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/arch/sdl/joy.c#l85 The macro is misspelled, it uses USE_SDLUI2 but it must be USE_SDL2UI instead. EDIT: however, fixing joy.c is not enough, all sources including joy.h crash with the same error, so the hack on simulating SDL_JoystickID on SDL1 needs to be moved elsewhere.
-
I think I found the cause of the problem, the bug is here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/arch/sdl/joy.c#l85 The macro is misspelled, it uses USE_SDLUI2 but it must be USE_SDL2UI instead.
-
SDL1UI: VICE cannot be compiled anymore.
-
Error when comping GTK+3 on MinGW-w64:
-
[PATCH] Cannot build C::B anymore outside the source tree.
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
I really don't know, but it looks like you want to build C::B under CYGWIN? Yes, I'm using bash shell from CYGWIN when building. However, it happens also when you try to build Code::Block under linux with MinGW-w64 cross compiler, same identical issue. The $(EXEEXT) is expected to be used by design in this case, as it is explained into the automake man page linked above. Under Windows and inside C::B, you want to run the make command? I have not understood this sentence, sorry.
-
I really don't know, but it looks like you want to build C::B under CYGWIN? Yes, I'm using bash shell from CYGWIN when building. However, it happens also when you try to build Code::Block under linux with MinGW-w64 cross compiler, same identical issue. The $(EXEEXT) is expected to be used by design in this case, as it is explained into the autoconf man page linked above. Under Windows and inside C::B, you want to run the make command? I have not understood this sentence, sorry.
-
Windows: fix handle leak
-
WIN32: detect target correctly.
-
First part of the patch: src_plugins_contrib.txt Adds -no-undefined to various Makefile.am scripts. In my opinion, this should be done indipendently if the second part of the patch can be accepted or not, otherwise it simply won't build. Second part of the patch: src_src.txt Adds location of convenience libraries to $PATH.
-
This is a solution that seems to work fine for loading all contrib plugins under CYGWIN. It just adds the right path to the $PATH variable, so the place with convenience libraries will be known to the dynamic linker. Ater this change, all plugins are loaded successfully. I made it for CYGWIN but I think that it could be used also for platform::windows, so there won't be the need to place the convenience libraries into the root of the intallation directory anymore. Unfortunately, cross compiling for...
-
This is a solution that seems to work fine for loading all contrib plugins under CYGWIN. It just adds the right path to the $PATH variable, so the place with convenience libraries will be known to the dynamic linker. Ater this change, all plugins are loaded successfully. I made it for CYGWIN but I think that it could be used also for platform::windows, so there won't be the need to place the convenience libraries into the root of the intallation directory anymore. Unfortunately, cross compiling for...
-
The patch.
-
[PATCH] Fix support for parallel jobs on Windows
-
Excuse me, I accidentally pressed the Post button before finishing the ticket and formatting the code lines. The right title in my mind was "Replace hardcoded separators with wxPATH_SEP/wxFILE_SEP_PATH".
-
Replace hardcoded separators with
-
At the moment, I have not a Linux or Mac machine for testing this change, sorry. However, instead of doing static libraries, dynamic libraries could be still created, by leaving everything as it is and by just using -no-undefined instead of -static and writing something like this before PluginManager::LoadPlugin() is called: if (platform::cygwin || platform::windows) { // append to $PATH the directory where these libraries are: // - wxchartctrl // - wxflatnotebook // - wxkwic // - wxmathplot // -...
-
At the moment, I have not a Linux or Mac machine for testing this change, sorry. However, instead of doing static libraries, dynamic libraries could be still created, by leaving everything as it is and by just using -no-undefined instead of -static and writing something like this before PluginManager::LoadPlugin() is called: if (platform::cygwin || platform::windows) { // append to $PATH the directory where these libraries are: // - wxchartctrl // - wxflatnotebook // - wxkwic // - wxmathplot // -...
-
At the moment, I have not a Linux or Mac machine for testing this change, sorry. However, instead of doing static libraries, dynamic libraries could be still created, by leaving everything as it is and by just using -no-undefined instead of -static and writing something like this before PluginManager::LoadPlugin() is called: if (platform::cygwin || platform::windows) { // append to $PATH the directory where these libraries are: // - wxchartctrl // - wxflatnotebook // - wxkwic // - wxmathplot // -...
-
I did some change to the post with the build & installation guide. I added some additional libraries: libfam-devel libboost-devel libhunspell-devel and I added all missing plugins by including option --with-contrib-plugins=all when configuring. Unfortunately, I got a number of these errors: libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified but not all libraries seem to need this option. In my opinion, the -no-undefined flag surely needs to be added...
-
The patch to the contrib plugins.
-
I did some change to the post with the build & installation guide. I added some additional libraries: libfam-devel libboost-devel libhunspell-devel and I added all missing plugins by including option --with-contrib-plugins=all when configuring. Unfortunately, I got a number of these errors: libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified but not all libraries seem to need this option. In my opinion, the -no-undefined flag surely needs to be added...
-
I did some change to the post with the build & installation guide. I added some additional libraries: libfam-devel libboost-devel libhunspell-devel and I added all missing plugins by including option --with-contrib-plugins=all when configuring. Unfortunately, I got a number of these errors: libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified but not all libraries seem to need this option. In my opinion, the -no-undefined flag surely needs to be added...
-
I did some change to the post with the build & installation guide. I added some additional libraries: libfam-devel libboost-devel libhunspell-devel and I added all missing plugins by including option --with-contrib-plugins=all when configuring. Unfortunately, I got a number of these errors: libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified but not all libraries seem to need this option. In my opinion, the -no-undefined flag surely needs to be added...
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
I modified the post according to your description, thank you.
-
Indeed, CYGWIN mimics a UNIX environment, could you give me more details about these missing plugins? I also noticed that C::B does not detect x86_64-w64-mingw32 and i686-w64-mingw32 cross compilers automatically, but I don't know if this is expected to happen or it is not correct .
-
Indeed, CYGWIN mimics a UNIX environment, could you give me more details about these missing plugins? I also noticed that C::B does not detect x86_64-w64-mingw32 and i686-w64-mingw32 cross compiler automatically, but I don't know if this is expected to happen or it is not correct .
-
Actually, CYGWIN provides both GTK+2 and GTK+3. The versions of wxWidgets available on CYGWIN are: - 2.8 available only with GTK+2. - 3.0.5, available for GTK+2 and GTK+3 - 3.1.5, available for GTK+2 and GTK+3 Version 2.8 cannot be used since the minimum requirement for C::B is 3.0 as I can see. At the time of writing, version 3.1.5 cannot be use because it has been compiled without advanced support for regex expressions. So, the only option of wxWidget is version 3.0.5, which can be used with either...
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
You are right, sorry, I forgot to add a "cd .." after bootstrap. Modifying the configure line looks better, one command less to type.
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
This is a guide for building and testing Code::Blocks on CYGWIN from scratch. (1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform: setup_x86_64.exe if you want to use 64-bit environment. (recommended) setup_x86.exe if you want to use 32-bit environment. (2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside. (3) Launch setup utility: for entering to the page for selecting...
-
I wrote a detailed guide with all steps needed for running C::B on CYGWIN. Perhaps, it would be worth to move it also in a wiki page, if you will find it useful.
-
PATCH: main fixes for adding support for CYGWIN. Applying this patch also closes issues #1190 and #1191.
-
PATCH: fix detection for supporting -fPIC option.
-
PATCH: main fixes for adding support for CYGWIN.
-
[PATCH] Support for CYGWIN
-
directx: Add missing config.h include
-
[PATCH] Fix build for audio_directx_out driver
-
Cannot cross-compile anymore: AC_PROG_LEX fails.
-
Fix error when building with FreeRTOS.
-
Diskimage: use archdep_fseeko() instead of fseeko()
-
On Windows when they aren't available (they are using msys2, but not with MSVC 2019), I use _fseeki64()/_ftelli64(). Now the question is: are those winapi functions available for CE/Mobile? Some googling indicates they might not be. Actually, no, they are not available. My port for Windows CE / Mobile / Embedded requires an extra test like this one: #ifdef _WIN32_WCE ... #endif although it would be better that configure script should detect _fseeki64() and _ftelli64() functions too. However, I noticed...
-
On Windows when they aren't available (they are using msys2, but not with MSVC 2019), I use _fseeki64()/_ftelli64(). Now the question is: are those winapi functions available for CE/Mobile? Some googling indicates they might not be. Actually, no, they are not available. My port for Windows CE / Mobile / Embedded requires an extra test like this one: #ifdef _WIN32_WCE ... #endif although it would be better that configure script should detect _fseeki64() and _ftelli64() functions too. However, I noticed...
-
xpmanifest blocks compilation under CYGWIN
-
CYGWIN fails to link libcodeblocks.la because missing -no-undefined.
-
Configure script should test if ZIP utility is available.
-
Thank you, after some debugging I have understood why it is needed to recover the correct case of a file name. It's for limiting the chance that two drives open the same file, because the user can type directly the name rather than selecting it from a list. Actually, it is also better to avoid strcasecmp since the file system can be made case sensitive on user demand (at least, the ones that support the feature). In this case, this issue can be resolved.
-
Normally, it does not happen, but it can happen if it is a foreign platform or the platform does not provide network headers and functions (like an embedded OS): for example, in configure.ac, this is activated by UNIX_NETWORK_HEADERS_PRESENT and UNIX_NETWORK_FUNCS_PRESENT for an UNIX/MacOS machine. On BeOS, this is enabled by BEOS_NETWORK_FUNCS_PRESENT and BEOS_NETWORK_HEADERS_PRESENT. On Windows, RS232NET is always activated by default. I have not found anything else for other Operating Systems...
-
The patch.
-
VICE does not honor both HAVE_RS232DEV and HAVE_RS232NET
-
[WIN32] Simplify archdep_real_path()
-
Array drive_funcs[] could be made const
-
If you will find this idea interesting, this is how I made it.
-
Code for GTK3 ACIA widget could be simplified a lot.
-
[WIN32] Fix bug into archdep_get_runtime_info()
-
Making "sound_device_t" structures to be "const".
-
Make mouse_func_t structures to be const.
-
I compiled successfully. Thank you!
-
Joystick: fix to coding guidelines.
-
Make various snap_module_name[] to be const strings
-
I updated the sources with your changes and now I'm getting these new errors: CCLD x64dtv.exe /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: autostart.o: in function `autostart_tape': /home/Carlo/vice-emu-code/v1_x86_64/src/../../vice/src/autostart.c:1494: undefined reference to `datasette_control' /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: autostart.o: in function `advance_pressplayontape': /home/Carlo/vice-emu-code/v1_x86_64/src/../../vice/src/autostart.c:1020:...
-
I updated the sources with your changes and now I'm getting these new errors: CCLD x64dtv.exe /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: autostart.o: in function `autostart_tape': /home/Carlo/vice-emu-code/v1_x86_64/src/../../vice/src/autostart.c:1494: undefined reference to `datasette_control' /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: autostart.o: in function `advance_pressplayontape': /home/Carlo/vice-emu-code/v1_x86_64/src/../../vice/src/autostart.c:1020:...
-
I suspect that you are compiling for GTK3 and not SDL, so this line saves you: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/c64dtv/c64dtvstubs.c#l34 EDIT: I confirm that compiling for GTK3 works. Tested on CYGWIN.
-
I suspect that you are compiling for GTK3 and not SDL, so this line saves you: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/c64dtv/c64dtvstubs.c#l34
-
I suspect that you are compiling for GTK3 and not SDL, so this line save you: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/c64dtv/c64dtvstubs.c#l34
-
Cannot build VICE anymore.
-
This is an example about what I'm talking about: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/core/ata.c#l53
-
Handle HAVE_FSEEKO only in one place.
-
Excuse me, have you evaluated the chance to use AC_OPENMP provided by autotools? Since the macro provides several variables like OPENMP_CFLAGS, you could easily integrate extra configuration from the command line or integrate additional options if the platform needs them.
-
Use pre-defined directory separator.
-
Yes, the AC_TRY_RUN() has to be executed only if the option is set to auto. Otherwise, have_openmp will be set directly with the vale provided into --with-openmp. This is also my idea.
-
Cannot cross-compile VICE anymore.
-
[WIN32] SetWaitableTimer() doesn't use QueryPerformanceCounter()
-
Here, it works everything fine. I configured it with: configure --enable-silent-rules --without-alsa --prefix=/home/Carlo/inst_vice I had to disable ALSA otherwise the configuration process stops. After doing "make install", I started pulseaudio with: pulseaudio --start Finally, I started xterm and X server with xlaunch tool, I went into my inst_vice/bin directory and I launched x64sc.exe. Audio is working fine. Graphic output is also fine (I attached an image with VICE running into a maximized window)....
-
Here, it works everything fine. I configured it with: configure --enable-silent-rules --without-alsa --prefix=/home/Carlo/inst_vice I had to disable ALSA otherwise the configuration process stops. After doing "make install", I started pulseaudio with: pulseaudio --start Finally, I start xterm and X server with xlaunch tool, I go into my inst_vice directory and I launched x64sc.exe. Audio is working fine. Graphic output is also fine (I attached an image with VICE running into a maximized window)....
-
After applying this fix, VICE can be built and executed on CYGWIN with its X server. EDIT: this is an example of the errors that you get: CC socketdrv.o In file included from /usr/include/w32api/winsock.h:36, from ../../../vice/src/socketdrv/socket-win32-drv.c:30, from ../../../vice/src/socketdrv/socketdrv.c:44: /usr/include/w32api/psdk_inc/_fd_types.h:100:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This can cause runtime problems with W32 sockets" [-Wcpp] 100...
-
After applying this fix, VICE can be built and executed on CYGWIN with its X server.
-
Fix native build for CYGWIN.
-
Make few strings and tables as "const".
-
Hello, I have finally found the cause of the problem and I got a solution. The explanation of the defect is described into this page: https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html In short: - All versions of Windows are "DLL platforms", and DLL are targets for "bin" directory. - On all other "non-DLL platforms", the shared libraries are targets for "lib" directory. This means that: - On DLL platforms: RUNTIME_OUTPUT_DIRECTORY and RUNTIME_OUTPUT_NAME target properties are used....
-
Hello, I have finally found the cause of the problem and I got a solution. The explanation of the defect is described into this page: https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html In short: - All versions of Windows are "DLL platforms", and DLL are targets for "bin" directory. . On all other "non-DLL platforms", the shared libraries are targets for "lib" directory. This means that: - On DLL platforms: RUNTIME_OUTPUT_DIRECTORY and RUNTIME_OUTPUT_NAME target properties are used....
-
Lib.c does not respect USE_VICE_THREAD
1 >