GTK2 port fails to build on macOS (v3.2.2.1) (Issue #23475)
nieder
Trying to build wxGTK on macOS and get the following compile error. This is the input to configure:
./configure --prefix=/sw --libdir=/sw/lib/wxwidgets320-gtk2 --enable-intl --enable-unicode --disable-mediactrl --enable-dependency-tracking --enable-cxx11 --enable-unicode --enable-display --enable-geometry --disable-stl --enable-richtext --with-gtk=2 --with-liblzma --with-libpng --with-libjpeg --with-libtiff --without-sdl --with-opengl --with-libiconv-prefix=/sw --with-macosx-sdk=no --with-macosx-version-min=no GREP=/usr/bin/grep
The same configure command but with --with-cocoa instead of with --with-gtk=2 successfully builds the native library. For comparison, wx @ v3.0.5 successfully built on the same macOS machine using both toolkits.
Description
This is the error:
$ make -w make: Entering directory '/sw/build.build/wxwidgets320-gtk2-3.2.2.1-1.1/wxWidgets-3.2.2.1' /sw/build.build/wxwidgets320-gtk2-3.2.2.1-1.1/wxWidgets-3.2.2.1/bk-deps flag-sort -r g++ -std=gnu++11 -c -o basedll_core_mimetype.o -I/sw/build.build/wxwidgets320-gtk2-3.2.2.1-1.1/wxWidgets-3.2.2.1/lib/wx/include/gtk2-unicode-3.2 -I./include -I/sw/include -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include -I/sw/include/pango-1.0 -I/sw/include/atk-1.0 -I/sw/include/cairo -I/sw/include/freetype2 -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/opt/X11/include -D__WXGTK__ -DWXBUILDING -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -O2 -I/opt/X11/include -I/sw/include -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include -I/sw/include/pango-1.0 -I/sw/include/atk-1.0 -I/sw/include/cairo -I/sw/include/freetype2 -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/gtk-unix-print-2.0 -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -I/sw/include ./src/osx/core/mimetype.cpp In file included from ./src/osx/core/mimetype.cpp:21: In file included from ./include/wx/osx/private.h:4: In file included from ./include/wx/osx/core/private.h:23: ./include/wx/osx/core/cfarray.h:56:14: error: unknown type name 'WX_NSArray' operator WX_NSArray() { return (WX_NSArray) this->get(); } ^ In file included from ./src/osx/core/mimetype.cpp:21: In file included from ./include/wx/osx/private.h:4: ./include/wx/osx/core/private.h:43:22: warning: 'wxOSX_USE_IPHONE' is not defined, evaluates to 0 [-Wundef] #if ( !wxUSE_GUI && !wxOSX_USE_IPHONE ) || wxOSX_USE_COCOA_OR_CARBON ^ ./include/wx/osx/core/private.h:65:48: error: use of undeclared identifier 'NSString'; did you mean 'cString'? WXDLLIMPEXP_BASE wxString wxStringWithNSString(NSString *nsstring); ^~~~~~~~ cString /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/OpenScripting.framework/Headers/ASRegistry.h:212:3: note: 'cString' declared here cString = cStringClass /* old name for cStringClass - can't be used in .r files*/ ^ In file included from ./src/osx/core/mimetype.cpp:21: In file included from ./include/wx/osx/private.h:4: ./include/wx/osx/core/private.h:65:58: error: use of undeclared identifier 'nsstring'; did you mean 'cString'? WXDLLIMPEXP_BASE wxString wxStringWithNSString(NSString *nsstring); ^~~~~~~~ cString /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/OpenScripting.framework/Headers/ASRegistry.h:212:3: note: 'cString' declared here cString = cStringClass /* old name for cStringClass - can't be used in .r files*/ ^ In file included from ./src/osx/core/mimetype.cpp:21: In file included from ./include/wx/osx/private.h:4: ./include/wx/osx/core/private.h:65:27: error: calling a private constructor of class 'wxString' WXDLLIMPEXP_BASE wxString wxStringWithNSString(NSString *nsstring); ^ ./include/wx/string.h:324:3: note: declared private here wxString(int); ^ In file included from ./src/osx/core/mimetype.cpp:21: In file included from ./include/wx/osx/private.h:4: ./include/wx/osx/core/private.h:66:18: error: unknown type name 'NSString'; did you mean 'wxString'? WXDLLIMPEXP_BASE NSString* wxNSStringWithWxString(const wxString &wxstring); ^~~~~~~~ wxString ./include/wx/osx/core/cfstring.h:25:28: note: 'wxString' declared here class WXDLLIMPEXP_FWD_BASE wxString; ^ In file included from ./src/osx/core/mimetype.cpp:21: ./include/wx/osx/private.h:6:5: warning: 'wxOSX_USE_IPHONE' is not defined, evaluates to 0 [-Wundef] #if wxOSX_USE_IPHONE ^ ./include/wx/osx/private.h:8:7: warning: 'wxOSX_USE_COCOA' is not defined, evaluates to 0 [-Wundef] #elif wxOSX_USE_COCOA ^ ./src/osx/core/mimetype.cpp:193:27: warning: 'LSGetExtensionInfo' is deprecated: first deprecated in macOS 10.11 - Use CFURLCopyPathExtension(), -[NSURL pathExtension], or -[NSString pathExtension] instead. [-Wdeprecated-declarations] OSStatus status = LSGetExtensionInfo( wholeString.length, buffer, &periodIndex ); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:206:1: note: 'LSGetExtensionInfo' has been explicitly marked deprecated here LSGetExtensionInfo( ^ 4 warnings and 5 errors generated.
config.log attached
config.log
Platform and version information
- wxWidgets version you are building: 3.2.2.1
- wxWidgets port you are building: wxGTK2
- OS and its version: macOS 10.14.6
- Compiler being used: Apple clang version 11.0.0 (clang-1100.0.33.17)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, I don't even have GTK under Mac, so I can't test this, but would something like
diff --git a/src/osx/core/mimetype.cpp b/src/osx/core/mimetype.cpp index bd6cd3dd1b..0c5399ba3b 100644 --- a/src/osx/core/mimetype.cpp +++ b/src/osx/core/mimetype.cpp @@ -18,7 +18,10 @@ #if wxUSE_MIMETYPE #include "wx/osx/mimetype.h" -#include "wx/osx/private.h" + +#include <CoreFoundation/CoreFoundation.h> +#include <Carbon/Carbon.h> +#include "wx/osx/core/cfstring.h" ///////////////////////////////////////////////////////////////////////////// // Helper functions
help? If yes, I can push this, but I'm afraid this is about as far as I'm ready to go for fixing this because I really don't think that many people use wxGTK under macOS (do you have any statistics about the number of installations of the corresponding Fink package or anything like this by chance?).
Of course, any PRs fixing this would be still welcome in any case.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
nieder
Yes, that change worked for mimetype.cpp. Thanks. There are follow up errors in cfstring.cpp like this:
In file included from ./src/osx/core/cfstring.cpp:22:
./include/wx/osx/core/cfstring.h:34:56: error: unknown type name 'CFStringRef'; did you mean 'wxCFStringRef'?
class WXDLLIMPEXP_BASE wxCFStringRef : public wxCFRef< CFStringRef >
^~~~~~~~~~~
wxCFStringRef
and in uilocale.mm
./src/osx/core/uilocale.mm:230:29: error: no matching function for call to 'AsString'
preferred.push_back(wxCFStringRef::AsString(preferredLangs[j]));
^~~~~~~~~~~~~~~~~~~~~~~
./include/wx/osx/core/cfstring.h:67:14: note: candidate function not viable: no known conversion from 'id' to 'wxFontEncoding' for 1st argument
wxString AsString( wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) const;
^
among a few files. I'll try to see if similarish changes fix them.
If I try to generate a PR, is there some set of #defines that can be used to conditional on the toolkits? I see the following but don't understand the differences:
WXMAC
WXOSX
wxOSX_USE_COCOA
There's also WXGTK, and WXGTK{2,3,4}.
I was trying to conditional the above #include ... patch on #ifdef __WXGTK__, but platform.h seems to wipe that:
I don't have statistics on how many users are using the old wxGTK-3.0.5 vs wxCocoa-3.0.5 for their app gui needs. It was probably more important long ago when many tools were not native ready, but that's less so these days and other toolkits have been impossible to build X11 flavors on macOS for a long time (e.g. Qt and XUL both in 2011). This might be too much effort to 1) port, and 2) maintain.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks for looking at this. I thought this would be the only place with this problem, but if it isn't, perhaps it would be simpler to change the check for __WXMAC__ here https://github.com/wxWidgets/wxWidgets/blob/b4a29beecd4bbaf821fe26fe3b8933c5f97e1d97/include/wx/defs.h#L2716 to #ifdef __DARWIN__ to use it for all ports there.
The situation with preprocessor identifiers under macOS is confusing due to long and winding history which led us to the present day, but they are documented here. I.e. __WXMAC__ and __WXOSX__ are just the same and, confusingly, apply to both macOS and iOS, and wxOSX_USE_COCOA is the same as __WXOSX_COCOA__, i.e. is for macOS only.
In comparison, __WXGTK__ is much simpler: it's always defined for any wxGTK port, while __WXGTKN__ is defined for GTK version N or greater.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
nieder
Changing defs.h to __DARWIN__ does get me much further, but then things fail here (and in a couple other files with the same error:
g++ <many flags> ./src/osx/cocoa/utils_base.mm ./src/osx/cocoa/utils_base.mm:259:30: error: no matching function for call to 'AsString' wxString errorDesc = wxCFStringRef::AsString([error localizedDescription]); ^~~~~~~~~~~~~~~~~~~~~~~ ./include/wx/osx/core/cfstring.h:65:14: note: candidate function not viable: no known conversion from 'NSString *' to 'wxFontEncoding' for 1st argument wxString AsString( wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) const; ^ ./include/wx/osx/core/cfstring.h:67:21: note: candidate function not viable: no known conversion from 'NSString *' to 'CFStringRef' (aka 'const __CFString *') for 1st argument static wxString AsString( CFStringRef ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ; ^ 1 error generated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
One (probably simpler) possibility would be to change #ifndef __WXOSX_IPHONE__ around wxCocoaLaunch() in src/osx/cocoa/utils_base.mm to #ifdef __WXOSX_COCOA__ and do the same in the code calling it in src/unix/utilsunx.cpp.
However I suspect we actually do want to use this function even when building wxGTK for macOS, as launching application bundles should work in the same way from either Cocoa or GTK program. And in this case the proper fix would be to replace #ifdef __WXMAC__ around AsString(WX_NSString) overload declaration in include/wx/osx/core/cfstring.h to something else. I'd probably just guard it by the same __OBJC__, as it seems like this should be accessible whenever using Objective C, but in this case it also needs to be made inline, i.e. the implementation moved from src/osx/core/cfstring.cpp as __OBJC__ is not defined when compiling that C++ file.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
nieder
@vadz Thanks for your help here. Unfortunately, I've hit a snag and I'm not sure how much time I should throw at this when I'm not sure how many will benefit. Maybe someone more versed in the code could look at it, but for now I'going to stop working on it Below is the patch that I've used so far, but it is far from creating a working build under macOS with the GTK+2 toolkit. If this ever works, some of the changes might need to be surrounded by #ifdefs to protect other toolkits that are currently working, but I did not get that far in preparing this.
Thank you for your help in getting this far.
diff -ruNpw -U8 wxWidgets-3.2.2.1-orig/include/wx/defs.h wxWidgets-3.2.2.1/include/wx/defs.h --- wxWidgets-3.2.2.1-orig/include/wx/defs.h 2023-02-13 08:45:39.000000000 -0600 +++ wxWidgets-3.2.2.1/include/wx/defs.h 2023-06-12 21:16:32.000000000 -0500 @@ -2781,17 +2781,17 @@ typedef int (* LINKAGEMODE wxListIterate /* --------------------------------------------------------------------------- */ #ifdef __DARWIN__ #define DECLARE_WXOSX_OPAQUE_CFREF( name ) typedef struct __##name* name##Ref; #define DECLARE_WXOSX_OPAQUE_CONST_CFREF( name ) typedef const struct __##name* name##Ref; #endif -#ifdef __WXMAC__ +#ifdef __DARWIN__ #define WX_OPAQUE_TYPE( name ) struct wxOpaque##name typedef void* WXHCURSOR; typedef void* WXRECTPTR; typedef void* WXPOINTPTR; typedef void* WXHWND; typedef void* WXEVENTREF; diff -ruNpw -U8 wxWidgets-3.2.2.1-orig/include/wx/osx/core/cfstring.h wxWidgets-3.2.2.1/include/wx/osx/core/cfstring.h --- wxWidgets-3.2.2.1-orig/include/wx/osx/core/cfstring.h 2023-02-13 08:45:39.000000000 -0600 +++ wxWidgets-3.2.2.1/include/wx/osx/core/cfstring.h 2023-06-12 21:24:12.000000000 -0500 @@ -61,17 +61,17 @@ public: ~wxCFStringRef() { } wxString AsString( wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) const; static wxString AsString( CFStringRef ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ; static wxString AsStringWithNormalizationFormC( CFStringRef ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ; -#ifdef __WXMAC__ +#ifdef __OBJC__ static wxString AsString( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ; static wxString AsStringWithNormalizationFormC( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ; #endif #ifdef __OBJC__ WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; } #endif private: } ; diff -ruNpw -U8 wxWidgets-3.2.2.1-orig/src/osx/core/evtloop_cf.cpp wxWidgets-3.2.2.1/src/osx/core/evtloop_cf.cpp --- wxWidgets-3.2.2.1-orig/src/osx/core/evtloop_cf.cpp 2023-02-13 08:45:39.000000000 -0600 +++ wxWidgets-3.2.2.1/src/osx/core/evtloop_cf.cpp 2023-06-12 21:19:34.000000000 -0500 @@ -26,17 +26,19 @@ #include "wx/log.h" #include "wx/app.h" #endif #include "wx/evtloopsrc.h" #include "wx/scopedptr.h" -#include "wx/osx/private.h"
+#include <CoreFoundation/CoreFoundation.h> +#include <Carbon/Carbon.h> +#include "wx/osx/core/cfstring.h"
#include "wx/osx/core/cfref.h"
#include "wx/thread.h"
#if wxUSE_GUI
#include "wx/nonownedwnd.h"
#endif
#include <CoreFoundation/CFSocket.h>
diff -ruNpw -U8 wxWidgets-3.2.2.1-orig/src/osx/core/mimetype.cpp wxWidgets-3.2.2.1/src/osx/core/mimetype.cpp
--- wxWidgets-3.2.2.1-orig/src/osx/core/mimetype.cpp 2023-02-13 08:45:39.000000000 -0600
+++ wxWidgets-3.2.2.1/src/osx/core/mimetype.cpp 2023-06-12 21:15:03.000000000 -0500
@@ -13,17 +13,19 @@
#ifndef WX_PRECOMP
#include "wx/defs.h"
#endif
#if wxUSE_MIMETYPE
#include "wx/osx/mimetype.h"
-#include "wx/osx/private.h"
+#include <CoreFoundation/CoreFoundation.h> +#include <Carbon/Carbon.h> +#include "wx/osx/core/cfstring.h"
///////////////////////////////////////////////////////////////////////////// // Helper functions ///////////////////////////////////////////////////////////////////////////// // Read a string or array of strings from a CFDictionary for a given key // Return an empty list on error
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@nieder Did you happen to have it fixed? I am interested in wxGTK on macOS, and it was working before (with 3.0 branch).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
nieder
@barracuda156 the patch above is as far as I got, and there were still some things not compiling, but it's been a year since I looked at any of this. If I remember correctly, there were discrepancies in some places about what meant macOS (the underlying system), vs macOS (the GUI), assuming they would always be the same (sensible assumption).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@nieder I tried using the patch, it does not work (unsurprisingly, since it did not work before either).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
One (probably simpler) possibility would be to change
#ifndef __WXOSX_IPHONE__aroundwxCocoaLaunch()insrc/osx/cocoa/utils_base.mmto#ifdef __WXOSX_COCOA__and do the same in the code calling it insrc/unix/utilsunx.cpp.However I suspect we actually do want to use this function even when building wxGTK for macOS, as launching application bundles should work in the same way from either Cocoa or GTK program. And in this case the proper fix would be to replace
#ifdef __WXMAC__aroundAsString(WX_NSString)overload declaration ininclude/wx/osx/core/cfstring.hto something else. I'd probably just guard it by the same__OBJC__, as it seems like this should be accessible whenever using Objective C, but in this case it also needs to be made inline, i.e. the implementation moved fromsrc/osx/core/cfstring.cppas__OBJC__is not defined when compiling that C++ file.
@vadz The first option fails, since that function is used elsewhere. Could you suggest how to make it inline correctly?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
What might have broken everything is removal of wxOSX_USE_COCOA_OR_IPHONE. For example:
vs
So now what is under __OBJC__ gonna be used for ObjC files, some of which are still included in GTK build. From looks of things it is wrong (given that 3.0 branch works fine with GTK).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, I really can't dive into this now, but it's not clear why wouldn't using __OBJC__ around the functions not available in wxGTK build work?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Sorry, I really can't dive into this now, but it's not clear why wouldn't using
__OBJC__around the functions not available in wxGTK build work?
This is only a suggestion, I do not know for the fact. I suppose that __OBJC__ will be defined when compiling .mm files or maybe even generally for Apple Clang (i.e. will evaluate as true with GTK build at least for ObjC sources), while wxOSX_USE_COCOA_OR_IPHONE will not evaluate as true for a GTK build. If this is correct, we get different outcomes, obviously.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
__OBJC__ is defined when compiling Objective-C or Obj-C++ code (files with .m or .mm extensions).
And what I suggested was to change the existing preprocessor guards to use it instead, so it's available to any Objective-C code, whether it's being compiled as part of wxGTK or wxOSX.
Actually, in non-monolithic build (default), this code is compiled as part of wxBase and so should be the same independently of the GUI toolkit used by wxCore.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Changing a macro to __OBJC__ works for that file, but the build fails a bit further on some Mac-specific stuff.
In principle, I think, the closer GTK build on macOS can be made to the same on Linux/BSD, the better (since that will improve compatibility), but I have no idea what parts of Cocoa code are strictly required and what are optional and thus could be excluded.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Just for the record, this is what I get when applying the patch from #23475 (comment) as-is:
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/bk-deps /usr/bin/clang++ -std=gnu++11 -c -o basedll_core_uilocale.o -I/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/lib/wx/include/gtk3-unicode-3.2 -I../include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -D_FILE_OFFSET_BITS=64 -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/cairo -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/atk-1.0 -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -D__WXGTK__ -DWXBUILDING -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -std=gnu++11 -Wno-deprecated-declarations -fvisibility=hidden -fvisibility-inlines-hidden ../src/osx/core/uilocale.mm
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/bk-deps /usr/bin/clang++ -std=gnu++11 -c -o basedll_fdiodispatcher.o -I/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/lib/wx/include/gtk3-unicode-3.2 -I../include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -D_FILE_OFFSET_BITS=64 -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/cairo -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/atk-1.0 -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -D__WXGTK__ -DWXBUILDING -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/gtk-3.0/unix-print -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/atk-1.0 -I/opt/local/include/gdk-pixbuf-2.0 -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 ../src/common/fdiodispatcher.cpp
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/bk-deps /usr/bin/clang++ -std=gnu++11 -c -o basedll_selectdispatcher.o -I/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/lib/wx/include/gtk3-unicode-3.2 -I../include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -D_FILE_OFFSET_BITS=64 -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/cairo -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/atk-1.0 -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -D__WXGTK__ -DWXBUILDING -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/gtk-3.0/unix-print -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/atk-1.0 -I/opt/local/include/gdk-pixbuf-2.0 -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 ../src/common/selectdispatcher.cpp
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:45:19: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
wxCFStringRef(WX_NSString ref)
^~~~~~~~~~~
NSString
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/objc/NSObject.h:13:8: note: 'NSString' declared here
@class NSString, NSMethodSignature, NSInvocation;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:45:31: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
wxCFStringRef(WX_NSString ref)
^
*
../include/wx/osx/core/cfstring.h:70:31: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
static wxString AsString( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^~~~~~~~~~~
NSString
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/objc/NSObject.h:13:8: note: 'NSString' declared here
@class NSString, NSMethodSignature, NSInvocation;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:70:43: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
static wxString AsString( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^
*
../include/wx/osx/core/cfstring.h:71:53: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
static wxString AsStringWithNormalizationFormC( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^~~~~~~~~~~
NSString
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/objc/NSObject.h:13:8: note: 'NSString' declared here
@class NSString, NSMethodSignature, NSInvocation;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:71:65: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
static wxString AsStringWithNormalizationFormC( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^
*
../include/wx/osx/core/cfstring.h:74:5: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~
NSString
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/objc/NSObject.h:13:8: note: 'NSString' declared here
@class NSString, NSMethodSignature, NSInvocation;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:74:5: error: interface type 'NSString' cannot be returned by value; did you forget * in 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^
*
../include/wx/osx/core/cfstring.h:74:60: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~
NSString
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/objc/NSObject.h:13:8: note: 'NSString' declared here
@class NSString, NSMethodSignature, NSInvocation;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:21:
../include/wx/osx/core/cfstring.h:74:45: error: C-style cast from 'CFStringRef' (aka 'const __CFString *') to 'NSString' is not allowed
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:23:
../include/wx/osx/core/cfarray.h:56:14: error: unknown type name 'WX_NSArray'; did you mean 'NSArray'?
operator WX_NSArray() { return (WX_NSArray) this->get(); }
^~~~~~~~~~
NSArray
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:258:8: note: 'NSArray' declared here
@class NSArray;
^
In file included from ../src/osx/cocoa/utils_base.mm:24:
In file included from ../include/wx/osx/private.h:4:
In file included from ../include/wx/osx/core/private.h:23:
../include/wx/osx/core/cfarray.h:56:14: error: interface type 'NSArray' cannot be returned by value; did you forget * in 'NSArray'?
operator WX_NSArray() { return (WX_NSArray) this->get(); }
^
*
../include/wx/osx/core/cfarray.h:56:5: error: cannot specify any part of a return type in the declaration of a conversion function; put the complete type after 'operator'
operator WX_NSArray() { return (WX_NSArray) this->get(); }
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:45:19: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
wxCFStringRef(WX_NSString ref)
^~~~~~~~~~~
NSString
../include/wx/defs.h:2845:8: note: 'NSString' declared here
@class NSString;
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:45:31: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
wxCFStringRef(WX_NSString ref)
^
*
../include/wx/osx/core/cfstring.h:70:31: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
static wxString AsString( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^~~~~~~~~~~
NSString
../include/wx/defs.h:2845:8: note: 'NSString' declared here
@class NSString;
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:70:43: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
static wxString AsString( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^
*
../include/wx/osx/core/cfstring.h:71:53: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
static wxString AsStringWithNormalizationFormC( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^~~~~~~~~~~
NSString
../include/wx/defs.h:2845:8: note: 'NSString' declared here
@class NSString;
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:71:65: error: interface type 'NSString' cannot be passed by value; did you forget * in 'NSString'?
static wxString AsStringWithNormalizationFormC( WX_NSString ref, wxFontEncoding encoding = wxFONTENCODING_DEFAULT ) ;
^
*
../include/wx/osx/core/cfstring.h:74:5: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~
NSString
../include/wx/defs.h:2845:8: note: 'NSString' declared here
@class NSString;
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:74:5: error: interface type 'NSString' cannot be returned by value; did you forget * in 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^
*
../include/wx/osx/core/cfstring.h:74:60: error: unknown type name 'WX_NSString'; did you mean 'NSString'?
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~
NSString
../include/wx/defs.h:2845:8: note: 'NSString' declared here
@class NSString;
^
In file included from ../src/osx/core/uilocale.mm:28:
../include/wx/osx/core/cfstring.h:74:45: error: C-style cast from 'CFStringRef' (aka 'const __CFString *') to 'NSString' is not allowed
WX_NSString AsNSString() const { return (WX_OSX_BRIDGE WX_NSString)(CFStringRef) *this; }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/osx/cocoa/utils_base.mm:222:5: error: unknown type name 'NSWorkspace'
NSWorkspace *ws = [NSWorkspace sharedWorkspace];
^
../src/osx/cocoa/utils_base.mm:222:24: error: use of undeclared identifier 'NSWorkspace'
NSWorkspace *ws = [NSWorkspace sharedWorkspace];
^
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/bk-deps /usr/bin/clang++ -std=gnu++11 -c -o basedll_appunix.o -I/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxWidgets-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/build/lib/wx/include/gtk3-unicode-3.2 -I../include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -D_FILE_OFFSET_BITS=64 -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/cairo -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/atk-1.0 -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -D__WXGTK__ -DWXBUILDING -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -dynamic -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/fribidi -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/gtk-3.0/unix-print -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/gio-unix-2.0 -I/opt/local/include/atk-1.0 -I/opt/local/include/gdk-pixbuf-2.0 -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 ../src/unix/appunix.cpp
../src/osx/cocoa/utils_base.mm:225:5: error: unknown type name 'NSRunningApplication'
NSRunningApplication *app = nil;
^
10 errors generated.
make: *** [basedll_core_uilocale.o] Error 1
make: *** Waiting for unfinished jobs....
../src/osx/cocoa/utils_base.mm:229:28: error: use of undeclared identifier 'NSWorkspaceLaunchAsync'
options:NSWorkspaceLaunchAsync
^
../src/osx/cocoa/utils_base.mm:236:42: error: use of undeclared identifier 'NSWorkspaceLaunchAsync'
options:NSWorkspaceLaunchAsync
^
18 errors generated.
make: *** [basedll_utils_base.o] Error 1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Again, sorry, I really can't spend any time on this myself, but you need to take the errors one by one as there is a cascade of them. The first one, about WX_NSString not being defined, already explains most of them, probably. And to fix it, it either has to be defined for any Obj-C code in wx/defs.h, i.e. #if defined(__WXMAC__) there needs to be changed to #if defined(__WXMAC) || defined(__OBJC__), or, maybe simpler, the code in include/wx/osx/core/cfstring.h shouldn't use it at all: anything inside #ifdef __OBJC__ can use NSString directly, WX_NSString is only useful for not Obj-C code.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz Thank you very much, I will try your suggestions.
I really can't spend any time on this myself
This is perfectly understandable, and please feel free not to respond in the issue until it is convenient.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
So I kinda got it to build, but something needs to be adjusted with the patches, since after I use wxgtk-3.2 to build some app (which works fine), it fails to launch with:
08:07:24: Error: Unable to initialize GTK+, is DISPLAY set properly?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
undeadindustries
@barracuda156 Do me a favor? When this bug is fixed, mind summarizing what anyone looking to compile on MacOS + gtk should do? It's a long thread to follow. I'll be excited when this is fixed. Glad to see some momentum on it!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz Ok, I just forgot that I had no xserver installed on this machine LOL
So there is a partial success then. I was able to build this port, and it seems to work normally:
svacchanda@Sergeys-MacBook-Air ~ % otool -L /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor
/Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor:
/opt/local/lib/libomp/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 64.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 2420.0.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_qa-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/lib/libexpat.1.dylib (compatibility version 11.0.0, current version 11.2.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.0)
On the other hand, FileZilla crashes, complaining about a missing symbol.
So it is certainly not working correctly yet, but it is somewhat functional.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Please make a PR with your changes so that they could be applied. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Please make a PR with your changes so that they could be applied. TIA!
In a couple of days, I need to review what I have, find out why FileZilla fails to launch (it works with wxGTK-3.0) and hopefully reproduce the build on powerpc (Cocoa is broken there, but GTK works fine).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Catalina gave me a meaningful error with FileZilla:
svacchanda@Sergeys-Mini ~ % filezilla
Reading locale option from /Users/svacchanda/.config/filezilla/filezilla.xml
dyld: lazy symbol binding failed: Symbol not found: __ZN13wxCFStringRef8AsStringEP8NSString14wxFontEncoding
Referenced from: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib
Expected in: flat namespace
dyld: Symbol not found: __ZN13wxCFStringRef8AsStringEP8NSString14wxFontEncoding
Referenced from: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib
Expected in: flat namespace
zsh: abort filezilla
Now it can be addressed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
This is wxCFStringRef::AsString(NSString*, wxFontEncoding), which is normally defined in src/osx/core/cfstring.cpp, please check why it isn't getting defined there.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz Yeah, I will look into that.
In general, anything reported in this thread in relation to my GTK-based build should not be considered automatically a bug in the source, since it can well be a bug in patches applied.
And once I have a version which works for filezilla (I think it is a reasonably good test), we will still need to review whether fixes are actually optimal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
This is
wxCFStringRef::AsString(NSString*, wxFontEncoding), which is normally defined insrc/osx/core/cfstring.cpp, please check why it isn't getting defined there.
I don’t think I did anything in my patches to this on purpose, but I guess it could be a result of something did not working well between master and 3.2.5. There were some changes specifically to cfstring which are not in 3.2.5 (which I was building).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Sorry, I don't even have GTK under Mac, so I can't test this
Just in case, if anyone would want to, for any reasonably recent macOS installing GTK is as easy as sudo port install gtk3 (or gtk2, or gtk4). That should install everything pre-built.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz I have fixed it :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
FileZilla built against wxGTK 3.2
F4598A47-BA31-4B38-889F-01A72416250A.jpeg (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz Is it an expected behavior that --without-urlsession does not disable urlsession? The code was introduced in 152e160 but presently that option does not exist, there is only this:
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/configure#L2390
Using that flag did not prevent related files from compiling.
For the context: I wanna minimize patching to support legacy macOS (locally, not planning to try upstreaming that), since those will be huge and hard to rebase, so I rather disable anything broken via configure, if that is possible.
As of now, uilocale is problematic, and there are issues with urlsession and stdpaths. stdpaths have a straightforward configure option, not sure about the other two.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
I have built it on 10.6 powerpc now, though disabling stdpaths, webrequest (because disabling only urlsession did not work) and cutting out uilocale. It is not properly functional yet, and likely not everything needs to be disabled of the above (at least stdpaths apparently had a compatible implementation earlier, which can be restored), so it needs more work.
I could not try Filezilla rightaway, since it wants --enable-printfposparam, and for w/e reason it was disabled by default; I will probably postpone rebuilding wxGTK so that I can add some fixes and reduce disabling.
diff-pdf failed to link against my new library (this is on 10.6, not 14.5):
CXXLD diff-pdf
Undefined symbols:
"__ZThn420_NK10wxVListBox14OnGetRowHeightEm", referenced from:
__ZTV6Gutter in diff_pdf-gutter.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
make: *** [diff-pdf] Error 1
Looks trivial, should be fixable. (By the way, I did not try it on Sonoma, maybe it also fails.)
And removed locale causes trouble, though I did not clean up sources from it, just removed from Makefile. So something expects it to be present.
36-25% rawproc
dyld: lazy symbol binding failed: Symbol not found: __ZN10wxUILocale10GetCurrentEv
Referenced from: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib
Expected in: dynamic lookup
dyld: Symbol not found: __ZN10wxUILocale10GetCurrentEv
Referenced from: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib
Expected in: dynamic lookup
But at this point I think it should not be too hard overall. Whether we get a meaningful benefit over 3.0 on legacy systems is another question.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz When you have a bit of time, please take a look.
Here is the branch which seems to work fine on Sonoma / aarch64: https://github.com/barracuda156/wxWidgets/commits/v3.2.5-gtk
(Disclaimer: most likely some code is wrong here, and adjustments were made on the go, i.e. I did not try every possible combination of tweaks. Some may not be really required. I can only say that this builds for me and I can use it to build something else, which is then confirmed to be functional.
Also, this issue is unresolved, and the commit intending to fix it does not have an effect. I had to copy the header manually into its supposed location.)
Not making PR yet, since I don’t think it is optimal way to fix the build, and as of now IRL testing was minimal.
What can we improve / change / drop?
P. S. As for support for earlier macOS, I think it will be problematic to make needed fixes in a neat way, since substantial amount of code has to be restored to its working versions. Technically it is trivial, there are AvailabilityMacros, but it is a lot of work for me and perhaps a burden to maintain for others.
Provided I get a working version on 10.6, I will make a branch with the fixes (possibly it will be available via MacPorts). We could also make a separate branch here (wxGTK-3.2-compat or smth), if it is acceptable, without any commitment to further updates for it. Obviously, it can only be GTK-based. Cocoa is hopeless.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I think it would be worth making a PR with the fixes for building wxGTK under currently supported versions (macOS 10.10+), it would make it easier to see what has been changed and comment on the changes if necessary.
As for 10.6 support, I'm afraid this is indeed hopeless and you'd have to maintain a branch with these changes yourself, we don't have any resources for doing this and we're much more interested in wxOSX under Mac anyhow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz I will deal with this over the weekend.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
CMake build does not check the header presence and does not provide configure option for joystick, which leads to this with GTK build:
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_graphics_wxgtk-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/src/unix/joystick.cpp:26:10: fatal error: 'linux/joystick.h' file not found
#include <linux/joystick.h>
^~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [libs/core/CMakeFiles/wxcore.dir/__/__/__/__/src/unix/joystick.cpp.o] Error 1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
It has wxUSE_JOYSTICK and a check, but it excludes APPLE. Maybe it should be AND UNIX?
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/build/cmake/setup.cmake#L395-L401
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@MaartenBent I do not know if GTK on macOS can support native or generic joystick support, but in any case we should not use Linux headers. Perhaps makefiles build just disabled it, so I did not face the issue when building with make.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
For instance, CMake has these files as Cocoa-specific:
set(BASE_AND_GUI_OSX_COCOA_SRC
src/osx/cocoa/utils.mm
src/osx/cocoa/power.mm
src/osx/volume.mm
)
While makefile has those in ALL_BASE_SOURCES.
In this instance it looks like CMake build is broken, makefile is correct.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
ALL_BASE_SOURCES is used for creating the distribution package, not when building.
The makefile is generated from files.bkl which has the same sections as files.cmake, which are both generated from build/files. So there is no difference there.
This must be related to build options, likely wxUSE_FSVOLUME. Did you disable this with configure but not with CMake?
Both CMake and configure only inlude those files when the toolkit is COCOA, not when the toolkit is GTK:
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/build/cmake/lib/base/CMakeLists.txt#L18-L20
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/build/bakefiles/files.bkl#L3167-L3169
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
Maybe the problem is CMake defining __WXOSX__ and __WXMAC__ for any toolkit on macOS, while configure only does this when the toolkit is COCOA:
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/build/cmake/toolkit.cmake#L146-L148
https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/configure.ac#L3146-L3151
Try changing the first one to if(wxBUILD_TOOLKIT MATCHES "osx_cocoa")
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Maybe the problem is CMake defining WXOSX and WXMAC for any toolkit on macOS, while configure only does this when the toolkit is COCOA:
This I have already fixed locally, issue is something else.
Thank you for the hints, I will try sorting this out. (I thought that using CMake will make it easier for me to fix the build for legacy macOS, so far does not seem so.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@MaartenBent Looks like what differed was that I used to pass -undefined dynamic_lookup with makefiles build but did not do it with CMake. I have added it back, and the build succeeds.
This is a pretty standard option for linking on macOS. It looks like it is needed, but build system does not use it for some reason.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Hmm, while makefiles build did not install one required header, CMake build installs literally all headers, including completely unnecessary ones.
There are also two other issues:
- CMake installs libraries with 0.0.0 version:
---> Scanning binaries for linking errors
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Could not open /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_qa-3.2.0.2.3.dylib: Error opening or reading file (referenced from /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor)
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /Applications/MacPorts/wxHexEditor.app/Contents/MacOS/wxHexEditor requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_propgrid-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_propgrid-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-exif requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_propgrid-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-img requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_propgrid-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/rawproc-wxcmd requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_net-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_html-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/mediainfo-gui requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/filezilla requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/filezilla requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu_xml-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/filezilla requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/filezilla requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_xrc-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/filezilla requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_aui-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/diff-pdf requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_baseu-3.2.0.2.3.dylib provides version 0.0.0
Incompatible library version: /opt/local/bin/diff-pdf requires version 3.0.0 or later, but /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.2.0.2.3.dylib provides version 0.0.0
(here these ports were built with wxGTK built itself with makefile, now I rebuilt it with CMake, and linking broken).
- CMake installs with wrong paths to dylibs, ignoring prefix (makefiles did it correctly with no manual adjustment):
Could not open /opt/local/lib/libwx_baseu-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/bin/wxrc-3.2)
Could not open /opt/local/lib/libwx_baseu_xml-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/bin/wxrc-3.2)
Could not open /opt/local/lib/libwx_gtk3u_core-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_adv-3.2.0.2.3.dylib)
Could not open /opt/local/lib/libwx_gtk3u_html-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_richtext-3.2.0.2.3.dylib)
I.e. CMake installs correctly into CMAKE_INSTALL_PREFIX which was passed to the build, but bakes in paths to a generic MacPorts prefix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@MaartenBent @vadz Compatibility version of libs set to 0.0.0 looks like an actual bug; I cannot see how MacPorts could be messing this up. I am less sure about wrong rpaths, need to verify what CMake port group may be doing in this regard.
Re headers, looks like CMake build is indeed set up to install all headers: https://github.com/wxWidgets/wxWidgets/blob/a8b6fdb7a7d518258a56b6a88262bf8281ddd26e/build/cmake/install.cmake#L14-L17
Is this intended?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Ok, I have found an option to disable uilocale, from looks of things, and configure allows to set it normally, but then hell breaks loose during the build: datetime does not build without uilocale, and numerous options break without datetime:
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_wxgtk-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/include/wx/chkconf.h:1840:13: error: #error "wxCalendarCtrl requires wxUSE_DATETIME"
:info:build 1840 | # error "wxCalendarCtrl requires wxUSE_DATETIME"
:info:build | ^~~~~
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_wxgtk-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/include/wx/chkconf.h:1865:13: error: #error "wxDatePickerCtrl and wxTimePickerCtrl requires wxUSE_DATETIME"
:info:build 1865 | # error "wxDatePickerCtrl and wxTimePickerCtrl requires wxUSE_DATETIME"
:info:build | ^~~~~
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_wxgtk-3.2/wxgtk-3.2/work/wxWidgets-3.2.5/include/wx/chkconf.h:1898:13: error: #error "wxFileCtrl requires wxDateTime"
:info:build 1898 | # error "wxFileCtrl requires wxDateTime"
:info:build | ^~~~~
These all should be dependent options: if they really require datetime, and datetime requires uilocale, then -DwxUSE_INTL=OFF must force disable everything down the chain.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
UPD. uilocale issue has been fixed in the master in 77e825f
(datetime issue stands in principle, but now I do not need to disable it anymore.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
0.0.0 is probably be the so-version, which gets reset to 0 when wxWidgets major version changes, because the whole library name changes. See build/bakefiles/version.bkl for more info.
Or it could be macOS Mach-O specific version stuff. Which we currently don't set.
You could try changing/adding version stuff in wx_set_target_properties and see if it makes any difference.
set_target_properties(${target_name} PROPERTIES SOVERSION ${wxSOVERSION_MAJOR} VERSION ${wxSOVERSION} MACHO_CURRENT_VERSION ${wxVERSION} MACHO_COMPATIBILITY_VERSION "${wxMAJOR_VERSION}.${wxMINOR_VERSION}" )
I know about CMake installing all the header files, there is #22714, but I haven't found motivation to try to improve it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@MaartenBent We have seen similar issues with meson with dylib versions, in fact rather often, I need to find what is was specifically; perhaps, CMake does the same thing.
Since with makefiles I had weird linking issues (even on Sonoma), perhaps I rather stick to cmake. Wrong baked in paths are unpleasant, but trivially fixable.
Do we need gnome filesystem on Apple? The build picks it up, if installed. Compilation is easy to fix (I had one minor error due to incorrect macros in the source), but I have no idea if it is useful on macOS for anything :)
Also I did not find how to disable weburlsession: configure args seems to get ignored. (Fixing it locally is no issue, a matter of a couple of macros, but that is not a proper fix.)
P. S. Just for the record, re legacy systems:
- There is no problem with positional arguments (which I mentioned earlier), the cause of that error with Filezilla configure is unrelated to
wx. Fixed now. - Disabling uilocale, unfortunately, is a problem, even though
wxGTKbuilds fine from the master without uilocale, since dependents may not build:
:info:build filezillaapp.h:55:25: error: 'wxLocale' was not declared in this scope; did you mean 'SetLocale'?
:info:build 55 | std::unique_ptr<wxLocale> m_pLocale;
:info:build | ^~~~~~~~
:info:build | SetLocale
:info:build filezillaapp.h:55:33: error: template argument 1 is invalid
:info:build 55 | std::unique_ptr<wxLocale> m_pLocale;
:info:build | ^
:info:build filezillaapp.h:55:33: error: template argument 2 is invalid
:info:build In file included from bookmarks_dialog.cpp:3:
:info:build filezillaapp.h:55:25: error: 'wxLocale' was not declared in this scope; did you mean 'SetLocale'?
:info:build 55 | std::unique_ptr<wxLocale> m_pLocale;
:info:build | ^~~~~~~~
:info:build | SetLocale
:info:build filezillaapp.h:55:33: error: template argument 1 is invalid
:info:build 55 | std::unique_ptr<wxLocale> m_pLocale;
:info:build | ^
:info:build filezillaapp.h:55:33: error: template argument 2 is invalid
So instead a Cocoa-free code has to be restored, which worked in 3.0.
3. Some missing symbols are still there, should not be hard to fix:
36-25% diff-pdf
dyld: Symbol not found: __ZN22wxMimeTypesManagerImpl19GetIconFromMimeTypeERK8wxString
Referenced from: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_core-3.3.dylib
Expected in: dynamic lookup
(This is a result of GTK vs Cocoa defs, I think.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
nieder
You could try changing/adding version stuff in
wx_set_target_propertiesand see if it makes any difference.set_target_properties(${target_name} PROPERTIES SOVERSION ${wxSOVERSION_MAJOR} VERSION ${wxSOVERSION} MACHO_CURRENT_VERSION ${wxVERSION} MACHO_COMPATIBILITY_VERSION "${wxMAJOR_VERSION}.${wxMINOR_VERSION}" )
Here's the doc link for how/when to use MACHO_COMPATIBILITY_VERSION: https://cmake.org/cmake/help/latest/prop_tgt/MACHO_COMPATIBILITY_VERSION.html This issue happens frequently when going from autotools to cmake.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
I have apparently resolved issues with missing symbols in wxGTK build on 10.6 and sorted CMake build on Sonoma (both systems use the same build set-up, though 10.6 needs a few extra patches and disabled uilocale, for now).
I can build now against wxGTK 3.3 on the old macOS, and I got diff-pdf working (well, GUI works, I did not test anything deeper).
However, I have a segfault with rawproc. Could someone say if this suggests anything?
Process: rawproc-orig [80492]
Path: /opt/local/bin/rawproc-orig
Identifier: rawproc-orig
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: zsh [319]
Date/Time: 2024-07-30 18:18:15.262 +0800
OS Version: Mac OS X 10.6 (10A190)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff8
Crashed Thread: 0
Thread 0 Crashed:
0 libwx_baseu-3.3.dylib 0x00e26be4 wxString::~wxString() + 20
1 libwx_baseu-3.3.dylib 0x00e3fb0c void std::_Destroy_aux<false>::__destroy<wxString*>(wxString*, wxString*) + 52
2 libwx_baseu-3.3.dylib 0x00e764e4 wxBaseArray<wxString, wxSortedArray_SortFunction<wxString> >::RemoveAt(unsigned long, unsigned long) + 160
3 rawproc-orig 0x0000b1ac rawprocFrmApp::OnInit() + 2780 (filename.h:508)
4 libwx_baseu-3.3.dylib 0x00e7f73c wxEntry(int&, wchar_t**) + 196
5 rawproc-orig 0x0014c428 main + 68 (rawprocApp.cpp:26)
6 rawproc-orig 0x0000a50c start + 64
GDB shows this:
Reading symbols for shared libraries .. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffff8
0x00e26be4 in wxString::~wxString () at _string.h:80
80 return __builtin___memset_chk (__dest, __val, __len, __darwin_obsz0(__dest));
(gdb) bt
#0 0x00e26be4 in wxString::~wxString () at _string.h:80
#1 0x00e3fb10 in std::_Destroy_aux<false>::__destroy<wxString*> ()
#2 0x00e764e8 in wxBaseArray<wxString, wxSortedArray_SortFunction<wxString> >::RemoveAt ()
#3 0x0000b1b0 in rawprocFrmApp::OnInit (this=0x73241a0) at filename.h:508
#4 0x00e7f740 in wxEntry ()
#5 0x0014c42c in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawproc/rawproc/work/rawproc-1.4.0/src/rawprocApp.cpp:26
Current language: auto; currently c
The same version of rawproc launches on Sonoma without crashes, being built against my port of wxGTK. So I think the issue is rather with my patches or with wxGTK code.
Not asking anyone to bother fixing it, of course, I just want an informed opinion.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Possibly something got broken in b0d6b11#diff-543aa2eadf8db59603670dfc563c2245d24f07b6c79e1e022ed7e9cd6e082531
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
While working on #24792, I noticed BASE_OSX_NOTWXMAC_{HDR/SRC} file definitions for macOS builds with a toolkit different from cocoa/iphone. But both CMake and configure do not use this. Not sure if this helps with your problem or makes it worse, but I added it like this:
https://github.com/wxWidgets/wxWidgets/blob/6585c10d0b12283310b32289ee6cce965cb88f1b/build/cmake/lib/base/CMakeLists.txt#L16-L25
configure/makefile also does not use it because the bakefile that generates the makefile defines BASE_OSX_SRC, but later on uses BASE_OSX_SHARED_SRC instead of BASE_OSX_SRC.
https://github.com/wxWidgets/wxWidgets/blob/2fe07151440ad19a8e3d80001d74a4399134b8c2/build/bakefiles/files.bkl#L3150-L3166
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@MaartenBent Thank you, I will take a look. Is this issue specific to CMake-based build or also relevant to autotools one?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
I think autotools is also affected. Because both build systems do not use this OSX_NOTWXMAC file-list, but the normal macOS file-list.
For example, the OSX_NOTWXMAC file-list does not include some files that you listed as problematic, like src/osx/core/mimetype.cpp and src/osx/cocoa/stdpaths.mm and src/osx/fswatcher_fsevents.cpp (and uses src/unix/mimetype.cpp instead).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Something started baking in wrong paths to wx libs:
---> Scanning binaries for linking errors
Could not open /opt/local/lib/libwx_baseu-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/bin/wxrc-3.2)
Could not open /opt/local/lib/libwx_baseu_xml-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/bin/wxrc-3.2)
Could not open /opt/local/lib/libwx_gtk3u_core-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_adv-3.2.0.3.0.dylib)
Could not open /opt/local/lib/libwx_gtk3u_html-3.2.0.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.2/lib/libwx_gtk3u_richtext-3.2.0.3.0.dylib)
---> Found 27 broken files, matching files to ports
---> Found 1 broken port, determining rebuild order
---> Rebuilding in order
wxgtk-3.2 @3.2.6_0
I think there was no such a problem in 3.2.5, though I need to verify that still.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
@vadz I revisited the issue today, and I think at least on Sonoma (should be all recent macOS) I got a working installation.
It builds on powerpc too, though I had no time today to try using it with dependents.
How should we proceed? Ideally I would like to have wxGTK fixed for all macOS, which includes older systems (there wxGTK is essential, since Cocoa is just broken). But I need someone to review patches and hopefully improve upon them. I had to revert a couple of breaking commits when building for 10.6, which is mostly not mergeable in this form, so those have to be changed in some way.
You could take a look at patches here: macos-powerpc/powerpc-ports@cbedc9c (this is for 3.2.x, but I have a version for 3.3.x as well).
There are two sets of those: 000x are for all macOS (including the current), 100x are only needed for older ones. It will probably be easy to deal with the first set, since those are minimal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It would be simpler to review the patches (and check that they don't break anything for the other builds) if you could please make a PR with them. Please start with a PR against master first.
TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
Ok, will do it in a couple of days.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)This is wxGTK 3.2.6 on 10.6 PowerPC:
7DB53A2C-4A6C-4534-8EBA-5D7B28A57D6E.png (view on web)
This is a very basic app, but it works. No hacks to the build too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)@MaartenBent It took forever to come back to this, but yes, your patch helps with some issues, at least I can drop mimetype-related hack now. I will see if anything else got fixed. Thank you!
P. S. While wxGTK supports building with wxLocale disabled, in practice that means some ports won’t build with it, since they assume, unfortunately, that wxLocale must be supported. In particular, FileZilla. So disabling it isn’t a satisfactory solution after all. Good news is that the problem turns out to be specifically with two, apparently somewhat secondary, functions, which should not be really hard to fix or in the worst case disabled. I will update on that soon.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)Update. In fact I got rid of pretty much all ugly patches. CoreGraphics did not work because it could not be included directly and needed an extra flag to find the framework headers. A few files aren’t really used with GTK backend at all, and I think I had those patches simply due to reverting some large breaking commits in bulk. They are not needed, as long as we only support older macOS with GTK and not Cocoa (which is my idea anyway). uilocale.mm probably is just misplaced and should not be included in the build. I could also drop most of overrides for configure args for legacy systems which I had.
Still need to check if the resulting lib works correctly.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)I got FileZilla built against wxGTK 3.2.6 (at it launches normally). On Sonoma arm64 now (it is just faster to debug the build), will sort out PowerPC too, I think.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23475)Do you have any patches to wx itself? 3.2.7 release is imminent, so if you do, now would be a great time to apply them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)@vadz Against which branch should I do the PR? Will submit tonight (regardless of powerpc status).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23475)3.2 please. If the changes are too extensive, I'm probably not going to be able to apply them that close to the release, but there is still time to get some minor fixes in.
TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)@vadz Great. 3.2 is easier, since I worked with 3.2.6 this time. I think patches are pretty minimal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)Looks like it is working now. FileZilla was failing before, since it required locale support.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)@vadz Was this forgotten? 6585c10
This is not my fix, but we need it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23475)Sorry, I don't know what is 6585c10, it doesn't seem to belong to any PR.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#23475)It was part of #24792 (maybe before a rebase) and has already been backported to 3.2 in c82cec8
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)@vadz Would you recommend making several PR with more or less isolated fixes? I will need your help with this though; I can test on available set-ups (but only macOS), but I am no expert in this code at all :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23475)I think it would be better to make separate PRs, it would make discussing them more convenient. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Sergey Fedorov
barracuda156 left a comment (wxWidgets/wxWidgets#23475)Just to reflect recent developments: the build works for the master. (Breakages might occur, but they get addressed.)
I am not 100% sure re 3.2.x branch, it may lack some backports, since I keep local patches in the port.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.