Building C::B on Mac OS (arm64): problems

[perazz]

Hi,

I've almost managed to build and package C::B nightly on Mac OS (arm64), I think I've sorted out most of the issues, but I need help for the final application bundling.

This is the process so far:

- Using all gcc tools from homebrew
- Using pre-built wx 3.1.7 also from homebrew
- then run:

Code

#!/bin/zsh 

# download nightly
#svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk

# prepare installation
cd trunk

# homebrew wxwidgets is not globally installed: add here
ACLOCAL_FLAGS="-I /opt/homebrew/share/wx/3.1/aclocal" ./bootstrap

# remove plugins that depend on stuff that doesn't build
./configure --prefix=/Users/federico/Downloads/codeblocks/nightly/test_build --with-contrib-plugins=all,-NassiShneiderman,-FileManager --enable-fortran --enable-debug

# build
make -j12
make install

# package
cd /Users/federico/Downloads/codeblocks/nightly/test_build/share/codeblocks/osx_bundle
sh ./bundle.sh

The bundle script can't copy/change name some DLLs:

Code

./bundle.sh: line 29: 88312 Killed: 9               install_name_tool -change $dep @executable_path/$(basename $dep) $1
./bundle.sh: line 29: 88323 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88334 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88345 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88356 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88367 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88378 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88389 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88400 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88411 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1
./bundle.sh: line 29: 88422 Killed: 9               install_name_tool -change $oldlink "@executable_path/$current_dep" $1

so that when I try to run the code blocks application it crashes on segfault (due to missing DLLs I think).
Could anybody help?
Thank you,
Federico

[AndrewCot]

I have been working on C::B with an Intel based MAC with Big Sir.  I have not had any problems with the bundle.sh. Attached are the scripts I use to build and run C::B on the MAC (in the zip) as well as a gamma build doc (if you have time to update/fix it then go for it and post a followup in this thread with the update as an attachment) . The build script can be configured to use either wxWidgets 3.1 or 3.2. These may be of some use.

One thing with the script you have is that the svn checkout needs to have the "--recursive" in order to grab the external Fortran and one other plugin (sorry cannot remember it). These missing plugins could be an issue.
I do not understand why you are running the bundle.sh in the cd /Users/federico/Downloads/codeblocks/nightly/test_build/share/codeblocks/osx_bundle , when it's in the SVN root source directory. This could be an issue as well.


One big issue you will hit, is the ability to debug using GDB is not easy as it needs you to jump through a bunch of hoops to get it installed and working on OSX. I could not get it working. As such I have been working on getting the DAP interface to get debugging working with LLDB and have it working for simple debugging. See https://forums.codeblocks.org/index.php/topic,24930.msg170479.html#msg170479 for info the DAP interface and where I am up to.


BTW:

• I have not updated the https://github.com/acotty/CodeBlocks_Unofficial_Testing repo with the build and code changes I have made this week after going back to getting C::B debugging working on the MAC again after a while working on Windows and Linux.
• The https://github.com/acotty/CodeBlocks_Unofficial_Testing source tree has a bunch of changes compared to the SF C::B source tree and is not the same as my local build tree. I push changes from my local source tree into a private GIT repo and then when I have a working testable release I then update the  https://github.com/acotty/CodeBlocks_Unofficial_Testing source after reformatting the souse so it is consistent.
• I am working on the LLDB-server auto detection code for the MAC and once I have it working then I will update the https://github.com/acotty/CodeBlocks_Unofficial_Testing repo, which should hopefully occur in the next few days.

[AndrewCot]

I fixed the LLDB-server auto detection code and have update my repo with all of the changes and did a quick test to ensure the code builds and runs on my MAC.

This is a quick set of instructions to build and test C::B from my repo:

• git clone https://github.com/acotty/CodeBlocks_Unofficial_Testing
• cd ./CodeBlocks_Unofficial_Testing/Build_Helper_Files/CodeBlocks_MacOS
• chmod +x *
• ./change_permissions_MacOS.sh
• ./MacOS_codeblocks_build.sh
• To test the resulting C::B before installing the DMG file run the following script:    ./StartCB_Makefile.sh

In the C::B source root directory you should find the DMG file if everything worked or if it did not then errors will be shown.

With this repo you can use build Code::Blocks using Code::Blocks as follows:

 1. Copy the file:
       from: CodeBlocks_Unofficial_Testing/Build_Helper_Files/CB_GlobalVariables.xml
       to:   CodeBlocks_Unofficial_Testing/Build_Helper_Files/CB_MacOSVariables.xml
 2. Open the CB_MacOSVariables.xml file in an editor and :
    a) remove the windows and Linux environment variables so that just the <cb_macos>...</cb_macos> variable data is left.
    b) Edit the data to match your configuration. Set the <wxwidgets> <BASE> to "" if you have used brew to install wxWidgets.
 3. Run C::B
 4. Open the "Global Variable Editor" by selecting the following sub menu: Settings->Global variables...
 5. In the "Global Variable Editor" dialog click on the "Import Set/All" button at the bottom of the  dialog and load the
       "CodeBlocks_Unofficial_Testing/Build_Helper_Files/CB_MacOSVariables.xml" file 6. Load the CodeBlocks_Unofficial_Testing/src/CodeBlocks_MacOS.workspace
 7. Build the workspace
 8. At the moment you cannot debug C::B, so you will need to run it via the following file:
     "CodeBlocks_Unofficial_Testing/Build_Helper_Files/CodeBlocks_MacOS/StartCB_Devel3264.sh"


The next thing I will be working on is getting the DAP debugger debugging the C::B build

[perazz]

Thank you for the hints! I still have a few issue building the NassiShneiderman plugin (auto tools can't find the boost library from homebrew), but apart from that, I can build C::B more or less following the same example that you've posted.

- Now, if I run the executable from devel31/bin/codeblocks , the code starts, but it can't load any plugins, not even the compiler plugin.
(apparently it's looking for them in the wrong folder)
- If I run the Mac package, I still get "zsh: killed" and there's nothing I can do, nor any error messages is seen.
If I run `otool -L codeblocks` I don't see any issues with the libraries being linked against.

I wonder if the packaging procedure is copying the wrong .dylib files e.g. from wxWidgets?
I notice you're building wx yourself, is there a reason why you're not using the wx build shipping with homebrew? (It's at 3.2.0)

[perazz]

Ok I think I've sorted that out.
When using the pre-built homebrew wx library, the packaging manager had troubles with the signature of those libraries,
with errors like

Code

install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...

(see for example at https://gitlab.kitware.com/cmake/cmake/-/issues/21854)

Of course when I was launching C::B directly from /src/devel31/bin, there was no issue because the original libraries in /opt/homebrew were used; this
was only an issue with the package because the executable dependencies are re-written to search for dynamic libraries in @executable_path only.

Now, with self-built wxWidgets, everything works OK. Next step will be to try build the Fortran plugin, which has a broken unix makefile...

[AndrewCot]

I have not looked at the packaging debug output as the DMG file I build works.

I was building wx3.2 before it was availabel on brew and since it became available I have installed it. The build file I attached was updated yesterday afternoon and in the git repo as the check to see if it was installed did not work and has been fixed.

[sodev]

Ok I think I've sorted that out.
When using the pre-built homebrew wx library, the packaging manager had troubles with the signature of those libraries,
with errors like

Code

install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...

This is not an error, but a warning, and will always occur when you package signed libraries, because changing rpath and the like do invalidate the signatures. The solution is to sign the bundle again.