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, according to locate.

Can you help me figure out what's going on here?
 
So you did install zziplib? What does pkg info -l zziplib say? I've been using the bundled zziplib, BTW.
 
And for a package that FreeBSD doesn't support (like inotify) what is the normal way to replace it? Or is there a workaround?
 
Inotify is a Linux kernel feature. See here for more
forums.freebsd.org

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 forums.freebsd.org
 
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?
 
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.
 
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.
 
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?
Click to expand...
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.
Click to expand...
Fair nuff. Don't you want to find out if it compiles and maybe even runs, though? Don't forget to use gmake.
 
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?
 
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.
Click to expand...
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.
 
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?
Click to expand...
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.
 
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.
Click to expand...

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
 
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?
 
xsundevil said:
#include <byteswap.h>
compilation terminated.
Click to expand...
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.
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
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?
Click to expand...
Are you volunteering?
 
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.
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

Are you volunteering?
Click to expand...
I would if I could! :)
 
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?
 
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?
Click to expand...
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
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
 
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
Click to expand...
 
xsundevil said:
Don't you need the "--" before the flags, though?
Click to expand...
There are three different things going on in that command line
  1. 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.
  2. I'm invoking the configure script
  3. 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
Code: 
#!/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
 
Code: 
--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
Code: 
--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.
Code: 
--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.
 
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]
In file included from /usr/src/contrib/ofed/include/byteswap.h:35:0,
from ../mstl/m_byte_order.ipp:19,
from ../mstl/m_byte_order.h:49,
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 db_board.cpp:34:
db_board.cpp: In member function 'bool db::Board::neitherPlayerHasMatingMaterial(db::variant::Type) const':
db_board.cpp:7301:41: error: 'struct db::material::Count' has no member named '__minor'
if (wtotal == 2 && btotal == 1 && wmat.minor() == 1)
^
db_board.cpp:7304:41: error: 'struct db::material::Count' has no member named '__minor'
if (btotal == 2 && wtotal == 1 && bmat.minor() == 1)
^
db_board.cpp: In member function 'bool db::Board::cannotWin(db::color::ID, db::variant::Type) const':
db_board.cpp:7331:32: error: 'struct db::material::Count' has no member named '__minor'
return total == 2 && material.minor() == 1;
^
db_board.cpp:7332:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
gmake[2]: *** [Makefile:162: db_board.o] Error 1
gmake[1]: *** [Makefile:205: recursive] Error 1
gmake: *** [Makefile:20: all] Error 2
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]
In file included from /usr/src/contrib/ofed/include/byteswap.h:35:0,
from ../mstl/m_byte_order.ipp:19,
from ../mstl/m_byte_order.h:49,
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 db_board.cpp:34:
db_board.cpp: In member function 'bool db::Board::neitherPlayerHasMatingMaterial(db::variant::Type) const':
db_board.cpp:7301:41: error: 'struct db::material::Count' has no member named '__minor'
if (wtotal == 2 && btotal == 1 && wmat.minor() == 1)
^
db_board.cpp:7304:41: error: 'struct db::material::Count' has no member named '__minor'
if (btotal == 2 && wtotal == 1 && bmat.minor() == 1)
^
db_board.cpp: In member function 'bool db::Board::cannotWin(db::color::ID, db::variant::Type) const':
db_board.cpp:7331:32: error: 'struct db::material::Count' has no member named '__minor'
return total == 2 && material.minor() == 1;
^
db_board.cpp:7332:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
gmake[2]: *** [Makefile:162: db_board.o] Error 1
gmake[1]: *** [Makefile:205: recursive] Error 1
gmake: *** [Makefile:20: all] Error 2
Click to expand...
 
You must log in or register to reply here.
Back
Top