Menu
▾
▴
#1509 r13594 breaks build on older versions of macOS: fatal error: Security/SecRandom.h: No such file or directory
Recent commit has broken the build on older macOS versions:
:info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.0-cxx11/include/wx-3.0/wx/iconbndl.h:113:5: note: in expansion of macro 'wxDEPRECATED_CONSTRUCTOR'
:info:build 113 | wxDEPRECATED_CONSTRUCTOR( wxIconBundle (const wxString& file, long type)
:info:build | ^~~~~~~~~~~~~~~~~~~~~~~~
:info:build src/crypto/random.cpp:270:10: fatal error: Security/SecRandom.h: No such file or directory
:info:build 270 | #include <Security/SecRandom.h>
:info:build | ^~~~~~~~~~~~~~~~~~~~~~
:info:build compilation terminated.
:info:build make[5]: *** [src/crypto/random.lo] Error 1
:info:build make[5]: *** Waiting for unfinished jobs....
It is really nice to have CodeBlocks working. Please consider using a breaking code conditionally.
It can probably be fixed via
legacy-supportlibrary (available in MacPorts and NetBSD’s pkgsrc), since it hasgetentropy: https://github.com/macports/macports-legacy-support/blob/38694c215027ff21b24819a96256859157d89a35/include/sys/random.hThis is also available in macOS 10.12+, not clear why it was not used, reducing special cases.
Maybe there is an even easier solution: To my knowledge, we don't even use the crypto stuff of the wxPDF lib. Could you please try to remove all compilation units under the "
crypto" folder from theMakefile.amand try to compile again?Sure, I will try that and let you know, thank you.
Looks like
pdfencryptuses it, so linking fails with a bunch of undefined symbols.Too bad. I've forwarded this request to the original author of the lib:
https://github.com/utelle/wxpdfdoc/issues/94
...lets see if he is able to propose a solution.
(I don't want to patch foreign libraries in C::B if not really needed.)
I've downgraded the wxPDFDoc library to v1.1.0 to address this issue in [r13602].
This should restore compatibility with wx3.0 according to the release notes here:
https://github.com/utelle/wxpdfdoc/releases/tag/v1.2.0
...and here:
https://github.com/utelle/wxpdfdoc/releases/tag/v1.1.0
Let me know if that is working for you and thanks for reporting!
Related
Commit: [r13602]
Thank you! I will try that.
OK, great. There are some more news now:
The author of wxPDFDoc has now also implemented a patch in its repo that should allow to use version 1.2.0 on wx30 on Mac 10.6x (thanks to Ken Cunningham). I would like to propose therefore:
1.) Please try C::Bs SVN version now which is v1.1.0
...whether or not this will be successful, after that I'll update to the patched version of v1.2.0 and then...
2.) please try again C::Bs SVN version then which would be v1.2.0-patched
In this way we can switch to whatever is more reasonable and know when we break things.
I started the build for 13603 now (cuttent SVN trunk), will update on result in a while. (It will take some time to build.)
Hold on, I need to run another build. That was from a different portfile (r13593, I forgot to resync to an overlay repo).
Upd2. Okay, 13603 builds fine, confirmed.
Last edit: Sergey Fedorov 2025-01-05
Additionally, for the record: Could you please tell what MacOS version you are using?
10.6.8 at the moment (but no point trying also on 10.5.8, we know the header is missing there either).
P. S. Thank you for opening the issue with upstream!
He's using an offshoot version of 10.6.
I have been updating the codeblocks build on macos via macports for some years now.
we use wx3.0 on older systems (10.11 and older) that can’t use wx32, and wx32 on all systems 10.12+.
https://github.com/macports/macports-ports/blob/ae0a50c058007c7d1d9ff4bbba57285031f5850c/devel/codeblocks-devel/Portfile#L108
With the recent update to wxPDFDoc, I did have to add the security framework to allow the newer wxPdfDocument to build on almost all macos versions:
https://github.com/macports/macports-ports/blob/ae0a50c058007c7d1d9ff4bbba57285031f5850c/devel/codeblocks-devel/Portfile#L69
and opened this on the codeblocks devel forum about that:
https://forums.codeblocks.org/index.php/topic,25932.0.html
where a simple fix was proposed and tested.
The Security framework on 10.6 is missing the specific header mentioned in the this ticket and used in wxPDFDoc 1.2. That header is present on 10.7+.
https://github.com/kencu/macos-sdk/tree/master/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Versions/A/Headers
Working around that on 10.6 might be possible by forcing a fallback implementation to be used here:
https://github.com/utelle/wxpdfdoc/blob/fa88c9587560ca2a395eb0dbcd399bda134ffd65/src/crypto/random.cpp#L269
But there may be no point to doing that if the changes in the newer versions are for wx32+ only anyway, as wx32+ requires 10.12+.
https://ports.macports.org/port/wxWidgets-3.2/details/
So if wx30 compatibilty is to be maintained, and that means rolling back to wxPdfDocument 1.1.0, then that one Security header is not used there, so there will be no issue to fix.
Last edit: Ken Cunningham 2025-01-04
wxGTK 3.2 builds at least on 10.6, but needs some extra work to make sure everything works as expected, which I had no time to do so far.
Until then, wx* 3.0 is the only working option.
to be noted that upstream wxpdf has made some changes in v1.2 to support wx3.0 and pre-10.7 MacOS. Just testing those now.
Oh-- I see this mentioned in the threaded comments above.
Last edit: Ken Cunningham 2025-01-05
wxPDF 1.2.1 has been released now, with fixes for this, and other issues.
Confirmed to build on pre-10.7 MacOS, and current systems.
If you're using your own Makefile.am with it as CB does, it does need the Security framework added to the link libs, as per the CB forum post.