Public bug reported:
I am maintainer of the freebsd port of smartmontools. While trying to
update the port to the latest version i found a lot of build failures.
All this failures are looking as:
[ 2%] Building C object
cuneiform_src/Kern/ctb/CMakeFiles/ctb32.dir/src/ctb_oper.c.o
In file included from /usr/include/string.h:49,
from
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/ctb/src/ctb_oper.c:62:
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/hrstr/strings.h:101:
error: expected specifier-qualifier-list before 'uchar'
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/hrstr/strings.h:138:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'bNeedFreeString'
*** Error code 1
The real problem is that wrong strings.h is included from the system string.h
header. Reason is very simple - gcc searches all directories from -I/src/...
dirs and only then - system path. There is file names strings.h in the source
tree, so its included by mistake and this causing a build failure.
There are 2 possible workarounds for this - one is to use mine
workaround from the cuneiform_src/Kern/hhh/tigerh/h/c_types.h file:
/* solves conflict with bsd <strings.h> */
#if defined(__FreeBSD__)
#undef __BSD_VISIBLE
#endif
This way it force system strng.h not to include strings.h. The problem
is that in many source files <strings.h> is included *before* cuneiform
includes, so this will require to change include order of the all such
files, Another option (as for me - better one) is to rename strings.h to
something like cf_strings.h and also to change references in the
cuneiform files (it is used only in 1 or 2 headers). I think this is the
best case, because will prevent such problems in the feature. Please
tell me your opinion and i will do the patch.
** Affects: cuneiform-linux
Importance: Undecided
Status: New
--
build fail on freebsd because of strings.h include
https://bugs.launchpad.net/bugs/631207
You received this bug notification because you are a member of Cuneiform
Linux, which is the registrant for Cuneiform for Linux.
Status in Linux port of Cuneiform: New
Bug description:
I am maintainer of the freebsd port of smartmontools. While trying to update
the port to the latest version i found a lot of build failures. All this
failures are looking as:
[ 2%] Building C object
cuneiform_src/Kern/ctb/CMakeFiles/ctb32.dir/src/ctb_oper.c.o
In file included from /usr/include/string.h:49,
from
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/ctb/src/ctb_oper.c:62:
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/hrstr/strings.h:101:
error: expected specifier-qualifier-list before 'uchar'
/usr/ports/graphics/cuneiform/work/cuneiform-linux-1.0.0/cuneiform_src/Kern/hrstr/strings.h:138:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'bNeedFreeString'
*** Error code 1
The real problem is that wrong strings.h is included from the system string.h
header. Reason is very simple - gcc searches all directories from -I/src/...
dirs and only then - system path. There is file names strings.h in the source
tree, so its included by mistake and this causing a build failure.
There are 2 possible workarounds for this - one is to use mine workaround from
the cuneiform_src/Kern/hhh/tigerh/h/c_types.h file:
/* solves conflict with bsd <strings.h> */
#if defined(__FreeBSD__)
#undef __BSD_VISIBLE
#endif
This way it force system strng.h not to include strings.h. The problem is that
in many source files <strings.h> is included *before* cuneiform includes, so
this will require to change include order of the all such files, Another
option (as for me - better one) is to rename strings.h to something like
cf_strings.h and also to change references in the cuneiform files (it is used
only in 1 or 2 headers). I think this is the best case, because will prevent
such problems in the feature. Please tell me your opinion and i will do the
patch.
_______________________________________________
Mailing list: https://launchpad.net/~cuneiform
Post to : cuneiform@lists.launchpad.net
Unsubscribe : https://launchpad.net/~cuneiform
More help : https://help.launchpad.net/ListHelp
