Building GCC

Nope. Compiles just fine for me
Code: 
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]
 
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?
 
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?
 
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.
 
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.
 
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.
Click to expand...
I'm using clang10 as well:
Code: 
 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.
 
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? :-/
 
I'm afraid we're at an impasse. I cannot reproduce your results. Here's what I did
Code: 
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
Code: 
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 said:
I just got the configure program to see my version of tcl/tk. I'm recompiling to see what I get...
Click to expand...

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.
 
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?
 
Correct, Freebsd has its own C library. I do have the Linux kernel modules loaded because the Nvidia driver requires them:
Code: 
 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
Code: 
 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
 
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.
 
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.
Click to expand...
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.
 
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?
 
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?
 
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.
 
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?
 
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:
forums.FreeBSD.org

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 forums.FreeBSD.org
 
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
and setting SYS_LDFLAGS:
forums.FreeBSD.org

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 forums.FreeBSD.org
Click to expand...
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?
 
You must log in or register to reply here.
Back
Top