# Building GCC



## xsundevil (Apr 27, 2021)

After you run gmake you get a lot of stdout output.  I'm actually getting errors trying to build gcc7.3.  And in order for me to ask for help I need to know whether all this gmake output gets logged somewhere and, if so, where.  Or is it just enough to copy just the last several lines where the word error starts to come up?

Just FYI, gmake runs for a really long time, but at the very end when it appears to be wrapping things up it exits with a #2 error.

I'd really appreciate if you could help me out with this.  Thank you in advance.


----------



## SirDice (Apr 27, 2021)

xsundevil said:


> After you run gmake you get a lot of stdout output. I'm actually getting errors trying to build gcc7.3.


Why are you building this from source? We have plenty of versions to choose from:
lang/gcc48 (deprecated), lang/gcc6 (expired), lang/gcc7 (deprecated), lang/gcc8, lang/gcc9, lang/gcc10



xsundevil said:


> And in order for me to ask for help I need to know whether all this gmake output gets logged somewhere and, if so, where.


It doesn't. Learn to use script(1) or shell output redirection. 



xsundevil said:


> Or is it just enough to copy just the last several lines where the word error starts to come up?


No, the actual cause of the error may be a lot further up.


----------



## xsundevil (Apr 27, 2021)

I'm actually trying to install a chess program.  The developer recommends gcc7.3.  Version 8 didn't work for him.  I tried version 10 and I got an error message that this version is not working.

Now that you mention that, I did run pkg search gcc and I think I just got hits for a couple of versions (8 and 10, IIRC), but definitely not all of the versions that you listed.


----------



## kpedersen (Apr 27, 2021)

I recently put together a script to build GCC 9.x

You might find it useful: https://github.com/osen/mdcc/blob/main/build.sh#L81

Just note, unless you are interested in the m68k architecture, you will likely need a few different flags.

Edit: Also, there is usually a script to bootstrap all the little GNU dependencies needed to build it. I downloaded them manually and added them to the repo. Likely your build is failing because you are missing these. The part of the script that extracts them is here.


----------



## SirDice (Apr 27, 2021)

xsundevil said:


> I did run pkg search gcc and I think I just got hits for a couple of versions (8 and 10, IIRC), but definitely not all of the versions that you listed.


Everything except GCC 6 is still be available, 4.8 and 7 are deprecated (not supported upstream anymore and may be removed soon) but should still be available.


----------



## bobmc (Apr 28, 2021)

Could the host platform make a difference.  For example, GCC cross-compiled for MSYS on windows may have patches for that environment that make the application flaky in a better system.


----------



## xsundevil (Apr 28, 2021)

I figured it out.  It was just a matter of linking to the right gcc version from /usr/bin.  I did try that earlier, but from so much trying with different versions I got confused and never did try linking to the old gcc 4.8.

Thank you for all your help, though.


----------



## datasmurf (Apr 28, 2021)

```
pkg install gcc6-aux-20180516_2,1
cd /to/src/of/Scidb
export PATH="$PATH:/usr/local/gcc6-aux/bin"
```

For *other* gcc Version use the following Variables Set them before ./configure runs.


```
export CC=gcc9
export CXX=g++9
export AR=gcc-ar9
```

`./configure --help`

Shows more Environmental Variables that can be set, btw.



Most likely you will also need to set


```
export CXXFLAGS=-fpermissive
export CPATH=/usr/src/sys/cddl/contrib/opensolaris/uts/common:/usr/src/contrib/ofed/include:/usr/src/cddl/compat/opensolaris/include
```

Anyway, _for me_ compiling Scidb[1] ends in


```
Compiling m_file.cpp                      [-fpermissive -g]                                                                                                                         
m_file.cpp: In destructor 'virtual mstl::bits::file::~file()':                       
m_file.cpp:50:27: error: cannot convert '_IO_FILE*' to 'FILE* {aka __sFILE*}' for argument '1' to 'int fileno(FILE*)'                                                               
  if (m_open && fileno(m_fp) > 2)                                                                                                                                                   
                           ^
```

with gcc7.5, gcc10, gcc4.8, gcc9.

So ... Good luck.  Maybe it would compile on GNU/Linux Distro of your choice and then run it with Linuxlator?

[1] http://scidb.sourceforge.net/index.html


----------



## xsundevil (Apr 28, 2021)

That was an awesome reply, thank you.  I'll definitely try that.

Question #1:  So, you don't think I'll be able to set up on a FreeBSD system?

Question #2: configure starts out by displaying the Tcl/Tk version (8.6).  Later it lists the locations of both tcl.h and tk.h as not found.  Also,  Tcl and Tk libraries are listed as blank and not found, respectively.

I ran locate and found them easily in /usr/local/include/tk8.7 and /usr/.../tcl8.7.

locate also revealed that in /path/to/Scicdb/src/tk/tcl8.7 there are some header files, but tcl.h and tk.h are missing.

What does this all mean?

Question #3: configure complains that freetype2 is missing, but pkg says that "the most recent versions of packages are already installed".

whereis finds freetype2 in /usr/ports/print/freetype2.

So, my question is the same, what does this all mean?  Is it the way FreeBSD is set up?

Thank you in advance!


----------



## datasmurf (Apr 28, 2021)

> Question #2: configure starts out by displaying the Tcl/Tk version (8.6).  Later it lists.....



First, you should start with unpacking the source archive again, so you can work in a "clean" environment. 

Then set the Compiler Variables and _then_ run `./configure`. You will also need some C Headers that are found in 
*/usr/src - *so download and extract src.txz from the FTP Server if don't have them already.



> Question #1: So, you don't think I'll be able to set up on a FreeBSD system?



I couldn't. Best would be to forward the final error message to the dev, maybe he/she can provide a patch.

Also, don't forget that you have to use `gmake` instead of `make` to start the build.


----------



## richardtoohey2 (Apr 28, 2021)

xsundevil said:


> Question #2: configure starts out by displaying the Tcl/Tk version (8.6). Later it lists the locations of both tcl.h and tk.h as not found. Also, Tcl and Tk libraries are listed as blank and not found, respectively.
> 
> I ran locate and found them easily in /usr/local/include/tk8.7 and /usr/.../tcl8.7.


I _think_ you'll need the -I (i for igloo) and -L options to tell the compiler and linker where to find headers (I for include) and libraries (L for libraries).  I'm a bit rusty.


```
-I<directory>
              Add the specified directory to the search path for include
              files.
```


```
-L dir, --library-path=dir
             Add a directory to the library search path.
```

Source code for other OSs will assume certain locations, so if compiling on FreeBSD you need to give more clues to the compiler/linker.

See section 13.10 https://docs.freebsd.org/en/books/porters-handbook/porting-dads/#dads-cflags - just has examples of those two flags.


----------



## Jose (Apr 28, 2021)

I got it to compile with clang from base, but it was fairly unpleasant and required some code changes. I can throw these up somewhere if you like. To give you a flavor of the unpleasantness, this is the configure command line I had to use

```
SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat" SYS_CFLAGS="-I/usr/local/include" SYS_CXXFLAGS="-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common" ./configure --gcc-version=clang
```


----------



## zirias@ (Apr 28, 2021)

Jose said:


> To give you a flavor of the unpleasantness


That still looks somehow "clear" 

At some time in the past, I needed to build a GCC5 targeting Linux to get a correctly working MakeMKV, which looked like this:





						[ports] Contents of /head/multimedia/makemkv/Makefile
					






					svnweb.freebsd.org
				



Yes, three steps with parts of glibc in between 

GCC is often a beast to build. It's nice to have ports where everything is already figured out; if you just need a GCC targeting FreeBSD, use these 

Side note: Code that needs a specific compiler (as opposed to a specific version of standard C or C++) should be forbidden. Code that works with an older version of a compiler, but not a newer one, is likely broken and should be fixed…


----------



## Jose (Apr 28, 2021)

Oh, this one is a doozy. I stopped counting the warnings. It rewarded my efforts of getting it to compile with linker errors, natch. I'm still not exactly sure how I got it to link, and I'm not at all sure it runs (gives me prompt that doesn't know about "help" or "usage"), but something does run. The Tk version launches an empty window and the inscrutable prompt.


----------



## Jose (Apr 28, 2021)

These are the changes, if you're interested
https://gitlab.com/jose1234567/scidb-code/-/commit/2388d9ba4f4536e0fb7d600230bf2edc6f005548


----------



## kpedersen (Apr 28, 2021)

Its odd, GCC 9 I found compiled quite straight forward with CC=clang

Granted, I disable as much as I can 


```
../configure \
    --target=m68k-elf \
    --prefix="$PREFIX" \
    --with-newlib \
    --disable-libssp \
    --disable-tls \
    --enable-threads=single \
    --enable-languages=c \
    --disable-lto \
    --with-cpu=m68000 \
    --disable-werror \
    --disable-nls \
    --disable-multilib
```

Disabling LTO was purely to avoid longish compile times for Mega Drive games that really don't need it!

Painful amount of warnings however...


----------



## xsundevil (Apr 29, 2021)

richardtoohey2 said:


> I _think_ you'll need the -I (i for igloo) and -L options to tell the compiler and linker where to find headers (I for include) and libraries (L for libraries).  I'm a bit rusty.
> 
> 
> ```
> ...


richardtoohey2 but if there are header files in /path/to/Scicdb/src/tk/tcl8.7, how come the tcl.h and tk.h are missing?  Are they supposed to not be in such directory?


----------



## richardtoohey2 (Apr 29, 2021)

xsundevil said:


> richardtoohey2 but if there are header files in /path/to/Scicdb/src/tk/tcl8.7, how come the tcl.h and tk.h are missing?  Are they supposed to not be in such directory?


I was replying to this bit of your post - so it sounded like it couldn't find include files or libraries - so -I and -L _might_ help:
_
Later it lists the locations of both tcl.h and tk.h as not found.  Also,  Tcl and Tk libraries are listed as blank and not found, respectively.

I ran locate and found them easily in /usr/local/include/tk8.7 and /usr/.../tcl8.7._


----------



## Jose (Apr 29, 2021)

datasmurf said:


> Anyway, _for me_ compiling Scidb[1] ends in
> 
> 
> ```
> ...


This fixes that error
https://gitlab.com/jose1234567/scid...5548#c02312fe201cc4740c80df8090602da4729271c6


----------



## xsundevil (Apr 29, 2021)

There is no option listed in the configure help file to give it the path to freetype2 and inotify.  What does one do in this situation?


----------



## Jose (Apr 29, 2021)

I have it installed from packages. `pkg install freetype2`


----------



## xsundevil (Apr 29, 2021)

Yeah, I meant, if there's no option for freetype2 (like there's for Tcl/Tk), how do you help ./configure find freetype2 (that you have installed from packages).


----------



## Jose (Apr 29, 2021)

Looks like another bug in the configure script
https://gitlab.com/jose1234567/scid...bab3#09be8533ff0a6ee5d577f971145ed449399fcda4


----------



## xsundevil (Apr 29, 2021)

Sort of unbelievable - how come other people didn't come across this bug?  But, thank you for that!  I'll try this bug fix as soon as I get back from work.


----------



## Jose (Apr 29, 2021)

xsundevil said:


> Sort of unbelievable - how come other people didn't come across this bug?  But, thank you for that!  I'll try this bug fix as soon as I get back from work.


It gives me the heebie-jeebies too... Also, it's building differently now. It has decided to update some files in the man directory, and I think it's building a different set of binaries. I'll confirm the latter if I get time.


----------



## xsundevil (Apr 30, 2021)

With _whereis_ I can find zziplib (in /usr/ports/devel/zziplib).  The _configure_ script doesn't find it (as usual).  The obvious next step was to install the zziplib package, which does exist, but _whereis_ still returns /usr/ports/devel/zziplib.  And no other traces of zziplib exist on my system, according to _locate_.

Can you help me figure out what's going on here?


----------



## Jose (Apr 30, 2021)

So you did install zziplib? What does `pkg info -l zziplib` say? I've been using the bundled zziplib, BTW.


----------



## xsundevil (Apr 30, 2021)

And for a package that FreeBSD doesn't support (like inotify) what is the normal way to replace it?  Or is there a workaround?


----------



## Jose (Apr 30, 2021)

Inotify is a Linux kernel feature. See here for more








						iNotify for FreeBSD?
					

Is there an iNotify for FreeBSD?  Kqueue has to open every directory it watches, so too many directories will run it out of the max number of open files (typically 1024).  That would never work on a web server.  Thanks!




					forums.freebsd.org


----------



## xsundevil (Apr 30, 2021)

What is the right process to make the _configure_ program detect libinotify?  _configure_ seems to be looking for files named testinotify.c and inotify.h.

I know that libinotify is just an API to help port linux software to FreeBSD, but what changes are necessary for my system to pass the inotify test?


----------



## Jose (Apr 30, 2021)

Configure does a bunch of things, including executing a shell script that tries to compile a short program that calls inotify.  Look for TestInotify and SystemHasInotify. That code starts around line 1022 in my version of configure.

It looks like all it does at the end of the day is add `-DHAVE_INOTIFY` to CFLAGS (and maybe CXXFLAGS). You could try setting that directly in the configure invocation using SYS_CFLAGS and SYS_CXXFLAGS. I doubt the code will compile without modification, but I could be wrong.

Why do you think you need inotify? It's ok to not pass every configure check. You actually can't pass every configure check in more complex projects that use autotools. Some of the checks are for things that exclude each other.


----------



## xsundevil (Apr 30, 2021)

It runs a check on many things including inotify, but _configure_ does not find it.  In the next paragph, a message appears with the words "insane system", which I thought it was because of it not being able to find iNotify - but I was just guessing.  Need to acquire more experience.  What does insane system refer to exactly?

You're right.  iNotify doesn't sound like a crucial piece of software for Scidb to install or to run right.  I might just end up going without iNotify, but since libinotify interface is available it doesn't hurt to try a few times to see if I can get it to work with Scidb.  Also, getting libinotify to work in this project might prove useful in future ones.


----------



## Jose (Apr 30, 2021)

xsundevil said:


> It runs a check on many things including inotify, but _configure_ does not find it.  In the next paragph, a message appears with the words "insane system", which I thought it was because of it not being able to find iNotify - but I was just guessing.  Need to acquire more experience.  What does insane system refer to exactly?


It has something to do with some Linux tracing functionality the author deems critical. You know what they say about opinions...


xsundevil said:


> You're right.  iNotify doesn't sound like a crucial piece of software for Scidb to install or to run right.  I might just end up going without iNotify, but since libinotify interface is available it doesn't hurt to try a few times to see if I can get it to work with Scidb.  Also, getting libinotify to work in this project might prove useful in future ones.


Fair nuff. Don't you want to find out if it compiles and maybe even runs, though? Don't forget to use gmake.


----------



## xsundevil (Apr 30, 2021)

m_byte_order.ipp is a filename google doesn't know.  The file includes a couple of include directives that can't be just commented out.

The .h files are byteswap.h and endian.h.

How do we get around such an obstacle?


----------



## xsundevil (Apr 30, 2021)

ralphbsz said:


> What are you trying to accomplish?
> 
> Are you trying to port some software from another OS (Linux?) to FreeBSD?
> 
> Does that software have some prerequisites?  Obsigna already gave the answer indirectly:  there are several dozen versions of "byteswap.h" around, part of wildly different implementations of detecting byte order and byte swapping.  If you want to make your code more standard compliant, it might be a good idea to find out what the "idiomatic" way of byte swapping is.  Personally, I've always used the ntoh() and hton() family of functions, but I'm not really sure that this is the right thing.  Posix seems silent on it.


I found this message on this forum in another thread.  What the poster said might give you a clue.  This is a bit advanced for me at this point.


----------



## Jose (Apr 30, 2021)

xsundevil said:


> m_byte_order.ipp is a filename google doesn't know.  The file includes a couple of include directives that can't be just commented out.
> 
> The .h files are byteswap.h and endian.h.
> 
> How do we get around such an obstacle?


I'm sorry, but I need more context. That file compiled just fine for me. Is it not compiling for you? If so, post the error.


----------



## xsundevil (Apr 30, 2021)

Jose said:


> I'm sorry, but I need more context. That file compiled just fine for me. Is it not compiling for you? If so, post the error.



gmake[1]: 'scidb-beta.1.gz' is up to date.
In file included from ../mstl/m_byte_order.h:49:0,
    from ../util/u_crc.ipp:19,
    from ../util/u_crc.h:41,
    from ./db_move.h:36,
    from ./db_move_list.h:30,
    from ./db_board.h:34,
    from cql/cql_designator.cpp:29:
..mstl/m_by_order.ipp:19:22: fatal error: byteswap.h: No such file or directory
#include <byteswap.h>
compilation terminated.

Compiling cql/cql_common.cpp              [-Wall -g -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]
Compiling cql/cql_designator.cpp          [-Wall -g -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]

gmake[2]: *** [Makefile:162]: cql/cql_designator.o] Error 1
gmake[1]: *** [Makefile:205]: recursive] Error 1
gmake: *** [Makefile:20: all] Error 2


----------



## xsundevil (May 1, 2021)

I was just thinking, how come nobody's taken up the job of building a Scidb package for FreeBSD?  Is it because it's a lot of hard work or because of business reasons?


----------



## Jose (May 1, 2021)

xsundevil said:


> #include <byteswap.h>
> compilation terminated.


That file lives at /usr/src/contrib/ofed/include on my system. That should be on the include path if you used the config invocation I recommend.

```
SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat" \
SYS_CFLAGS="-I/usr/local/include" \
SYS_CXXFLAGS="-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include \
-I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common" \
./configure --gcc-version=clang
```



xsundevil said:


> I was just thinking, how come nobody's taken up the job of building a Scidb package for FreeBSD?  Is it because it's a lot of hard work or because of business reasons?


Are you volunteering?


----------



## xsundevil (May 1, 2021)

Jose said:


> That file lives at /usr/src/contrib/ofed/include on my system. That should be on the include path if you used the config invocation I recommend.
> 
> ```
> SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat" \
> ...


I would if I could!


----------



## Jose (May 1, 2021)

xsundevil said:


> I would if I could!


Why can't you? Start here https://docs.freebsd.org/en/books/porters-handbook


----------



## xsundevil (May 1, 2021)

Actually. I just stumbled on that page while I was googling stuff about porting - some post by SirDice, I think.  It definitely looks like there's a lot of stuff to learn on there!  I'll get to it when I get the chance.

By the way, what does it mean when you give it all those parameters, but it acts like you didn't?  I typed in all flags that you gave me and it worked the first time, but, it refuses to work again!  I even tried unpacking the source again and running gmake clean.  Have you ever had this happen?


----------



## Jose (May 1, 2021)

xsundevil said:


> Actually. I just stumbled on that page while I was googling stuff about porting - some post by SirDice, I think.  It definitely looks like there's a lot of stuff to learn on there!  I'll get to it when I get the chance.
> 
> By the way, what does it mean when you give it all those parameters, but it acts like you didn't?  I typed in all flags that you gave me and it worked the first time, but, it refuses to work again!  I even tried unpacking the source again and running gmake clean.  Have you ever had this happen?


Not with this kind of handmade configure, no. Autotools configure scripts cache the results of the tests and sometimes you have to clear the results, but that can't be a problem here (not using Autotools).

Does configure give any output when it "acts like you didn't (give it any parameters)"?

Try copy-pasting this entire block of text into your terminal

```
SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat" \
SYS_CFLAGS="-I/usr/local/include" \
SYS_CXXFLAGS="-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include \
-I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common" \
./configure --gcc-version=clang
```


----------



## xsundevil (May 1, 2021)

Don't you need the "--" before the flags, though?


----------



## xsundevil (May 1, 2021)

I'm doing this:
Is there a difference?


> ./configure --tcl-includes=/usr/local/include/tcl8.7 --tk-includes=/usr/local/include/tk8.7 --tcl-libraries=/usr/local/lib/tcl8.7 --tk-libraries=/usr/local/lib/tk8.7 --with-zziplib-inc=/usr/local/include/zziplib --with-zziplib-lib=/usr/local/lib --SYS_LDFLAGS=-L/usr/local/lib -lexecinfo -lcompat --SYS_CFLAGS=-I/usr/local/include --SYS_CXXFLAGS=-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common


----------



## Jose (May 1, 2021)

xsundevil said:


> Don't you need the "--" before the flags, though?


There are three different things going on in that command line

I'm setting 3 of environment variables for the environment in which the "configure" script will run. These are SYS_LDFLAGS, SYS_CFLAGS, and SYS_CXXFLAGS.
I'm invoking the configure script
I'm passing `--gcc-version=clang` command-line argument to the configure script
To answer your question, only the command-line argument needs to be prefixed with "--". There's unfortunately no standard for when you have to use "--" or "-". I'm assigning a value to a variable in the line `SYS_CFLAGS="-I/usr/local/include"` so no dashes are needed. It so happens that the SYS_CFLAGS variable now contains a flag that will be passed to the C compiler later, but this is not always the case when you're setting environment variables.

It would perhaps be clearer if I wrote it out as a shell script

```
#!/bin/sh

SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat"
SYS_CFLAGS="-I/usr/local/include"
SYS_CXXFLAGS="-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include"
SYS_CXXFLAGS="$SYS_CXXFLAGS -I/usr/src/contrib/ofed/include"
SYS_CXXFLAGS="$SYS_CXXFLAGS -I/usr/src/sys/cddl/contrib/opensolaris/uts/common"

./configure --gcc-version=clang
```


----------



## Jose (May 1, 2021)

```
--tcl-includes=/usr/local/include/tcl8.7 --tk-includes=/usr/local/include/tk8.7 --tcl-libraries=/usr/local/lib/tcl8.7 --tk-libraries=/usr/local/lib/tk8.7
```
The configure script found the Tcl 8.6 installation on my system without this

```
--with-zziplib-inc=/usr/local/include/zziplib --with-zziplib-lib=/usr/local/lib
```
I didn't bother installing zziplib on my system. The bundled version seems to work.

```
--SYS_LDFLAGS=...
```
This might work with Tcl. I'm not super experienced with Tcl scripts. This is my very first time looking at Tcl source

You're not passing `--gcc-version=clang` which means you're likely still compiling with gcc. This might make a difference.


----------



## xsundevil (May 1, 2021)

I get errors:
SYS_LDFLAGS=-L/usr/local/lib -lexecinfo -lcompat: Command not found.

Wrong shell?


----------



## Jose (May 1, 2021)

You forgot the quotes, but yeah, this style of setting environment variables only works for Bourne and Korn shells. See here





						Unix Shells: Bash, Fish, Ksh, Tcsh, Zsh - Hyperpolyglot
					






					hyperpolyglot.org


----------



## xsundevil (May 1, 2021)

Yeah, I figured it out.  I just didn't know they were environment variables.  So I just did _setenv_ VAR setting, etc.

This is where I left off before I encountered the issue with the variables.  Are you familiar with it?


> Compiling cql/cql_position.cpp            [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]
> Compiling cql/cql_relation.cpp            [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]
> Compiling db_annotation.cpp               [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]
> Compiling db_board.cpp                    [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.7 -DSCI_NAMEBASE_FIX=1]
> ...


----------



## Jose (May 1, 2021)

Nope. Compiles just fine for me

```
Compiling db_annotation.cpp               [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.6 -DSCI_NAMEBASE_FIX=1] 
Compiling db_board.cpp                    [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.6 -DSCI_NAMEBASE_FIX=1] 
Compiling db_board_base.cpp               [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.6 -DSCI_NAMEBASE_FIX=1] 
Compiling db_bpgn_reader.cpp              [-Wall -g -D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include -I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/local/include/tcl8.6 -DSCI_NAMEBASE_FIX=1]
```


----------



## xsundevil (May 2, 2021)

Running _gmake_ with the d option revealed that the problem is, indeed, db_board.o.

_gmake_ starts out by considering target file 'db_board.o'.  Then, outputs the line 'db_board.o' does not exist'.  Next, it tries to look for an implicit rule for it looking at several 'db_board' files.  Finishes up by saying that it found an implicit rule for it.  Later on in the compilation process, it comes back to 'db_board.o' after pruning '../mstl/m_stdio.h' and saying "finished prerequisites of target file 'db_board.o, must remake target db_board.o'."

After printing out lines like 'putting child db_board.o PID 2887 on the chain' and 'compiling db_board.cpp' it gets down to the very specifics of 'db_board.cpp' and says that it can't find a member function.

This leads me to believe that it could be the compiler, as you already said.  But, after giving it clang with the --gcc-version option ./configure can't run it.  It finds it because it says:

"Checking if your system has clang installed: yes, but existing clang version 10.0 is too old.

The required version is 3.1 and higher".

But, it doesn't make sense.  Do you know what this is about?


----------



## Jose (May 2, 2021)

xsundevil said:


> But, it doesn't make sense.  Do you know what this is about?


Yes. I couldn't fix the clang check, so I just disabled it. It would detect clang just fine, but die on clang++ for reasons I didn't care to investigate. This is where I disable the clang check:
https://gitlab.com/jose1234567/scid...533ff0a6ee5d577f971145ed449399fcda4_1615_1615


----------



## xsundevil (May 2, 2021)

Okay, I keep making more and more progress.

_gmake_ went on for a while, but stopped on a file not found error (alloca.h).
_locate_ tells me it's in /usr/src/cddl/compat/opensolaris/include and /usr/src/contrib/ofed/libibverbs, which is pretty close to the paths we give to the environment variables.

To which variable should I give this path (which of the two) and, also, will it make a difference?


----------



## Jose (May 2, 2021)

You don't need that file on Freebsd. This part disables including it:
https://gitlab.com/jose1234567/scid...5548#95b2e2b923926f3f57fa721402f4e4d9edbc3d70


----------



## xsundevil (May 2, 2021)

I just removed m_file.cpp from src/mstl/Makefile, but immediately got another error - this time it is tcl_engine.o.

In order to save time, do you have a list of files somewhere that are not needed in FreeBSD systems?

Thanks in advance.


----------



## Jose (May 2, 2021)

xsundevil said:


> I just removed m_file.cpp from src/mstl/Makefile, but immediately got another error - this time it is tcl_engine.o.


You misunderstood me. You don't need alloca.h. You do need m_file.cpp.


xsundevil said:


> In order to save time, do you have a list of files somewhere that are not needed in FreeBSD systems?


Yes `git clone https://gitlab.com/jose1234567/scidb-code.git`


----------



## xsundevil (May 2, 2021)

For the m_file.cpp error, gmake gives Makefile:76:m_file.o in the end.  It says in the gmake output "no matching function for call to 'fileno'" many times.  I compared my src/mstl/Makefile to yours and their identical.  Now, I'm thinking that it could be the compiler version that I'm using, which is version 10.  Please, correct me if I'm wrong.


----------



## Jose (May 2, 2021)

xsundevil said:


> For the m_file.cpp error, gmake gives Makefile:76:m_file.o in the end.  It says in the gmake output "no matching function for call to 'fileno'" many times.  I compared my src/mstl/Makefile to yours and their identical.  Now, I'm thinking that it could be the compiler version that I'm using, which is version 10.  Please, correct me if I'm wrong.


I'm using clang10 as well:

```
clang --version                                                                                         
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
Target: x86_64-unknown-freebsd12.2
Thread model: posix
InstalledDir: /usr/bin
```
Try doing a `gmake clean all`.

The beauty of working inside a git(1) checkout is that you can find out what you've modified very quickly; git-status(1) will give you the list of modified files, and git-diff(1) will tell you exactly how they were modified.


----------



## xsundevil (May 2, 2021)

Started over by unpacking everything again, but the m_file.o error is still there.

Since we already established that it's most probably the compiler I ran "gmake clean all -d" to get the error message of the program called by gmake, but the output wasn't much different.

I still got [Makefile:76:m_file.o] Error 1.

Additionally, I got [Makefile:20:all] Error 2, which is the line,

SRC_CXX = \
    m_algorithm.cpp \
    m_assert.cpp \
    m_backtrace.cpp \
    m_bitfield128.cpp \
    m_bit_functions.cpp \
    m_bitset.cpp \
    m_bitset_iterator.cpp \
    m_byte_buf.cpp \
    m_equiv_classes.cpp \
    m_exception.cpp \
    m_file.cpp \
    m_fstream.cpp \
    m_hash.cpp \
    m_ifstream.cpp \
    m_ios.cpp \
    m_istream.cpp \
    m_match.cpp \
    m_ofstream.cpp \
    m_ostream.cpp \
    m_sstream.cpp \
    m_string.cpp \
    m_uint128.cpp \

Based on some google results, "Error 2" means that an include could be missing, but which one?


----------



## Jose (May 2, 2021)

I'm afraid we're at an impasse. I cannot reproduce your results. Here's what I did

```
rm -Rf scidb-code
git clone https://gitlab.com/jose1234567/scidb-code.git
cd scidb-code
SYS_LDFLAGS="-L/usr/local/lib -lexecinfo -lcompat" \
SYS_CFLAGS="-I/usr/local/include" \
SYS_CXXFLAGS="-D__BSD__ -D_LIBCPP_STDLIB_INCLUDE_NEXT -I/usr/local/include \
-I/usr/src/contrib/ofed/include -I/usr/src/sys/cddl/contrib/opensolaris/uts/common" \
./configure --gcc-version=clang
gmake
```
And it compiled just fine for me.

Edit: This is the output from the configure step for me

```
configure: Makefile configuration program for Scidb
    Tcl/Tk version: 8.6
    Your operating system is: FreeBSD 12.2-RELEASE-p6
                 Distributor: FreeBSD
                    Revision: 12.2
    Location of tcl.h: /usr/local/include/tcl8.6
    Location of tk.h: /usr/local/include/tk8.6
    Location of Tcl 8.6 library: /usr/local/lib
    Location of Tk 8.6 library: /usr/local/lib
    Location of X11/Xlib.h: /usr/local/include
    Location of X11 library: /usr/local/lib
    Location of Xcursor library: /usr/local/lib
    Location of fontconfig library: /usr/local/lib
    Checking your fontconfig version: 2.13
    Checking if your system has X11/SM/SM.h: yes.
    Checking if your system has fontconfig: yes.
    Checking if your system has freetype2: yes.
    Checking if your kernel has inotify support: no
    Checking if your system already has zlib installed: yes.
    Checking if your system already has zziplib installed: no.
      Using bundled library.
    Checking if your system already has expat installed: yes.
    Checking if your system already has gdbm installed: no.
      Using bundled library.

IMPORTANT NOTE:
-------------------------------------------------------------------------------
On this insane system debugging of own processes is not allowed due to the
kernel hardening paranoia. You might change this behaviour, see
<http://sourceforge.net/p/scidb/mailman/message/28418675/>, and then configure
again, otherwise you will not see useful error messages in case of internal
errors.
Makefile.in configured for your system was written.
Now just type "make" to compile Scidb.
```


----------



## xsundevil (May 2, 2021)

I just got the configure program to see my version of tcl/tk.  I'm recompiling to see what I get...


----------



## xsundevil (May 3, 2021)

xsundevil said:


> I just got the configure program to see my version of tcl/tk.  I'm recompiling to see what I get...



UPDATE:  I still obtained the same result ([Makefile:76: m_file.o] Error 1 and [Makefile:20: all] Error 2).

I'll google more and hope that I will get lucky and stumble on a solution.


----------



## xsundevil (May 4, 2021)

I just thought of something.  Is there something like a package that you could have installed to make FreeBSD systems more Linux-friendly?  Perhaps, something like this is what I need.

The reason I ask you this is because I remember hearing somewhere that FreeBSD doesn't use glibc.  In the gmake error, _IO_FILE comes up and _IO_FILE is defined in glibc.

Perhaps, you fixed this for a previous project, which helped you with Scidb?


----------



## Jose (May 4, 2021)

Correct, Freebsd has its own C library. I do have the Linux kernel modules loaded because the Nvidia driver requires them:

```
kldstat                                                                                                          
Id Refs Address                Size Name
 1   44 0xffffffff80200000  227ae98 kernel
 2    1 0xffffffff8247b000    27ce8 fuse.ko
 3    1 0xffffffff824a3000   175238 nvidia-modeset.ko
 4    4 0xffffffff82619000     d770 linux_common.ko
 5    3 0xffffffff82627000    b28f8 linux.ko
 6    2 0xffffffff826da000  1b4b490 nvidia.ko
 7    1 0xffffffff8451a000     1a20 fdescfs.ko
 8    1 0xffffffff8451c000     2698 intpm.ko
 9    1 0xffffffff8451f000      b40 smbus.ko
10    1 0xffffffff84520000     1860 uhid.ko
11    1 0xffffffff84522000     2908 ums.ko
12    1 0xffffffff84525000     1a40 wmt.ko
13    1 0xffffffff84527000     61d8 kgssapi_krb5.ko
14    1 0xffffffff8452e000     a900 kgssapi.ko
15    1 0xffffffff84539000      1e3 rc4.ko
16    1 0xffffffff8453a000      acf mac_ntpd.ko
```
But I don't have any of the Linux userland packages installed

```
pkg info | grep -i linux                                                                                         
libevdev-1.9.1.20200928        Linux Event Device library
libv4l-1.20.0                  Video4Linux library
linuxlibertine-g-20120116_2    Linux Libertine G and Linux Biolinum G fonts
py37-evdev-1.3.0               Bindings to the Linux input handling subsystem
```
I handle the absence of `_IO_FILE` in Freebsd here
https://gitlab.com/jose1234567/scid...5548#c02312fe201cc4740c80df8090602da4729271c6
I got that idea from the D language documentation


			FILE (core.stdc.stdio.FILE)


----------



## xsundevil (May 4, 2021)

In src/tk/treecontrol/Makefile there are a lot of paths hardcoded into the source.  For example, ../tk8.6/tkPort.h.  It's a long list.  Does this mean that it will only compile with version 8.6 and no other version?  It don't sound right to me.


----------



## Jose (May 4, 2021)

xsundevil said:


> In src/tk/treecontrol/Makefile there are a lot of paths hardcoded into the source.  For example, ../tk8.6/tkPort.h.  It's a long list.  Does this mean that it will only compile with version 8.6 and no other version?  It don't sound right to me.


Those are relative paths into the same source tree. Notice there are tcl8.5, tcl8.6, and tcl8.7 directories. It does seem like you'd have to edit that Makefile to make it work with a different version of tcl, though. That's not super great. The configure script should handle that.


----------



## xsundevil (May 4, 2021)

Hahah.  They always miss something


----------



## xsundevil (May 4, 2021)

I'm at the last stages.  At the build stage, (tkscidb-beta, I think it's called)  I get "Undefined symbol TclGetIntForIndex", or something along those lines.  I ran grep and found it in src/tk/tcl8.7/tclInt.h and tclIntDecls.h.

The header file IS being included in tkTreeCtrl.h.  It certainly looks like a missing include error.  Where else should tclInt.h (or tclIntDecls.h) be included?


----------



## xsundevil (May 4, 2021)

It might be pkg_config.  I'm investigating...


----------



## xsundevil (May 4, 2021)

I modified a couple of files, usr/util/libhyphenate/Makefile and ./configure.  I just changed pkg-config to pkgconfig, which resulted in:

/bin/sh: pkgconfig: not found (x4) (used to get /bin/sh: pkg-config: not found)

I just installed the pkgconfig package and it got placed in /usr/bin/local. 

What modifications do I have to make to help gmake or /bin/sh see pkgconfig?  And, also, could pkgconfig still be required even though we set the SYS flags at the beginning?


----------



## Jose (May 4, 2021)

No modifications since devel/pkgconf installed /usr/local/bin/pkg-config which is a symlink to pkgconf. The directory /usr/local/bin is in my PATH and should be in yours too.


----------



## xsundevil (May 4, 2021)

It's there by default, yes.  We know that "Undefined symbol" is a link-time error.  So, I need to add a path to the compiled version of the file where TclGetIntForIndex is defined, which, I think, happens in TclInt.h (and TclIntDecls.h).  How does one do that?  Where do the compiled versions of such files reside?


----------



## Jose (May 4, 2021)

Header (*.h) files are not used in the link step. They're only used in the compilation step. Missing linker symbols are caused by missing libraries in the linker invocation.

Correcting the linker flags required both changes to the configure script:
https://gitlab.com/jose1234567/scid...5548#09be8533ff0a6ee5d577f971145ed449399fcda4
and setting SYS_LDFLAGS:








						Building GCC
					

With whereis I can find zziplib (in /usr/ports/devel/zziplib).  The configure script doesn't find it (as usual).  The obvious next step was to install the zziplib package, which does exist, but whereis still returns /usr/ports/devel/zziplib.  And no other traces of zziplib exist on my system...




					forums.FreeBSD.org


----------



## xsundevil (May 4, 2021)

Jose said:


> Header (*.h) files are not used in the link step. They're only used in the compilation step. Missing linker symbols are caused by missing libraries in the linker invocation.
> 
> Correcting the linker flags required both changes to the configure script:
> https://gitlab.com/jose1234567/scid...5548#09be8533ff0a6ee5d577f971145ed449399fcda4
> ...


_gmake_ doesn't stop after the compile stage is complete and the link step begins.  The building process starts automatically.  So, how do you handle that?


----------



## Jose (May 4, 2021)

xsundevil said:


> _gmake_ doesn't stop after the compile stage is complete and the link step begins.  The building process starts automatically.  So, how do you handle that?


Of course not, build tools like make are supposed to handle invoking the compiler and the linker for you, and shouldn't stop until the entire build (and possibly tests) are finished (Edit: or fail.) The configure step is supposed to massage or generate the build tool's configuration files such that the compiler, linker and whatever else are invoked with the proper arguments for your system.

The handmade Tcl configure tool this project uses doesn't do a great job of this, as you've already discovered. I discovered that it does not generate the correct Tcl/Tk linker flags. See the diff above for details.


----------



## xsundevil (May 4, 2021)

You said above that the configure file needed to be amended.  Did you mean that, also, SYS_LDFLAGS needed changes or does it keep the setting you give it at the beginning?

Now, I'm getting errors at "Building cbh2si4".  Lots of errors such as "Tcl_CreateInterp, referenced by cb2si4.cpph73, cbh2si4.o Tclnterpreter::Tclnterpreter())"

And, "error: undefined symbol: Tcl_UniCharToLower, referenced by sys_utf8:ipp:172 (../sys/sys_utf8.ipp:172). U_match.osys::utf8::toLower(unsigned short)) in archive util/libutil.a.

Also, some errors referenced by sys_utf8.o, sys_file.o, 

By the way, are you figuring this out as we go?  I ask because it kind of feels like there could be a lot more errors to fix, but I wish I'm wrong.


----------



## Jose (May 5, 2021)

xsundevil said:


> You said above that the configure file needed to be amended.  Did you mean that, also, SYS_LDFLAGS needed changes or does it keep the setting you give it at the beginning?


You have to do both the configure script changes, and setting the SYS_LDFLAGS environment variable when you invoke configure. Both persist until configure is run again.


xsundevil said:


> Now, I'm getting errors at "Building cbh2si4".  Lots of errors such as "Tcl_CreateInterp, referenced by cb2si4.cpph73, cbh2si4.o Tclnterpreter::Tclnterpreter())"


Didn't get this one, probably because I used Tcl/Tk 8.6.


xsundevil said:


> And, "error: undefined symbol: Tcl_UniCharToLower, referenced by sys_utf8:ipp:172 (../sys/sys_utf8.ipp:172). U_match.osys::utf8::toLower(unsigned short)) in archive util/libutil.a.


That's interesting. I actually got duplicate symbol there, and I fixed it with the change in src/tk/text/tkTextPriv.h:
https://gitlab.com/jose1234567/scid...5548#341a6869b57ffd2b358f02540ab37bc5b89bf5d0
You may have to revert that change, but I'm guessing what's actually happening is you're not passing `-ltcl86` to the linker.


xsundevil said:


> Also, some errors referenced by sys_utf8.o, sys_file.o,


Probably not linking to libtcl86 here too.


xsundevil said:


> By the way, are you figuring this out as we go?  I ask because it kind of feels like there could be a lot more errors to fix, but I wish I'm wrong.


Nope. I got it to compile and link last Wednesday.


----------



## xsundevil (May 5, 2021)

Thank you for everything, Jose.

Mission: Accomplished.


----------

