Compiling repp and ACE (again) on OSX 10.15 Intel

This thread discusses compiling ACE on OSX in some detail, however I am afraid I am not getting even as far as TJ got by the time he first posted in that thread. So I think I can’t yet benefit from that thread and I will start a new one.

I need to be able to build ACE on my Macbook Pro. I have an Intel processor and my OS is currently 10.15 (though I could upgrade if necessary).

gcc --version returns the following:

Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

After looking at the instructions, I installed boost which I think is the equivalent of libboost-regex-dev (is it?). I installed it using Homebrew. I hope it istalled correctly (how do I check?..)

I think I do not need to install build-essential (there is no such thing for OSX?)

The next step, according to the instructions, is to build repp. I downloaded the source code and am trying to build it but I get errors:

clang: warning: argument unused during compilation: '-fnested-functions' [-Wunused-command-line-argument]
preprocessor.c:46:2: error: function definition is not allowed here
        {
        ^
preprocessor.c:74:5: error: implicit declaration of function 'process_lost_char'
      is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                                process_lost_char(*inp++, *ina++);
                                ^
preprocessor.c:113:3: error: implicit declaration of function
      'process_lost_char' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
                process_lost_char(*inp++, *ina++);
                ^
3 errors generated.
make[1]: *** [preprocessor.lo] Error 1
make: *** [all-recursive] Error 1

Does this indicate I didn’t manage to install the dependencies correctly, or something else?.. Many thanks in advance.

If you check the homebrew build script, you should be able to recreate the make files that the homebrew install uses. I can look into it more later, if this doesn’t help.

Regarding the errors, these look like you’re either using the wrong compiler (though GCC is correct) or the wrong options. The brew build script should be helpful for the options.

1 Like

What this means is that you don’t actually have GCC installed. Instead you have clang, the compiler that Apple bundles. They provide a symlink so that typing gcc works, but clang doesn’t support nested functions. Home brew makes it pretty easy to install gcc though. Clang will remain available on your system. You may need to be creative with your PATH or something to get the home brew gcc to be the first ranked candidate for the command “gcc”.

Libboost-regex-dev is certainly the right species of animal. In the past I have had issues with the packaged versions not supporting ICU but I think those days may now be in the rear view mirror — I hope.

2 Likes

Aw, thanks for catching that, @sweaglesw! Yeah, you need to do brew install gcc, which should do everything automagically…

OK thanks, I’ve installed gcc now and modified the PATH and created aliases (as described here) so that:

$ gcc --version
gcc-11 (Homebrew GCC 11.2.0_3) 11.2.0

However I still get the same errors… Anything in addition to the PATH that I should be thinking about?.. (I have reloaded the terminal and even restarted the computer, just in case…)

The error message you posted earlier specifically mentioned clang and nested functions. If you are still getting that message then the build is still trying to use clang instead of your new gcc. You may want to edit a Makefile and manually set CC=/path/to/real/gcc or something like that? Or is the error different but just similar?

They are exactly the same errors, and yes, this definitely indicates that it keeps using the wrong compiler.

Here’s the full output in case you notice something useful there?.. (Thank you!!!)

(base) Murkin16:repp-0.2.2 olzama$ ./configure && make all
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i386-apple-darwin19.6.0
checking host system type... i386-apple-darwin19.6.0
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin/nm -B
checking the name lister (/opt/local/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /opt/local/bin/nm -B output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin19.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for regexecW in -lboost_regex... yes
checking for ANSI C header files... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking for bzero... yes
checking for regcomp... yes
checking for setlocale... yes
checking for strchr... yes
checking for strdup... yes
checking for strrchr... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating librepp/Makefile
config.status: creating repp/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
Making all in include
make[1]: Nothing to be done for `all'.
Making all in librepp
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"repp\" -DPACKAGE_TARNAME=\"repp\" -DPACKAGE_VERSION=\"0.2.2\" -DPACKAGE_STRING=\"repp\ 0.2.2\" -DPACKAGE_BUGREPORT=\"sweaglesw@sweaglesw.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"repp\" -DVERSION=\"0.2.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBBOOST_REGEX=1 -DSTDC_HEADERS=1 -DHAVE_LOCALE_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_BZERO=1 -DHAVE_REGCOMP=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DHAVE_STRDUP=1 -DHAVE_STRRCHR=1 -I.    -Wall -DVERSION=\"0.2.2\" -DPROG="\"repp\"" -I../include -g -O2 -fnested-functions -MT preprocessor.lo -MD -MP -MF .deps/preprocessor.Tpo -c -o preprocessor.lo preprocessor.c
libtool: compile:  gcc -DPACKAGE_NAME=\"repp\" -DPACKAGE_TARNAME=\"repp\" -DPACKAGE_VERSION=\"0.2.2\" "-DPACKAGE_STRING=\"repp 0.2.2\"" -DPACKAGE_BUGREPORT=\"sweaglesw@sweaglesw.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"repp\" -DVERSION=\"0.2.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBBOOST_REGEX=1 -DSTDC_HEADERS=1 -DHAVE_LOCALE_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_BZERO=1 -DHAVE_REGCOMP=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DHAVE_STRDUP=1 -DHAVE_STRRCHR=1 -I. -Wall -DVERSION=\"0.2.2\" -DPROG=\"repp\" -I../include -g -O2 -fnested-functions -MT preprocessor.lo -MD -MP -MF .deps/preprocessor.Tpo -c preprocessor.c  -fno-common -DPIC -o .libs/preprocessor.o
clang: warning: argument unused during compilation: '-fnested-functions' [-Wunused-command-line-argument]
preprocessor.c:46:2: error: function definition is not allowed here
        {
        ^
preprocessor.c:74:5: error: implicit declaration of function 'process_lost_char' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                                process_lost_char(*inp++, *ina++);
                                ^
preprocessor.c:113:3: error: implicit declaration of function 'process_lost_char' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                process_lost_char(*inp++, *ina++);
                ^
3 errors generated.
make[1]: *** [preprocessor.lo] Error 1
make: *** [all-recursive] Error 1

It says “we are using a GNU gcc compiler”?.. Is it mistaken? (Or is that a different thing altogether…)

I tried, in Makefile.in:

CC = /usr/local/Cellar/gcc/11.2.0_3/bin

…but unfortunately nothing changes, hmm.

I suspect the issue is that you used aliases instead of PATH to make typing “gcc” activate the home brew version. Aliases are only expanded for interactive shells by default, not in scripts. That would explain the behavior you are seeing.

The CC= line you tried in Makefile.in seems like it should have pointed to an executable rather than a directory, no?

Oh, I modified the PATH also…

Also corrected the CC= line to include the actual executable (gcc-11). Still no change.

My PATH looks like this:

/Users/olzama/anaconda3/bin:/Users/olzama/anaconda3/condabin:/Library/Frameworks/Python.framework/Versions/3.5/lib:/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/Users/olzama/Tools/delphin/art:/Users/olzama/Tools/delphin/ace:/usr/local/Cellar/gcc/11.2.0_3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Library/TeX/texbin:/usr/local/share/dotnet:/opt/X11/bin:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands

Anything on that PATH that looks wrong? (Could anaconda be messing with things?.. It should really only be relevant to python stuff, right?)

Another detail is that gcc --version returns what seems right the right thing (the Homebrew gcc) but which gcc returns usr/bin/gcc.

Ok, the following helped me reach a different outcome:

(base) Murkin16:repp-0.2.2 olzama$ ./configure CC=/usr/local/bin/gcc-11 && make all

And now it is complaining about not finding the boost library. Even though I thought I installed it. Oh well, at least this is progress :).

checking for regexecW in -lboost_regex... no
The Boost Regex library is required.

That message suggests either it can’t find your boost or the boost you installed lacks ICU support. You could use nm to see if regexecW is in the library.

@olzama, eventually you can find helpful the GitHub - LR-POR/delphin-docker: A docker container for running all DELPH-IN tools in a Linux box.. The delphin-docker/Dockerfile at master · LR-POR/delphin-docker · GitHub file contains the compilation step-by-step of ACE with all dependencies in the Linux Box. Let me know if I can help.

Anyway, in the past, I also tried to compile ACE on MacOS; I never really succeeded on that.

1 Like

Thank you Alex! My goal is to be able to set up a visual debugger and work with ACE that way (e.g. Visual Studio). In other words, the goal is not just to compile but rather to debug with the GUI tools that I am used to. Is the docker helpful for that?

(In related news, I was able to set up remote access to a linux machine via VS Code. It has such an option. So, I can open VS Code on my Mac, connect to a linux machine via ssh, and work on my Mac as if I were working on linux. This works pretty well, apart from the fact that one is then reliant on the ssh connection.)

In my Lisp dev environment, this is pretty common. I could easily connect my emacs to a remote Lisp Image, I never try that with C/C++ but if you made ssh to work, you can surely connect to the Linux Image using ssh. Debugging in a remote machine via VS Code… I never try… @goodmami any idea?

arademaker
January 19

[…] Debugging in a remote machine via VS Code… I never try… @goodmami any idea?

No, sorry. But VS Code does have very good documentation, so I’d start looking there.

I found Developing inside a Container using Visual Studio Code Remote Development, it seems that VS Code has good support for developing using containers.

1 Like

I mean, if I am using VS Code ssh remote, then it doesn’t matter to me to be able to compile anything on my Mac. The question here is whether I can, in principle, compile on my Mac (to not have to rely on ssh and remote connections).

(And I have to disagree about the quality of VS Code documentation. Where it comes to launching configurations, anything non-trivial and it’s really confusing and on occasion plainly wrong. There is multiple places where those configurations can be modified and there is no easy way of telling which place is the right one in different scenarios).