#1598 PATCH: new auto_revision tool for unix-like shells

[Carlo Bramini]

C::B uses a built-in program called auto_revision for getting some information about current sources.
This program is located under codeblocks-code\src\build_tools\autorevision and it is a .cpp source.
I noticed this can work when your build/host/target are all the same, in other words, a native build.
If you are using a cross compiler, it won't work because the target architecture is not the same of the build one.

So, I would like to suggest a different solution for bypassing this problem.
I made a script to be used when building with unix shell and autotools.
This script emulates all the functions of the corresponding existing program and it is able to extract the information from SVN or GIT trees.

I have built successfully my native port for CYGWIN and I compiled C::B for MinGW-w64 cross compilers for x86_64, i686 and Aarch64.

The patch is made by two parts:

• the auto_revision.sh script, that must be copied inside codeblocks-code\src\build_tools\autorevision directory.
• a patch to codeblocks-code\src\build_tools\autorevision\Makefile.am for supporting the new tool.

The new solution can coexist with the current implementation of the auto_revision tool and autorevision.cpp can be kept, if an user will want to build C::B with a different way besides autotools and an unix shell.

The new auto_revision.sh script is available here as plain text, for an immediate testing.

I hope that you will find it useful.
Sincerely.

[Carlo Bramini]

The auto_revision script:

[Carlo Bramini]

The patch to codeblocks-code\src\build_tools\autorevision\Makefile.am:

[Carlo Bramini]

Hello. Any comments?

[Christo]

Hi @carlo_bramini , could you please share the configure command you use for cross compiling codeblocks?

[Carlo Bramini]

I'm building code::blocks for Cygwin and MinGW.
For building C::B for Cygwin, I'm using this command:

CPPFLAGS=-D_GNU_SOURCE ../codeblocks-code/configure --enable-silent-rules --with-contrib-plugins=all --prefix=$HOME/codeblocks/inst_cb --with-wx-config=/usr/bin/wx-config-3.3-gtk3 --disable-static-wx

Unfortunately, C::B uses some C functions that are "extension" or "non standard" for the traditional C library, so I had to add _GNU_SOURCE to CPPFLAGS.
Perhaps, a cleaner alternative is adding AC_GNU_SOURCE configure,ac and let the configure script to handle it itself. The next parameters are all quite simple to understand. The build for Cygwin is Native.
However, Cygwin also requires a set of patches for working, that I had posted long time ago here, in a different bug report.

Next, for the C::B for MinGW, I did this command:

../codeblocks-code/configure --enable-silent-rules --with-contrib-plugins=all --prefix=$HOME/codeblocks/inst_cb_win64 --with-wx-config=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/wx-config-3.2 --host=x86_64-w64-mingw32 --disable-pch --disable-static-wx

They are all standard options and the configuration is done completely.
Unfortunately, although Windows is a supported platform, things are not building successfully.
I made some patches for fixing my troubles but probably these changes need to be posted into a different bug report too.

Sincerely.

[Carlo Bramini]

I updated he patch to codeblocks-code\src\build_tools\autorevision\Makefile.am.
Previously, every time auto_revision.sh was executed, it created a new file.
So, all executable files created in the previous build step needed to be re-linked even if the file generated by auto_revision.sh was identical to the previous one.
This updated patch makes things a bit smarter: if an old source file already exists a it is identical to the current one, then the previous one is not overwritten,

[Christo]

Hi @carlo_bramini could you please suggest if attached modified patch and the script is sufficient? It will keep current behavior for normal builds, but use your script during cross compilation.

[Carlo Bramini]

Well, at first sight, it seems to me that it could work.

However, my doubt is that I can't understand why doing this change.
In my opinion, there are two possible scenarios:

• If the new script is not good or if we aren't sure that it's right, then we can leave the code as it is, so the old autorevision tool is kept and that's fine.
• If the new script works fine, then the old autorevision tool is just redundant when using unix autotools for building C::B. The old autorevision tool will still be useful if there are other ways for build C::B besides an unix shell.

So, please excuse me, but I don't understand the reason of the new "use-script-for-crosscompile-only.patch" file.

[Christo]

Refactored autorevision tool to support cross compile in [r14036]

[Carlo Bramini]

Excuse me, I have not understood how the above commit has resolved this issue.
The autorevision tool cannot support cross compile.
It is compiled for running on host and not on build.
The host could be a different OS or a different CPU than build, so it cannot just work like this, that's why I contributed a bash script for collecting the same information.

[Christo]

Makefile.am is modified to use build CXX to compile for build PC in the commit. Could you please provide the error logs? Also please make sure to pass the correct --build=prefix during configure.

[Carlo Bramini]

I see, $(CC_FOR_BUILD) has been used to compile the tool.
That detail escaped to my attention, thanks.

However, I did an experiment and I tried to build C::B for Windows on ARM64 by using Cygwin as build platform (however, any build platform different from host is good to reproduce the behaviour).
My compilers are:

• gcc/g++ for building the "native" executables for x86_64 under Cygwin.
• aarch64-w64-mingw32 cross compiler for Windows on ARM64.

After configuring the build tree, I executed "make" and this happened on the console:

make[3]: Entering directory 'codeblocks-woa64/src/build_tools/autorevision'
./auto_revision +int +wx +t ../../../../codeblocks-code ../../../src/include/autorevision.h
./auto_revision: ./auto_revision: cannot execute binary file
make[3]: *** [Makefile:719: all-local] Error 126

The problem happens because it tries to execute a program for different CPU (Aarch64 instead of x86_64).
Why does it happen?
Well, Libtool creates a "wrapper" source file into the build directory, here it is called lt-auto_revision.c:

/* ./.libs/lt-auto_revision.c - temporary wrapper executable for .libs/auto_revision.exe
   Generated by libtool (GNU libtool) 2.6.2

   The auto_revision program cannot be directly executed until all the libtool
   libraries that it depends on are installed.

   This wrapper executable should never be moved out of the build directory.
   If it is, it will not operate correctly.
*/

The makefile creates two executables: a "native" executable and this "wrapper" executable, created with aarch64-w64-mingw32 cross compiler:

$ file src/build_tools/autorevision/.libs/auto_revision.exe
src/build_tools/autorevision/.libs/auto_revision.exe: PE32+ executable for MS Windows 5.02 (console), x86-64, 19 sections

$ file src/build_tools/autorevision/auto_revision.exe
src/build_tools/autorevision/auto_revision.exe: PE32+ executable for MS Windows 5.02 (console), ARM64 (stripped to external PDB), 10 sections

The build process tries to execute the wrapper executable but it fails.
So, that's the story.

[Christo]

Hi @carlo_bramini Thank you for the detailed analysis. I've added a followup commit [r14040] to use CXX_FOR_BUILD directly bybassing libtool. Hope this will fix the issue.

[Carlo Bramini]

It works!!!

[Christo]

Thank you for confirming