cuneiform team mailing list archive

[Alex Samorukov <samm@xxxxxxxxxxx>]

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.