Thread: [Tuxpaint-devel] Started the port to SDL3
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Pere P. i C. <per...@gm...> - 2025-06-29 12:03:20
|
Hi all, About three months ago I started that port, now after the release of 0.9.35 I am continuing it :) The source code is currently inside the sdl3 branch in my personal fork at SourceForge https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/ It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one: https://github.com/sabdul-khabir/SDL3_gfx And needs also SDL3_Pango wich I have working but needs a lot of cleaning before it gets ready for a merge request, I blindly ran some sed scripts that affected tons of files. Sorry Mark :) https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/ After installing them, and the SDL3* libraries that come in my distribution, I am able to compile and run Tux Paint in my box :) Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine. im and labels too but they are not tested hard. I'd really like reviews and tests, below some things that would need help: im subsystem: I don't know the languages we provide im for, so a test about correctness would be welcome. Right Alt do not work in the SDL3 version I have installed, so I've added Left Alt to Thai, even if it was explicitly disabled. Oher languages made use of both, left and right alt, now in my box, only left works. Fill Lineal doesn't work properly on single click inside small circles, without drag, I am currently investigating this... Magic tools: there are plenty of magic tools in the magic/src/WIP_SDL3 directory that are waiting to be ported. Wew, too long message, thanks for reading, and thaks for any help :) Pere |
|
From: Mark K. <mar...@gm...> - 2025-06-30 01:39:15
|
Hi Pere, Thank you for working on this. Can you grant the user `vindaci` access to the sdl3 branch so I can add the macOS changes? Thanks, Mark On Sun, Jun 29, 2025 at 8:03 AM Pere Pujal i Carabantes <per...@gm...> wrote: > Hi all, > > About three months ago I started that port, now after the release of > 0.9.35 I am continuing it :) > > The source code is currently inside the sdl3 branch in my personal fork at > SourceForge > https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/ > > It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've > picked this one: > https://github.com/sabdul-khabir/SDL3_gfx > > And needs also SDL3_Pango wich I have working but needs a lot of cleaning > before it gets ready for a merge request, > I blindly ran some sed scripts that affected tons of files. Sorry Mark :) > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/ > > After installing them, and the SDL3* libraries that come in my > distribution, > I am able to compile and run Tux Paint in my box :) > Painting, lines, shapes, stamps, text, open, save, slideshow, erase and > magic alien seems to work fine. > im and labels too but they are not tested hard. > > I'd really like reviews and tests, below some things that would need help: > > im subsystem: > I don't know the languages we provide im for, so a test about correctness > would be welcome. > Right Alt do not work in the SDL3 version I have installed, so I've added > Left Alt to Thai, even if it was explicitly disabled. > Oher languages made use of both, left and right alt, now in my box, only > left works. > > > Fill Lineal doesn't work properly on single click inside small circles, > without drag, I am currently investigating this... > > > Magic tools: > there are plenty of magic tools in the magic/src/WIP_SDL3 directory that > are waiting to be ported. > > > Wew, too long message, thanks for reading, and thaks for any help :) > Pere > > > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Pere P. i C. <per...@gm...> - 2025-06-30 06:22:54
|
El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure: > Hi Pere, > > Thank you for working on this. Can you grant the user `vindaci` access to the sdl3 branch so I can add the macOS changes? > > Thanks, > Mark I've just added you as developer, please test. Thanks Pere |
|
From: Mark K. <mar...@gm...> - 2025-07-01 01:20:25
|
> I've just added you as developer, please test. It worked! Thank you. On Mon, Jun 30, 2025 at 2:23 AM Pere Pujal i Carabantes <per...@gm...> wrote: > El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure: > > Hi Pere, > > > > Thank you for working on this. Can you grant the user `vindaci` access > to the sdl3 branch so I can add the macOS changes? > > > > Thanks, > > Mark > > I've just added you as developer, please test. > > Thanks > Pere > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Mark K. <mar...@gm...> - 2025-07-02 02:42:00
|
Hi Pere, Patches for the macOS port using SDL3 have been committed to the sdl3 branch of your personal fork. Thanks, Mark On Mon, Jun 30, 2025 at 9:20 PM Mark Kim <mar...@gm...> wrote: > > I've just added you as developer, please test. > > It worked! Thank you. > > > On Mon, Jun 30, 2025 at 2:23 AM Pere Pujal i Carabantes < > per...@gm...> wrote: > >> El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure: >> > Hi Pere, >> > >> > Thank you for working on this. Can you grant the user `vindaci` access >> to the sdl3 branch so I can add the macOS changes? >> > >> > Thanks, >> > Mark >> >> I've just added you as developer, please test. >> >> Thanks >> Pere >> >> >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tux...@li... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >> > |
|
From: Pere P. i C. <per...@gm...> - 2025-07-02 08:37:17
|
I've see them, thanks. Now I am slowly porting the magic tools, one by one. Thanks Pere El dt. 01 de 07 de 2025 a les 22:41 -0400, en/na Mark Kim va escriure: > Hi Pere, > > Patches for the macOS port using SDL3 have been committed to the sdl3 branch of your personal fork. > > Thanks, > Mark |
|
From: Pere P. i C. <per...@gm...> - 2025-07-14 23:53:58
|
El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure: > I've see them, thanks. > > Now I am slowly porting the magic tools, one by one. Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity, can be enabled/disabled with CTRL T for transparency and CTRL W for width. There are some values that may/should? be made available in tuxpaint-config but for now they are set to what works in my system. Still need to decide what to do when the user switches tips to the secondary one, maybe hardcode it to the eraser tool? I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again. If somebody has a spare graphics tablet that can send my way I will be very grateful :) Thanks Pere |
|
From: Bill K. <nb...@so...> - 2025-07-15 13:06:25
|
On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote: > El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure: > > I've see them, thanks. > > > > Now I am slowly porting the magic tools, one by one. > > Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c > > Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity, > can be enabled/disabled with CTRL T for transparency and CTRL W for width. > There are some values that may/should? be made available in tuxpaint-config > but for now they are set to what works in my system. In this case, by "width" you mean "spacing", correct? There's a feature I'd like to add that allows brush sizes to be altered via the UI as well. I feel as though that forthcoming feature would be better served by pressure sensitivity, than the spacing feature. (I admit, I don't actually do much art myself, and rarely with a tablet. It just 'feels' like pressure changing spacing would be confusing.) For now, until we can add the brush sizing feature (or perhaps forever?), I think transparency makes the most sense. And I would definitely want the ability to disable it for users who are not yet familiar/comfortable with pressure (i.e., an option to ignore pressure, and always be 100% opaque). Reporting pressure to Magic Tools probably makes sense, but I really need to sit down and think how & when, and how things should behave when pressure is unavailable. Obviously, right now -- for the past 23 years -- pressure has NOT been available. However, once we start adding pressure sensitivity to existing tools, and adidng new tools that support it, we'll want them all to behave intuitively and sensibly when the input lacks pressure (i.e., a regular mouse, a joystick, the keyboard, or a tablet with pressure disabled). > Still need to decide what to do when the user switches tips to the secondary one, > maybe hardcode it to the eraser tool? This is what I've always imagined. :) See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/ I imagine it could just behave like Tux Paint does when holding the [X] key. From README: Hold the [X] key while clicking for quick access to a small sharp round eraser (not available when the Text or Label tools are selected, when you're in the process of rotating a stamp or shape, or when using an interactive magic tool). Release the mouse to return to your currently-selected tool. Of course, if pressure is enabled, then we'd want the eraser to behave differently depending on the pressure. Right now, Erasers are basically just hard-coded shapes (the old "whiteboard eraser" square, then more recently circles, fuzzy circles, and transparent circles). While somewhat limiting in many ways, this also means we can just go in and code things how we want, for this special stylus version of the [X]-key-held eraser. > I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again. > If somebody has a spare graphics tablet that can send my way I will be very grateful :) I've asked Pere how I can help here. :-) -bill! |
|
From: Pere P. i C. <per...@gm...> - 2025-07-16 00:13:39
|
El dt. 15 de 07 de 2025 a les 14:06 +0100, en/na Bill Kendrick va escriure: > On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote: > > El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure: > > > I've see them, thanks. > > > > > > Now I am slowly porting the magic tools, one by one. > > > > Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c > > > > Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity, > > can be enabled/disabled with CTRL T for transparency and CTRL W for width. > > There are some values that may/should? be made available in tuxpaint-config > > but for now they are set to what works in my system. > > In this case, by "width" you mean "spacing", correct? I mean the size of the brush blit on the canvas, max pressure results in full size, less pressure results in less size. Obviously, I had to _also_ scale spacing according to the size, otherwise the results were incorrect. See the picture of 6 first brushes and the sphere drawing with and without pressure affecting width and transparency. https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250716/pressure_tests.png > There's a feature I'd like to add that allows brush sizes > to be altered via the UI as well. I feel as though that > forthcoming feature would be better served by pressure > sensitivity, than the spacing feature. (I admit, I don't > actually do much art myself, and rarely with a tablet. > It just 'feels' like pressure changing spacing would be > confusing.) If I understand right, this is exactly what I have implemented? well, just the half of what is implemented, the other half is transparency. BTW, I am not happy with transparency, one sees the different blits of the brushes in the line, still investigating... > For now, until we can add the brush sizing feature > (or perhaps forever?), I think transparency makes the most > sense. > > And I would definitely want the ability to disable it for > users who are not yet familiar/comfortable with pressure > (i.e., an option to ignore pressure, and always be 100% opaque). Oh, true, currently it starts always enabled, both for size and for transparency, > > Reporting pressure to Magic Tools probably makes sense, but > I really need to sit down and think how & when, and how things > should behave when pressure is unavailable. That would be also a good addition, I imagine many magic tools could benefit from it. > > Obviously, right now -- for the past 23 years -- pressure has NOT > been available. However, once we start adding pressure sensitivity > to existing tools, and adidng new tools that support it, we'll want > them all to behave intuitively and sensibly when the input lacks > pressure (i.e., a regular mouse, a joystick, the keyboard, or a > tablet with pressure disabled). Yes, of course, most people don't use tablets/pens to draw. BTW, are there any touchscreen that is pressure sensitive? (with finger I mean) > > > > Still need to decide what to do when the user switches tips to the secondary one, > > maybe hardcode it to the eraser tool? > > This is what I've always imagined. :) > See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/ > > I imagine it could just behave like Tux Paint does when holding > the [X] key. From README: > > Hold the [X] key while clicking for quick access to a small sharp round > eraser (not available when the Text or Label tools are selected, when > you're in the process of rotating a stamp or shape, or when using an > interactive magic tool). Release the mouse to return to your > currently-selected tool. > > Of course, if pressure is enabled, then we'd want the eraser > to behave differently depending on the pressure. > > Right now, Erasers are basically just hard-coded shapes (the old > "whiteboard eraser" square, then more recently circles, fuzzy > circles, and transparent circles). While somewhat limiting in > many ways, this also means we can just go in and code things how > we want, for this special stylus version of the [X]-key-held > eraser. Will see what I can do :), my first idea was to implement pressure in the Eraser tool, fully switch to it when switching pen tip, let the user do its stuff, then return to the previous tool when switching the pen again to the main tip. but as you say in the feature request, what should happen if the user is already in the Eraser tool? Oh, wait, I see Krita changing to eraser mode when switching from main tip to secondary one, but doing nothing if already in eraser mode, it continues in eraser mode and do not changes to paint mode when switching again back to the main tip of the pen. Maybe we can do the same... > > > > I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again. > > If somebody has a spare graphics tablet that can send my way I will be very grateful :) > > I've asked Pere how I can help here. :-) Yeah!, Thanks :) Pere > > -bill! > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Pere P. i C. <per...@gm...> - 2025-07-24 17:12:56
|
Hi Bill, and all, El dc. 16 de 07 de 2025 a les 02:13 +0200, en/na Pere Pujal i Carabantes va escriure: > El dt. 15 de 07 de 2025 a les 14:06 +0100, en/na Bill Kendrick va escriure: > > On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote: > > > El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure: > > > > > And I would definitely want the ability to disable it for > > users who are not yet familiar/comfortable with pressure > > (i.e., an option to ignore pressure, and always be 100% opaque). > > Oh, true, currently it starts always enabled, both for size and for transparency, Added the ability to disable pressure, still needs support for command line and config. > > > Reporting pressure to Magic Tools probably makes sense, but > > I really need to sit down and think how & when, and how things > > should behave when pressure is unavailable. > > That would be also a good addition, I imagine many magic tools could benefit from it. > > > > > Still need to decide what to do when the user switches tips to the secondary one, > > > maybe hardcode it to the eraser tool? > > > > This is what I've always imagined. :) > > See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/ > > > > I imagine it could just behave like Tux Paint does when holding > > the [X] key. From README: > > > > Hold the [X] key while clicking for quick access to a small sharp round > > eraser (not available when the Text or Label tools are selected, when > > you're in the process of rotating a stamp or shape, or when using an > > interactive magic tool). Release the mouse to return to your > > currently-selected tool. > > > > Of course, if pressure is enabled, then we'd want the eraser > > to behave differently depending on the pressure. Done in this way. I could not implement the idea I had in mind of fully switching to the Eraser tool when switching pen tips, I could not make SDL detect the switching until the pen were already touching the tablet, and that would be very confusing to users seeing the brush interface and getting the erase results and a sudden change of interface to the eraser one when the pen touches the tablet. I wanted to play with SDL_PenProximityEvents https://wiki.libsdl.org/SDL3/SDL_PenProximityEventbut they perform different than explained in the wiki, see https://github.com/libsdl-org/SDL/issues/12992 and I can't see any info about which pen tip is used. Also tried with SDL_PenMotionEvents https://wiki.libsdl.org/SDL3/SDL_PenMotionEvent but the _first_ time one switches the pen tips, pen_state don't show the eraser state until one touches the tablet with the eraser tip. Later switches go fine, one can detect the pen tip before it touches the tablet, but the first one would be confusing. A report of how are things now: Paint Size seems to work fine with pressure, I see a bug in transparency, the function used to blit scaled brushes changes slightly the brush color with transparency. For example the light grey c0c0c0 changes to bebebe Will see what I can do about it. Eraser Size of erasers works with pressure, transparency is not used, it fully erases to original canvas/starter/background. Maybe should be made transparency also enabled here? A small bug also present in 0.9.34 (35 also?): Ghosts xors appears when CTRL Z - CTRL R. In 0.9.34 you must move the mouse around the canvas when hitting repeteadly CTRL Z - CTRL R They appear about 1/3 of times In the sdl3 version the ghost xors appears more. Pen eraser tip Same behavior as holding X and click and drag the mouse Size works with pressure, transparency is not used. Lines Works with pressure disabled. I can't imagine how to use pressure here. Shapes Works with pressure disabled. Same as above. Magic ToDo? Stamps, text, open, etc Do not need pressure to work, assuming they are fine Command line, config ToDo Thanks for any comments Pere |
|
From: Bill K. <nb...@so...> - 2025-07-25 00:42:49
|
On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote: > Hi all, > > About three months ago I started that port, now after the release of 0.9.35 I am continuing it :) > > The source code is currently inside the sdl3 branch in my personal fork at SourceForge > https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/ > > It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one: > https://github.com/sabdul-khabir/SDL3_gfx > > And needs also SDL3_Pango wich I have working but needs a lot of cleaning > before it gets ready for a merge request, > I blindly ran some sed scripts that affected tons of files. Sorry Mark :) > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/ > > After installing them, and the SDL3* libraries that come in my distribution, > I am able to compile and run Tux Paint in my box :) > Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine. > im and labels too but they are not tested hard. There is not yet a release of SDL3_mixer, so I cloned the repo (https://github.com/libsdl-org/SDL_mixer) but unfortunately cannot build it (`cmake --build build`) due to some compiler errors: [ 3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24: /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly. | ^~ /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’: /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’? 218 | MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers); | ^~~~~~~~~~ | position [... plus more places where it complaints about `position3d` vs `position` ...] If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`), I got a number of errors due to parts of the code trying to use the mixer library (e.g., #include it, or declare variables of type Mix_Chunk). I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project); it's just hard for me to notice them because I _have_ SDL_Mixer (version 2) installed. :-) I'll need to sort that out. Beyond that, I'm also having trouble with SDL3_gfx. When I run `make` to do _anything_, it seems to always show this: Package sdl3-gfx was not found in the pkg-config search path. Perhaps you should add the directory containing `sdl3-gfx.pc' to the PKG_CONFIG_PATH environment variable Package 'sdl3-gfx', required by 'virtual:world', not found Makefile:340: -lSDL3_Mixer failed, no sound for you! Package sdl3-gfx was not found in the pkg-config search path. Perhaps you should add the directory containing `sdl3-gfx.pc' to the PKG_CONFIG_PATH environment variable Package 'sdl3-gfx', required by 'virtual:world', not found make: *** No rule to make target 'nosound'. Stop. And when I get it to compile, and it goes to link, it cannot find `zoomSurface` or `rotozoomSurface`, unsurprisingly: ...Linking Tux Paint... cc -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/local/include -I/usr/include/fribidi -I/usr/include/libxml2 -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND \ -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \ -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3 -lSDL3_image -lSDL3_ttf -lz -lpng16 -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo -lpaper -lfribidi -lxml2 -limagequant -lm /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush': /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface' /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface' /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor': /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface' /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw': /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface' /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale': /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface' /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create': /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface' /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface' /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface' /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface' /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface' /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow collect2: error: ld returned 1 exit status make: *** [Makefile:1258: tuxpaint] Error 1 However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig. I just ended up hard-coding it, for now: SDL_LIBS+=-lSDL3_gfx Finally, the Magic tools all want SDL_Mixer too, so I just dropped "magic-plugins" from Makefile's "all" target, and it built! I can launch Tux Paint, and see the splash screen, but then it seems to freeze. Okay, it's very late so I need to stop for now. -bill! > > I'd really like reviews and tests, below some things that would need help: > > im subsystem: > I don't know the languages we provide im for, so a test about correctness would be welcome. > Right Alt do not work in the SDL3 version I have installed, so I've added Left Alt to Thai, even if it was explicitly disabled. > Oher languages made use of both, left and right alt, now in my box, only left works. > > > Fill Lineal doesn't work properly on single click inside small circles, without drag, I am currently investigating this... > > > Magic tools: > there are plenty of magic tools in the magic/src/WIP_SDL3 directory that are waiting to be ported. > > > Wew, too long message, thanks for reading, and thaks for any help :) > Pere > > > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Pere P. i C. <per...@gm...> - 2025-07-25 07:47:37
|
El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: > On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote: > > Hi all, > > > > About three months ago I started that port, now after the release of 0.9.35 I am continuing it :) > > > > The source code is currently inside the sdl3 branch in my personal fork at SourceForge > > https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/ > > > > It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one: > > https://github.com/sabdul-khabir/SDL3_gfx > > > > And needs also SDL3_Pango wich I have working but needs a lot of cleaning > > before it gets ready for a merge request, > > I blindly ran some sed scripts that affected tons of files. Sorry Mark :) > > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/ > > > > After installing them, and the SDL3* libraries that come in my distribution, > > I am able to compile and run Tux Paint in my box :) > > Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine. > > im and labels too but they are not tested hard. > > There is not yet a release of SDL3_mixer, > Ouch, yes it was missing too, Looking at my sources, I compiled it in March. I don't remember having to do anything special to build it. commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps. > so I cloned the repo > (https://github.com/libsdl-org/SDL_mixer) but unfortunately > cannot build it (`cmake --build build`) due to some compiler > errors: > > [ 3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o > In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24: > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant > 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly. > | ^~ > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’: > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’? > 218 | MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers); > | ^~~~~~~~~~ > | position > [... plus more places where it complaints about `position3d` vs `position` ...] > > > If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`), > I got a number of errors due to parts of the code trying to use the > mixer library (e.g., #include it, or declare variables of type Mix_Chunk). > > I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project); > it's just hard for me to notice them because I _have_ SDL_Mixer (version 2) > installed. :-) I'll need to sort that out. > > > Beyond that, I'm also having trouble with SDL3_gfx. When I run `make` > to do _anything_, it seems to always show this: > > Package sdl3-gfx was not found in the pkg-config search path. > Perhaps you should add the directory containing `sdl3-gfx.pc' > to the PKG_CONFIG_PATH environment variable > Package 'sdl3-gfx', required by 'virtual:world', not found > Makefile:340: -lSDL3_Mixer failed, no sound for you! > Package sdl3-gfx was not found in the pkg-config search path. > Perhaps you should add the directory containing `sdl3-gfx.pc' > to the PKG_CONFIG_PATH environment variable > Package 'sdl3-gfx', required by 'virtual:world', not found > make: *** No rule to make target 'nosound'. Stop. > > And when I get it to compile, and it goes to link, > it cannot find `zoomSurface` or `rotozoomSurface`, > unsurprisingly: > > > ...Linking Tux Paint... > cc -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/local/include -I/usr/include/fribidi -I/usr/include/libxml2 -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND \ > -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \ > -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3 -lSDL3_image -lSDL3_ttf -lz -lpng16 -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo -lpaper -lfribidi -lxml2 -limagequant -lm > /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush': > /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface' > /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface' > /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor': > /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface' > /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw': > /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface' > /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale': > /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface' > /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create': > /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface' > /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface' > /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface' > /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface' > /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface' > /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow > collect2: error: ld returned 1 exit status > make: *** [Makefile:1258: tuxpaint] Error 1 > > However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig. > I just ended up hard-coding it, for now: > > > SDL_LIBS+=-lSDL3_gfx > > Finally, the Magic tools all want SDL_Mixer too, > so I just dropped "magic-plugins" from Makefile's "all" > target, and it built! > > I can launch Tux Paint, and see the splash screen, but > then it seems to freeze. Dropping all magic plugins resulted in a freeze splash screen. Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc when I wanted to concentrate in other stuff. > > Okay, it's very late so I need to stop for now. > > -bill! > |
|
From: Bill K. <nb...@so...> - 2025-07-25 10:40:31
|
On Fri, Jul 25, 2025 at 09:47:22AM +0200, Pere Pujal i Carabantes wrote: > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: <snip> > > I can launch Tux Paint, and see the splash screen, but > > then it seems to freeze. > > Dropping all magic plugins resulted in a freeze splash screen. > Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc > when I wanted to concentrate in other stuff. Ah, another 'upstream' bug, I suppose! :-) -bill! |
|
From: Shin-ichi T. <dol...@wm...> - 2025-07-26 23:42:54
|
Hi! On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote: >El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: >> On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote: >> There is not yet a release of SDL3_mixer, > >Ouch, yes it was missing too, Looking at my sources, I compiled it in March. >I don't remember having to do anything special to build it. >commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps. <... snip ...> On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote: >El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: >> so I cloned the repo >> (https://github.com/libsdl-org/SDL_mixer) but unfortunately >> cannot build it (`cmake --build build`) due to some compiler >> errors: >> >> [ 3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o >> In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24: >> /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant >> 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly. SDL3_mixer seems to be under a very active work in progress. I also once succeeded to build it but currently it fails with the same error bill mentioned. Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898". I will wait for a while until it would be more stable. Just FYI. -- Shin-ichi TOYAMA <dol...@wm...> |
|
From: Pere P. i C. <per...@gm...> - 2025-07-27 09:46:13
|
El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure: > Hi! > > On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote: > > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: > > > On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote: > > > There is not yet a release of SDL3_mixer, > > > > Ouch, yes it was missing too, Looking at my sources, I compiled it in March. > > I don't remember having to do anything special to build it. > > commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps. > > <... snip ...> > > On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote: > > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure: > > > so I cloned the repo > > > (https://github.com/libsdl-org/SDL_mixer) but unfortunately > > > cannot build it (`cmake --build build`) due to some compiler > > > errors: > > > > > > [ 3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o > > > In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24: > > > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant > > > 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly. > > SDL3_mixer seems to be under a very active work in progress. > > I also once succeeded to build it but currently it fails with the same error bill mentioned. > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898". > > I will wait for a while until it would be more stable. > > Just FYI. Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26 builds fine for me. Starting at the root of the source, rm the "build" directory if it has been created before, then: mkdir build && cd build && cmake -S .. -B . && make HTH Pere |
|
From: Bill K. <nb...@so...> - 2025-07-27 10:08:50
|
On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote:
> El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> > Hi!
> >
<snip>
> > > > In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > > > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > > > 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> >
> > SDL3_mixer seems to be under a very active work in progress.
> >
> > I also once succeeded to build it but currently it fails with the same error bill mentioned.
> > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".
That commit has a lot fewer source files. MIX_Track doesn't yet
exist; there's no "SDL_mixer_internal.h". That said, it DID build. :-D
And Tux Paint builds (in its entirety) for me, with only this change
to Makefile
-SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs)
+SDL_LIBS+=-lSDL3_gfx
It knows it's built with SDL3:
kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version
Tux Paint
Version 0.9.36 (2025-07-27)
Built with these options:
SDL version 3.2.18
However, it segfaults after the splash screen appears.
(It was built WITH all magic tools, this time around.)
I'll keep investigating when I can :)
> > I will wait for a while until it would be more stable.
We might need to, hehe.
> > Just FYI.
>
> Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
> builds fine for me.
>
> Starting at the root of the source, rm the "build" directory if it has been created before, then:
> mkdir build && cd build && cmake -S .. -B . && make
That commit continued to not build, due to `position3d` and `position`
differences in the struct described in "SDL_mixer_internal.h", and how
it was used elsewhere in the SDL_mixer sources. (Even after a `git pull`
on "master" branch.)
Strange!
-bill!
|
|
From: Mark K. <mar...@gm...> - 2025-07-27 12:17:59
|
On Sun, Jul 27, 2025 at 6:08 AM Bill Kendrick <nb...@so...> wrote: [snip] > However, it segfaults after the splash screen appears. > (It was built WITH all magic tools, this time around.) > The SDL3 branch of Tux Paint started crashing on macOS, too. The cause appears to be commit 499630757dca284de759b86650879763784a94b8 of magic/src/emitter.c. Reverting this one file to the prior commit allows Tux Paint to run on macOS without crashing once again. Deleting the emitter.dylib shared library also allows Tux Paint to run on macOS again. Can you see if the above workarounds for the macOS build also works for the Linux build? > I'll keep investigating when I can :) > > > > > I will wait for a while until it would be more stable. > > We might need to, hehe. > > > > > Just FYI. > > > > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July > 26 > > builds fine for me. > > > > Starting at the root of the source, rm the "build" directory if it has > been created before, then: > > mkdir build && cd build && cmake -S .. -B . && make > > That commit continued to not build, due to `position3d` and `position` > differences in the struct described in "SDL_mixer_internal.h", and how > it was used elsewhere in the SDL_mixer sources. (Even after a `git pull` > on "master" branch.) > > Strange! > > -bill! > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Pere P. i C. <per...@gm...> - 2025-07-27 14:29:49
|
El dg. 27 de 07 de 2025 a les 11:08 +0100, en/na Bill Kendrick va escriure: > On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote: > > El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure: > > > Hi! > > > > <snip> > > > > > In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24: > > > > > /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant > > > > > 139 | float SDL_ALIGNED(16) position3d[4]; // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly. > > > > > > SDL3_mixer seems to be under a very active work in progress. > > > > > > I also once succeeded to build it but currently it fails with the same error bill mentioned. > > > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898". > > That commit has a lot fewer source files. MIX_Track doesn't yet > exist; there's no "SDL_mixer_internal.h". That said, it DID build. :-D > > And Tux Paint builds (in its entirety) for me, with only this change > to Makefile > > -SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs) > +SDL_LIBS+=-lSDL3_gfx > > It knows it's built with SDL3: > > kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version > > Tux Paint > Version 0.9.36 (2025-07-27) > > Built with these options: > SDL version 3.2.18 > > However, it segfaults after the splash screen appears. > (It was built WITH all magic tools, this time around.) > > I'll keep investigating when I can :) > > > > > I will wait for a while until it would be more stable. > > We might need to, hehe. I agree too. > > > > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26 > > builds fine for me. The SDL3_mixer library builds fine, but after installed it, breaks the Tux Paint build, so Tux Paint would need to be adapted to the changes in the mixer lib. For now, I am going to downgrade the mixer in my box to the 4e9a308a0daa63b6bd492b0ec616f86337500898 commit until more people is able to compile the main branch of SDL3_Mixer. > > > > Starting at the root of the source, rm the "build" directory if it has been created before, then: > > mkdir build && cd build && cmake -S .. -B . && make > > That commit continued to not build, due to `position3d` and `position` > differences in the struct described in "SDL_mixer_internal.h", and how > it was used elsewhere in the SDL_mixer sources. (Even after a `git pull` > on "master" branch.) Strange, could be that a different compiler/make/whatever would not throw errors? It builds here with no complaints. In case of that helps: gcc --version gcc (Debian 14.2.0-19) 14.2.0 make --version GNU Make 4.4.1 ldd --version ldd (Debian GLIBC 2.41-6) 2.41 cmake --version cmake version 3.18.4 HTH Pere |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X