Menu

#1509 r13594 breaks build on older versions of macOS: fatal error: Security/SecRandom.h: No such file or directory

Undefined
open
nobody
None
Bug_Report
2025-01-06
2025-01-03
No

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....

Introduced by https://sourceforge.net/p/codeblocks/code/13594/tree//trunk/src/plugins/contrib/source_exporter/wxPdfDocument/src/crypto/random.cpp

It is really nice to have CodeBlocks working. Please consider using a breaking code conditionally.

Discussion

  • Morten MacFly

    Morten MacFly - 2025-01-03

    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 the Makefile.am and try to compile again?

     
    • Sergey Fedorov

      Sergey Fedorov - 2025-01-03

      Sure, I will try that and let you know, thank you.

       
    • Sergey Fedorov

      Sergey Fedorov - 2025-01-03

      Looks like pdfencrypt uses it, so linking fails with a bunch of undefined symbols.

       
  • Morten MacFly

    Morten MacFly - 2025-01-04

    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.)

     
  • Morten MacFly

    Morten MacFly - 2025-01-04

    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]

    • Sergey Fedorov

      Sergey Fedorov - 2025-01-04

      Thank you! I will try that.

       
      • Morten MacFly

        Morten MacFly - 2025-01-05

        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.

         
        • Sergey Fedorov

          Sergey Fedorov - 2025-01-05

          I started the build for 13603 now (cuttent SVN trunk), will update on result in a while. (It will take some time to build.)

           
          • Sergey Fedorov

            Sergey Fedorov - 2025-01-05

            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
  • Morten MacFly

    Morten MacFly - 2025-01-04

    Additionally, for the record: Could you please tell what MacOS version you are using?

     
    • Sergey Fedorov

      Sergey Fedorov - 2025-01-04

      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!

       
  • Ken Cunningham

    Ken Cunningham - 2025-01-05

    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
  • Ken Cunningham

    Ken Cunningham - 2025-01-06

    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.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.