Fix build with wxWidgets 3.3: macOS app bundle, frameworks, and cross-platform compat fixes - #453
Merged
Conversation
wxCFStringRef::AsString() no longer accepts an encoding argument in wxWidgets 3.3. The parameterless overload uses UTF-8 internally, which is correct for all modern macOS versions. This only affects macOS builds (the call site is inside #ifdef __WXMAC__).
cmake: generate a proper aMule.app bundle on macOS with the icon
from platforms/MacOSX/aMule-Xcode/amule.icns and auto-generated
Info.plist. Only the monolithic GUI target gets the bundle;
amuled and other tools remain plain executables.
cmake: link Apple frameworks where needed:
- muleappcore: IOKit + CoreFoundation (PlatformSpecific.cpp
sleep-prevention API, used by all targets that link it)
- amule (GUI): CoreServices + ApplicationServices (LSRegisterURL
for ed2k helper registration)
- amuleweb: CoreServices + ApplicationServices (LSFindApplication
for template directory lookup)
- ed2k: CoreServices (FSFindFolder for app-support path)
ExternalConnector.cpp: fix macOS libedit incompatibility with
GNU readline — rl_readline_name is char* (not const char*) and
rl_completion_entry_function is Function* (not rl_compentry_func_t*)
on macOS. Guarded with #ifdef __WXMAC__ so Linux builds are
unaffected.
TextClient.cpp: move string concatenation outside _() macro — wx
3.3 requires _() to wrap a literal, not a runtime expression.
WebInterface.cpp: drop AsString() encoding parameter (same wx 3.3
fix as amule.cpp in the previous commit).
Tested: all 6 targets (amule, amuled, amulegui, amulecmd, amuleweb,
ed2k) build clean on macOS 26 ARM (wx 3.3.2) and Ubuntu (wx 3.3.2).
got3nks
changed the title
got3nks
changed the title
The wx 3.3.2 release dropped the wxCFStringRef::AsString(wxFontEncoding) overload. Only the no-arg AsString() remains. Two GUI tools still called the old overload and failed to compile: - src/utils/aLinkCreator/src/alcframe.cpp (alc) - src/utils/wxCas/src/wxcascte.cpp (wxcas) Both sites were untouched by the earlier wx 3.3 fixes because the GUI tools aren't in the default build set. Drop the encoding argument. Strings are UTF-8 in wx 3.x, no encoding hint needed.
Both GUI tools use FSFindFolder + CFURLCreateFromFSRef (CoreServices /
CoreFoundation) to locate the user's Application Support directory.
These need -framework CoreServices on the link line, which the CMake
targets were missing, so the linker failed with
Undefined symbols for architecture arm64:
_FSFindFolder, _CFURLCreateFromFSRef, _CFURLCopyFileSystemPath,
_CFRelease
Mirrors the framework linking already present on the amule, amuled,
and ed2k targets.
got3nks
force-pushed
the
fix-mac-wx33-asstring
branch
from
April 21, 2026 15:18
d82ae9c to
116820e
Compare
mrjimenez
pushed a commit
to mrjimenez/amule
that referenced
this pull request
Aug 8, 2026
amule-project#454) On 32-bit targets the throttler's std::atomic<int64_t> needs libatomic (the ops expand to __atomic_*_8 library calls). The availability check used find_library(atomic), which only searches standard filesystem paths. With GCC, libatomic ships inside the compiler's own runtime dir (e.g. .../lib/gcc14/), which isn't on that path, so find_library false-fails and configure aborts -- even though `-latomic` links fine because the GCC driver resolves its internal copy (reported on MacPorts, amule-project#453). Replace find_library with check_library_exists(atomic __atomic_load_8), which links a probe with `-latomic` through the compiler driver. It succeeds wherever the flag actually links -- GCC's internal libatomic or a system libatomic (Clang / distro packages, versioned or not) -- and only errors when the flag genuinely can't link. The 32-bit "require libatomic" decision and the FATAL_ERROR guidance are unchanged; only the availability probe changes. Closes amule-project#453.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes build with wxWidgets 3.3 on both Linux and macOS, adds proper
.appbundle generation on macOS via cmake. All 6 targets (amule,amuled,amulegui,amulecmd,amuleweb,ed2k) now build cleanly on macOS ARM (Tahoe, wx 3.3.2) and Ubuntu (wx 3.3.2).Changes
wx 3.3 API fixes (all platforms)
TextClient.cpp: wx 3.3 requires_()to wrap a string literal, not a runtime expression. This brokeamulecmdon both Linux and macOS. Move the string concatenation outside_():wx 3.3 API fixes (macOS only)
amule.cpp/WebInterface.cpp:wxCFStringRef::AsString()no longer accepts an encoding argument in wx 3.3. Drop the parameter — the parameterless overload uses UTF-8 internally, which is correct for all modern macOS versions. Both call sites are inside#ifdef __WXMAC__, so Linux/Windows are unaffected.macOS readline / libedit fix
ExternalConnector.cpp: macOS ships libedit (not GNU readline). Itsrl_readline_nameischar *(notconst char *) andrl_completion_entry_functionisFunction *(notrl_compentry_func_t *). Added#ifdef __WXMAC__casts so both platforms compile. Linux codepath unchanged.cmake: Apple framework linking
Link required Apple frameworks that were previously missing from cmake (the old Xcode project handled them):
muleappcore:IOKit+CoreFoundation—PlatformSpecific.cppsleep-prevention API, inherited by all targetsamule(GUI):CoreServices+ApplicationServices—LSRegisterURLfor ed2k helperamuleweb:CoreServices+ApplicationServices—LSFindApplicationForInfofor template dired2k:CoreServices—FSFindFolderfor app-support pathcmake: macOS
.appbundleThe monolithic GUI now builds as
aMule.appwith:Info.plist(auto-generated by cmake'sMACOSX_BUNDLEsupport)platforms/MacOSX/aMule-Xcode/amule.icnsbundled intoResources/org.amule.aMuleOnly the GUI target gets the bundle;
amuled,amulecmd, etc. remain plain executables. On Linux/Windows nothing changes.Tested