Linux 2025

[danoli3]

Linux

• Updates for GCC14 / GCC13 / GCC12 / GCC11 / GCC10 (from GCC6 std=c++11)
• C++ now variant to C++23 depending GCC version. 24.04 = GCC14
• Download Script now updated to download correct GCC based on whats installed.
• Performance Boost for Linux apps 400% for correct GCC
• Split Linux64 to -TARGET = Linux - A = 64
• Split allows for all versions of Linux to fall into correct locations (arm64 etc)
• Updated Workflow for updated Linux Libraries
• Fixed Nightly borked

[danoli3]

Removed Gold LD for the moment regarding:
#8239

[danoli3]

@ofTheo yeah the library subpath was being used for the targetarch name in for the makefile in the directory! So with linux/64 it was bugging out. I thought it was line spacing tab stuff.

Makefiles are so sensitive though wow. It looks like maybe the streamer issue just reported is a spaces instead of tabs issue if they had run the code.

  ccache g++ -o bin/linux64_debug  obj/linux/64/Debug/src/ofApp.o obj/linux/64/Debug/src/main.o   ../../../libs/openFrameworksCompiled/lib/linux/64/libopenFrameworksDebug.a  -Wl,-rpath=./libs:./bin/libs:./ -Wl,--as-needed -Wl,--gc-sections -fuse-ld=gold ../../../libs/brotli/lib/linux/64/libbrotlienc.a ../../../libs/brotli/lib/linux/64/libbrotlicommon.a ../../../libs/brotli/lib/linux/64/libbrotlidec.a ../../../libs/fmt/lib/linux/64/libfmt.a ../../../libs/glew/lib/linux/64/libGLEW.a ../../../libs/glfw/lib/linux/64/libglfw3.a ../../../libs/tess2/lib/linux/64/libtess2.a ../../../libs/zlib/lib/linux/64/zlib.a -lgstapp-1.0 -lgstvideo-1.0 -lgstbase-1.0 -lgstreamer-1.0 -ludev -lfontconfig -lfreetype -lsndfile -lopenal -lssl -lcrypto -lcurl -lrtaudio -lpulse-simple -lpulse -pthread -lasound -L/usr/lib64 -lGLEW -lGL -lX11 -lGLU -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lmpg123  -lglut -lX11 -lXrandr -lXxf86vm -lXi -lXcursor -ldl -lpthread -lfreeimage -lpugixml -luriparser
  ../../../libs/openFrameworks/sound/ofOpenALSoundPlayer.cpp:1009: error: undefined reference to 'kiss_fftr_alloc'
  ../../../libs/openFrameworks/sound/ofOpenALSoundPlayer.cpp:1020: error: undefined reference to 'kiss_fftr_alloc'
  ../../../libs/openFrameworks/sound/ofOpenALSoundPlayer.cpp:1065: error: undefined reference to 'kiss_fftr'
  ../../../libs/openFrameworks/sound/ofOpenALSoundPlayer.cpp:1095: error: undefined reference to 'kiss_fftr'
  collect2: error: ld returned 1 exit status

Linking Kiss is missing! Sweet looking into

[ofTheo]

ha yeah!! Spaces vs Tabs was a whole new nightmare - an editor that shows the difference is key there.

[danoli3]

Complete

Ubuntu
24.04.1
LT
Build Success all GCC targets

Ubuntu
22.04.1
LT
Build Success GCC10 (max GCC for 22.04)

[danoli3]

Added a utility pipe to apothecary and just did the same for oF

this will make everything a lot easier to update before the gui stuff is done
./of or ./of.sh
usage following our function names: setup, update
of setup runs any setup scripts if applicable, apt gets etc
of update runs any download libs scripts

currently just targeting auto the platform that it is.
macOS will call default macos
Windows will call the default scripts for vs

This will drop clicks / folder clicks and bash running into 1 open repo in terminal: boom run command

[ofTheo]

Will the old linux64 and linuxarmv6l still work for PG etc?

[ofTheo]

Likewise will libs still get picked up in older addons from lib/linux64

[ofTheo]

looks like older projects with addons in lib/linux64/ might not work based on this?

[danoli3]

Good idea although make file location is a very minimal issue compared to all the std:: upgrades required for older projects... but I've added the beginning on an auto-upgrade script.

this script will automatically replace issue strings in addon_config.mk for Linux.

Called via:
./of upgrade addons
./of upgrade apps

In the future this can also add in std:: replacements. Just requires stop and prompt by user since they need to back up files.
Backup mk files are created and removed only upon user input

[ofTheo]

Upgrade script are always handy, but I think we have to be able to support addons that would be fully compliant up until this PR is merged.

I know its a pain to support two names, but I'd either suggest leaving the current system of linux64, linuxarmv6l or, making sure both linux/64 and linux64 libs get picked up by make files / PG etc.

This feels like the amount it will break, is not worth the conceptual tidiness of having the subfolder approach.

Curious what others think, but I am def nervous as it's the osx / macOS issue again, but with even more platforms.

[danoli3]

Actually all those issues were caused by explicit makefile definitions like this one, when we coded not to at all use them! thanks for reminder ~ these are redundant now. Even the exclude code should be removed and just use actual platform defines.

In fact lets just remove these completely as the projectGenerator figures this out automatically.

Here's a test fully removing these .a explicit:

Xcode:

Make:

Let me test this on native linux see if it just works without this

[dimitre]

I think the optional subfolders will complicate the regex needed by makefiles.
The best is having only one folder depth. If any improvement / disambiguating is needed I suggest using a target triplet as a single folder