hexagonal-sun/bic

A C interpreter and API explorer.

bic's Issues

Homebrew support/Formula

This is more a placeholder (feel free to assign the issue to me) to remind me to submit a formula to Homebrew/homebrew-core for bic once a stable 1.x release is published.

In the meantime, if it is not too involved to convince bic to build with XCode's/macOS' native bison that would be ideal and make it very likely that the formula is accepted within hours or a day of submission.

If bic needs GNU Bison, and it is unreasonable or a huge effort to port it to use native macOS bison, a few words here in this issue explaining why will help move the submission along once it is submitted.

I have a formula written up that works with the current master branch, and the only audit failures are that there's no stable version yet (quickly and easily fixable with a 1.0 release) and a complaint about using GNU bison when macos provides bison. Porting to native bison or explaining why this is not desirable/possible is enough to dismiss that audit.

I'm including the formula as an attachment and inline for future reference.

class Bic < Formula
  desc "C interpreter and API explorer"
  homepage "https://github.com/hexagonal-sun/bic"
  head "https://github.com/hexagonal-sun/bic.git" # Needs url and sha256 inserted above this line on 1.0.0 release

  depends_on "autoconf" => :build
  depends_on "autoconf-archive" => :build
  depends_on "automake" => :build
  depends_on "bison" => :build # macOS bison is too outdated, build fails unless gnu bison is used
  depends_on "libtool" => :build if build.head?

  depends_on "gmp"
  depends_on "readline"

  uses_from_macos "flex" => :build

  def install
    system "autoreconf", "-fi" if build.head?
    system "./configure", "--disable-debug",
           "--disable-dependency-tracking",
          "--disable-silent-rules",
           "--prefix=#{prefix}"
    system "make", "install"
  end

  test do
    (testpath/"hello.c").write <<~EOS
      #include <stdio.h>
      int main () {
        puts("Hello Homebrew!");
      }
    EOS
    assert_equal "Hello Homebrew!", shell_output("#{bin}/bic -s hello.c").strip
  end
end

@hexagonal-sun Are you interested in me submitting a PR that would setup nightly (or CI) testing of master as homebrew builds it so that you can easily see if upstream changes (i.e., nightly tests when packages in Homebrew are upgraded) break bic or changes pushed to master break bic's compatibility with Homebrew? I would use GH actions for this, I find it to be more reliable than Travis-CI for macOS stuff, and Homebrew and Github both use the same back-end provider (MacStadium) for Github actions (macOS) and Homebrew CI and binary compilation and distribution (a.k.a. "bottling").

Native macOS support?

Hi, I know that I can run this using docker on macOS, but, once you hit a stable release it would be awesome to package this with homebrew.

My current testing shows that:

• The build succeeds using configure packaged with the v0.9.1 release using Apple Clang (the native tooling more or less required for Homebrew submission)
• 3 tests pass with make check and 62 fail using this configuration
• installing the dependencies to re-generate configure is possible, but it leads to a complaint about the libtool version during autoreconf -i, and
• it fails during make with both clang and gcc-9
• trying to use gcc-9 with the shipped ./configure script causes compilation errors during make

Here are logs with information about the build steps, environment and test failures:
bic.zip

In particular:

• config.log might be useful for seeing general config output
• 03.make.txt contains info about the environment and the higher level commands during make check and the test failures
• 02.make.cc.txt contains the actual compiler invocations to build and link the bic REPL

Allow builds from source with macOS' (Xcode's) `bison`

Homebrew doesn't like it when you use a non-native tool (e.g., GNU version) instead of the version provided by macOS/Xcode. Investigate building with native bison provided on macOS.

$ brew audit --strict --online --new-formula bic
bic:
  * Dependency 'bison' is provided by macOS; please replace 'depends_on' with 'uses_from_macos'.

segfault when evaluating simple c file.

Using this file (deleteme.c):

int main(int argc, char *argv[]) {
    (void)argc;
    (void)argv;
    return 2;
}

Running:

bic deleteme.c

Produces:

Segmentation fault (core dumped)

I'm still looking into this, but Valgrind says it's an Invalid read of size 8, triggered in eval_fn_call (evaluate.c:393):

==364== Memcheck, a memory error detector
==364== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==364== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==364== Command: /home/cj/.local/bin/bic /home/cj/dump/bictest/deleteme.c
==364== 
==364== Invalid read of size 8
==364==    at 0x127578: eval_fn_call (evaluate.c:393)
==364==    by 0x126FAA: __evaluate (evaluate.c:2555)
==364==    by 0x10E90A: bic_eval_file (main.c:199)
==364==    by 0x10E90A: main (main.c:222)
==364==  Address 0x168 is not stack'd, malloc'd or (recently) free'd
==364== 
==364== 
==364== Process terminating with default action of signal 11 (SIGSEGV)
==364==  Access not within mapped region at address 0x168
==364==    at 0x127578: eval_fn_call (evaluate.c:393)
==364==    by 0x126FAA: __evaluate (evaluate.c:2555)
==364==    by 0x10E90A: bic_eval_file (main.c:199)
==364==    by 0x10E90A: main (main.c:222)
==364==  If you believe this happened as a result of a stack
==364==  overflow in your program's main thread (unlikely but
==364==  possible), you can try to increase the size of the
==364==  main thread stack using the --main-stacksize= flag.
==364==  The main thread stack size used in this run was 8388608.
==364== 
==364== HEAP SUMMARY:
==364==     in use at exit: 120,625 bytes in 99 blocks
==364==   total heap usage: 105 allocs, 6 frees, 125,143 bytes allocated
==364== 
==364== 5 bytes in 1 blocks are definitely lost in loss record 3 of 74
==364==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==364==    by 0x55A79B9: strdup (strdup.c:42)
==364==    by 0x10E8AD: add_call_to_main (main.c:77)
==364==    by 0x10E8AD: bic_eval_file (main.c:198)
==364==    by 0x10E8AD: main (main.c:222)
==364==
==364== 18 bytes in 1 blocks are definitely lost in loss record 12 of 74
==364==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==364==    by 0x55A79B9: strdup (strdup.c:42)
==364==    by 0x129ED5: eval_init_builtins (evaluate.c:2595)
==364==    by 0x129ED5: eval_init (evaluate.c:2602)
==364==    by 0x10E6DD: main (main.c:215)
==364==
==364== LEAK SUMMARY:
==364==    definitely lost: 23 bytes in 2 blocks
==364==    indirectly lost: 0 bytes in 0 blocks
==364==      possibly lost: 0 bytes in 0 blocks
==364==    still reachable: 120,602 bytes in 97 blocks
==364==         suppressed: 0 bytes in 0 blocks
==364== Reachable blocks (those to which a pointer was found) are not shown.
==364== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==364==
==364== For counts of detected and suppressed errors, rerun with: -v
==364== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

I'm looking through the stack trace now, but I'm not familiar with this code base. I'm trying to work on Issue #29, but I can't get the master branch or v0.9.1 to run a simple C file (I haven't made any changes to the code yet).

I'll let you know if I come across anything else to help track this down.

Inspector segfaults on function

BIC> #include <stdio.h>                                                                                                                                                             
BIC> ?puts                                                                                                                                                                          
puts is a Function.                                                                                                                                                                 
value of puts is                                                                                                                                                                    
sizeof(puts) = 8 bytes.                                                                                                                                                             
Segmentation fault   

and with --enable-debug I see:

BIC> #include <stdio.h>                                                                                                                                                             
BIC> ?puts                                                                                                                                                                          
Fatal error: inspect.c:42 print_object_type: Tree type miss-match; have T_EXT_FUNC, should be T_LIVE_VAR

I see the README.org says the inspector works on variables and types, but a segfault is not a great result.

"Invalid number of parameters error" for simple C file.

This is just a continuation of Issue #31. The segfault is gone, but it will error out parsing a C file like this:

// deleteme.c
int main(int argc, char** argv) {
    return 2;
}

Output:

deleteme.c:0:0: error: Invalid number of parameters to function
Evaluator Backtrace
===================

<tree E_CTX tECTX_IS_STATIC: false
      tECTX_IS_FN_CALL: true
      tECTX_PARENT_CTX: 
  <tree E_CTX tECTX_IS_STATIC: false
        tECTX_IS_FN_CALL: false
        tECTX_PARENT_CTX:     <null>

        tECTX_NAME: 
    <tree T_IDENTIFIER tID_STR: "Toplevel">
        tECTX_ID_MAP: 
    <chain
      <tree E_MAP tEMAP_RIGHT: 
        <tree D_T_INT>
            tEMAP_LEFT: 
        <tree T_IDENTIFIER tID_STR: "__builtin_va_list">
      >
      <tree E_MAP tEMAP_RIGHT: 
        <tree T_FN_DEF tFNDEF_ARGS: 
          <chain
            <tree T_DECL tDECL_TYPE: 
              <tree D_T_INT>
                  tDECL_OFFSET: 0
                  tDECL_DECLS: 
              <tree T_IDENTIFIER tID_STR: "argc">
            >
            <tree T_DECL tDECL_TYPE: 
              <tree D_T_CHAR>
                  tDECL_OFFSET: 0
                  tDECL_DECLS: 
              <tree T_POINTER tPTR_EXP: 
                <tree T_POINTER tPTR_EXP: 
                  <tree T_IDENTIFIER tID_STR: "argv">
                >
              >
            >
          >
              tFNDEF_NAME: 
          <tree T_IDENTIFIER tID_STR: "main">
              tFNDEF_STMTS: 
          <chain
            <tree T_RETURN tRET_EXP: 
              <tree T_INTEGER tINT_VAL: 2>
            >
          >
              tFNDEF_RET_TYPE: 
          <tree D_T_INT>
        >
            tEMAP_LEFT:
        <tree T_IDENTIFIER tID_STR: "main">
      >
    >
        tECTX_JMP_BUF:
        tECTX_ALLOC_CHAIN:
    <chain
    >
        tECTX_RETVAL:     <null>

  >
      tECTX_NAME:
  <tree T_IDENTIFIER tID_STR: "main">
      tECTX_ID_MAP:
  <chain
  >
      tECTX_JMP_BUF:
      tECTX_ALLOC_CHAIN:
  <chain
  >
      tECTX_RETVAL:   <null>

>

I pulled your latest fixes (3386a8e). I guess it still needs the arguments forwarded from bic's command line?

Segmentation fault when calling external function without arguments

// oi.h
int get_number();

// oi.c
int get_number() {
    return 42;
}

Compile with gcc oi.c -shared -o liboi.
Run LD_LIBRARY_PATH=$PWD bic -loi -I$PWD

Execute on the REPL:

#include <oi.h>
get_number();

The segmentation fault happens because this specific function tree has ARGS as null (t1 = 0x0000000000000000). However, evalute.c:552 tries to iterate over this tree:

                for_each_tree(i, tFN_ARGS(function))
                    if (is_T_VARIADIC(i)){
                        is_variadic = true;
                        break;
                    }

A quick workaround for this problem was to check if args was set before iterating over it:

            if (tFN_ARGS(function)) {
                for_each_tree(i, tFN_ARGS(function))
                    if (is_T_VARIADIC(i)){
                        is_variadic = true;
                        break;
                    }
            }

Perhaps a better solution would be to include this check on the definition of for_each_tree?

Unable to compile on debian sid

Following the directions on the readme results in this error:

$ make
make  all-recursive
make[1]: Entering directory '/home/hathaway/src/bic'
Making all in src
make[2]: Entering directory '/home/hathaway/src/bic/src'
: --header-file=cfilelex.h -o /dev/null cfilelex.l
: --header-file=repllex.h -o /dev/null repllex.l
: --header-file=lang_lexer.h -o /dev/null lang_lexer.lpp
  CXX      lang.o
lang.cpp:4:10: fatal error: lang_lexer.h: No such file or directory
    4 | #include "lang_lexer.h"
      |          ^~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:896: lang.o] Error 1
make[2]: Leaving directory '/home/hathaway/src/bic/src'
make[1]: *** [Makefile:410: all-recursive] Error 1
make[1]: Leaving directory '/home/hathaway/src/bic'
make: *** [Makefile:342: all] Error 2

looks like I need to generate the lang_lexer.h file, how do I do that?

Build on Slackware (no Debian): autoreconf: "debian/control" not found.

I want to compile in Slackware, but I am an error from Debian.

/bic
autoreconf -i
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "es_AR.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
autoreconf: "debian/control" not found. Are you sure you are in the correct directory?

Missing `AC_PROG_RANLIB` in configure.ac

I get the following output and error when running autoreconf:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: autoconf --force
autoreconf: running: autoheader --force
autoreconf: running: automake --add-missing --copy --force-missingMi
configure.ac:18: installing './compile'
configure.ac:8: installing './config.guess'
configure.ac:8: installing './config.sub'
configure.ac:11: installing './install-sh'
configure.ac:11: installing './missing'
src/Makefile.am:8: error: library used but 'RANLIB' is undefined
src/Makefile.am:8:   The usual way to define 'RANLIB' is to add 'AC_PROG_RANLIB'
src/Makefile.am:8:   to 'configure.ac' and run 'autoconf' again.
src/Makefile.am: installing './depcomp'
configure.ac: installing './ylwrap'
src/aarch64/Makefile.am:1: error: library used but 'RANLIB' is undefined
src/aarch64/Makefile.am:1:   The usual way to define 'RANLIB' is to add 'AC_PROG_RANLIB'
src/aarch64/Makefile.am:1:   to 'configure.ac' and run 'autoconf' again.
src/x86_64/Makefile.am:1: error: library used but 'RANLIB' is undefined
src/x86_64/Makefile.am:1:   The usual way to define 'RANLIB' is to add 'AC_PROG_RANLIB'
src/x86_64/Makefile.am:1:   to 'configure.ac' and run 'autoconf' again.
parallel-tests: installing './test-driver'
autoreconf: automake failed with exit status: 1

Following the advice and adding an AC_PROG_RANLIB in the configure.ac let's the bootstrap proceed without error.

break not supported

$ cat foo.c
int main() {
    while (1) {
        break;
    }
    return 0;
}
$ ./src/bic foo.c
Parser Error: <stdin>:3 syntax error, unexpected BREAK.

Bash syntax error in test.sh

The following line in `test.sh``:

bic/testsuite/test.sh

Line 14 in 482ec54

if [ -! -x "$BIC" ]; then

always produces a non-zero exit code, with the following output:

./test.sh: line 14: [: -x: binary operator expected

Replacing -! with ! should fix the conditional.

Declarations in for statements not supported

tavianator@superluminal $ cat foo.c
int main() {
    for (int i = 0; i < 1; ++i) {
        return i;
    }
}
tavianator@superluminal $ ./src/bic foo.c
Parser Error: <stdin>:2 syntax error, unexpected INT.

configure: syntax error

Just tried this project on Ubuntu 18.04 and hit an autotools error

$ git clone https://github.com/hexagonal-sun/bic
Cloning into 'bic'...
...
Receiving objects: 100% (3202/3202), 644.99 KiB | 2.39 MiB/s, done.
Resolving deltas: 100% (2382/2382), done.

donp@jewel Desktop $ cd bic 
donp@jewel bic $ autoreconf -i
libtoolize: putting auxiliary files in '.'.
..
configure.ac: installing './ylwrap'
parallel-tests: installing './test-driver'
donp@jewel bic $ ./configure
checking build system type... x86_64-pc-linux-gnu
checking dependency style of gcc... gcc3
...
checking for uint32_t... yes
checking for uint8_t... yes
checking for ptrdiff_t... yes
./configure: line 17591: syntax error near unexpected token `,'
./configure: line 17591: `AX_CXX_COMPILE_STDCXX_11(, mandatory)'
donp@jewel bic $ 

segfault when trying to take a modulo

to replicate:

BIC > int a;
BIC > a = 30 % 50;
Segmentation fault (core dumped)

i have attached the core dump
coredump.tar.gz

Comma operator not supported

tavianator@superluminal $ cat foo.c
int main() {
    return (0, 1);
}
tavianator@superluminal $ ./src/bic foo.c
Parser Error: <stdin>:2 syntax error, unexpected ',', expecting ')'.

#define support in the REPL

BIC> #define NUMBER 1337
Parser Error: syntax error, unexpected IDENTIFIER, expecting ',' or ';'.

Originally posted by @vesche in #10 (comment)

Jupyter Kernel with xeus?

Similar to xeus-cling, it could be cool to make a Jupyter kernel using xeus! https://github.com/QuantStack/xeus-cling/

There is a tutorial for a toy kernel at https://github.com/QuantStack/xeus-calc

It should be only a couple of lines of code... let me know if you're interested, I'd be happy to help.

Is it possible to use bic as C frontend for a compiler?

Hi.

I'm working on an OS based on a managed code. (Here is what is it: https://phantomdox.readthedocs.io/en/latest/)

Currently I have my own language compiler, but I'm looking for make Java and Python frontends for it.

I never thought of C as a possible language for such an environment, but now I do. :)

It there a point in your code where it is possible to extract AST and pass it to my compiler's backend for a code generation? I'd like to give it a try.

i686 support?

I can't build on my Ubuntu linux, and I think the reason is that you support x86_64 but not i686.

gtoal@linux:~/src/bic$ ls /usr/lib/gcc
i686-linux-gnu

By the way the build fails in a way that isn't obvious what the cause is - a "cd" failure into non-existent directory i686 in src. (I did try symbolically linking that to x86_64 but that was too trivial a workaround and failed as soon as it started assembling)

Great project, I will have lots of uses for it once it compiles. I used a very similar system with an Algol-like language back in 1977 ( http://history.dcs.ed.ac.uk/archive/os/emas/users/ecslib/emas-a/impis-unpacked/intdoc.txt ) and it has been a frustration that there was nothing equivalent in all the years since. My primary use for it will be to convert a static binary translator (which generates C code from 6809, 6502 or z80 binaries) into a dynamic recompiler. It will need one modification to your system to support but we can discuss that once I have a running bic system!

Graham

`bic -l m`, cannot open library: Invalid ELF header

Can't use the sin() function from math.h, because libm cannot be loaded.

bic -l m

Output:

Error: could not open library m: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

System Info:

Distro Information:
    Distributor ID      Ubuntu
    Description         Ubuntu 18.04.3 LTS
    Release             18.04
    Codename            bionic

Linux/Kernel Information:
    Linux 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Allow absolute path for library files.

I noticed that any library file I use has to be located in the system/global directory. Things like -l ./libforme.so are not allowed. -l forme is not allowed either if the file is in the current directory. It would be nice to at least allow an absolute path to the libraries that are loaded.

I'm having other issues with libraries. I'll probably post another report for those.

Can't build on arch linux.

checking for ptrdiff_t... yes
./configure: line 13064: syntax error near unexpected token `,'
./configure: line 13064: `AX_CXX_COMPILE_STDCXX_11(, mandatory)'

sizeof(*x) not supported

$ cat foo.c
void *malloc(unsigned long size);

int main() {
    int *x;
    x = malloc(sizeof(*x));
    return x ? 0 : -1;
}
$ ./src/bic foo.c
Parser Error: <stdin>:5 syntax error, unexpected '*'.

Allow parsing source files with no main().

I'm just following up on a comment I made in issue #16. Remove the main restriction on parsing C files, and ignore the first line of a file if it starts with "#!" (actually the shell may already remove this line on Linux. Edit: It doesn't, I checked). This opens up a whole new door for using pre-written functions, and allows C files to be "executed" with bic from the command line (./myfile.c would be opened by bic, which would parse and run the code).

Sorry, no pull request yet. I just wanted to put this idea on the list, in case anyone else was looking for an awesome feature to add to bic.

Failure when running `./configure`

Context: x86_64 Void Linux; bic commit 455ad8a

After doing autoreconf -i and then running ./configure --enable-debug, configure eventually fails with:

checking for size_t... (cached) yes
checking for uint16_t... yes
checking for uint32_t... yes
checking for uint8_t... yes
checking for ptrdiff_t... yes
./configure: 17641: ./configure: Syntax error: word unexpected (expecting ")")

failed to make on raspbian with raspberry 4

the error message is:

make all-recursive
make[3]: Entering directory '/home/pi/workspace/bic/src'
Making all in armv7l
/bin/bash: line 20: cd: armv7l: No such file or directory
make[3]: *** [Makefile:938: all-recursive] Error 1
make[3]: Leaving directory '/home/pi/workspace/bic/src'
make[2]: *** [Makefile:478: all] Error 2
make[2]: Leaving directory '/home/pi/workspace/bic/src'
make[1]: *** [Makefile:409: all-recursive] Error 1
make[1]: Leaving directory '/home/pi/workspace/bic'
make: *** [Makefile:341: all] Error 2

any idea? thanks!

Issue with defining and setting char pointer on one line

I was just messing around with this tool. It's really neat, thanks for making it! I noticed this:

This works just fine:

BIC> #include <stdio.h>
BIC> char *s;
s
BIC> s = "test\n";
BIC> printf(s);
test
5

This blows up:

BIC> #include <stdio.h>
BIC> char *s = "test\n";
<stdin>:2:9: error: Not a valid lvalue.
Evaluator Backtrace
===================

<tree E_CTX tECTX_IS_STATIC: false
      tECTX_IS_FN_CALL: false
      tECTX_PARENT_CTX:   <null>

      tECTX_ALLOC_CHAIN:
  <chain
    <tree E_ALLOC tALLOC_PTR: 0x5561f33c9250>
  >
      tECTX_RETVAL:   <null>

      tECTX_JMP_BUF:
      tECTX_ID_MAP:
  <chain
    <tree E_MAP tEMAP_RIGHT:
      <tree D_T_INT>
          tEMAP_LEFT:
      <tree T_IDENTIFIER tID_STR: "__builtin_va_list">
    >
    <tree E_MAP tEMAP_RIGHT:
      <tree T_LIVE_VAR tLV_IS_ARRAY: false
            tLV_ARRAY_SZ: 0
            tLV_TYPE:
        <tree D_T_PTR tDTPTR_EXP:
          <tree D_T_CHAR>
        >
            tLV_VAL: <Unprintable>
      >
          tEMAP_LEFT:
      <tree T_IDENTIFIER tID_STR: "s">
    >
  >
      tECTX_NAME:
  <tree T_IDENTIFIER tID_STR: "Toplevel">
>

Cygwin support?

Is it completely impossible to build it in cygwin environment? As a workaround I'll be happy to build just parser with cygwin, but it would be just a hack...

C-style comments not supported

$ cat foo.c
/* Comment */
int main() {
    return 0;
}
$ ./src/bic foo.c
Parser Error: <stdin>:1 syntax error, unexpected '/'.

Allow function definitions within the REPL

Perhaps I'm just not using bic correctly, but it would be great to allow function definitions in the REPL.

Also, are for loops and conditionals supported?

Mod result is wrong for negative numbers.

Simplest way to reproduce:

$ bic -v
This is bic v0.9.1.

Enabled Features:

   tree-check: no
$ bic
(ins)BIC> -1 % 3;
2
(ins)BIC> ⏎

I installed this morning from the AUR. cling, gcc and tcc both agree that -1 % 3 should be -1.

[cling]$ -1 % 3
(int) -1
[cling]$ 

$ cat test.c
#include <stdio.h>
int main(int argc, char** argv) {
   printf("%d\n", -1 % 3);
}

$ make test
cc     test.c   -o test
$ ./test
-1
$ tcc -run test.c
-1

failed to install on Mac OS

I tried to follow steps on README

input:

brew install bison flex gmp readline autoconf-archive
autoreconf -i

output:

Can't exec "aclocal": No such file or directory at /usr/local/Cellar/autoconf/2.69/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory

I googled how to resolve it and I found that I should install automake

input:

brew install automake
autoreconf -i
YACC="$(brew --prefix bison)/bin/bison -y" ./configure --enable-debug

and I found suspicious line at log of configure command

output:

...
checking ... yes
./configure: line 7593: LT_SYS_SYMBOL_USCORE: command not found 
checking ... yes
...

anyway I kept going on

input:

make

output:

/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in x86_64
make[4]: Nothing to be done for `all'.
  CCLD     bic
Undefined symbols for architecture x86_64:
  "___do_call", referenced from:
      _do_call in libbic_x86_64.a(libbic_x86_64_a-function_call.o)
  "_entry_point_0", referenced from:
      _get_entry_point_for_fn in libbic_x86_64.a(libbic_x86_64_a-ptr_call.o)
      _next_entry_point in libbic_x86_64.a(libbic_x86_64_a-ptr_call.o)
  "_entry_point_1", referenced from:
      _get_entry_point_for_fn in libbic_x86_64.a(libbic_x86_64_a-ptr_call.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [bic] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Create a git tag, so github can generate a release

I want to create an Arch Linux package, but I will prefer a release to keep updating the package. When a tag is created, GitHub will generate tarballs.