Bug 231373 - net/librsync2: Build broken since update to 2.0.2
Summary: net/librsync2: Build broken since update to 2.0.2
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-15 06:55 UTC by Peter Putzer
Modified: 2019-10-21 21:53 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (bdrewery)


Attachments
Header patch (327 bytes, patch)
2018-09-15 15:17 UTC, Nathan
no flags Details | Diff
Patch test (251 bytes, patch)
2018-09-15 17:04 UTC, Nathan
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Putzer 2018-09-15 06:55:58 UTC
As documented previously in bug #230154, the build is broken with the default system compiler (clang) since the update to upstream version 2.0.2. My system is 11.2-RELEASE-p3 on amd64, but others have reported the same issue as far back as 10.4 on x86.

Here is the log from the failing test compilaton:

[34/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O3 -pipe -funroll-loops -march=native  -fstack-protector -fno-strict-aliasing -Wall -O3 -pipe -funroll-loops -march=native  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
FAILED: CMakeFiles/sumset_test.dir/tests/sumset_test.c.o 
/usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O3 -pipe -funroll-loops -march=native  -fstack-protector -fno-strict-aliasing -Wall -O3 -pipe -funroll-loops -march=native  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
In file included from tests/sumset_test.c:27:
/usr/local/include/librsync.h:430:21: error: unknown type name 'FILE'
void rs_mdfour_file(FILE *in_file, char *result);
                    ^
/usr/local/include/librsync.h:432:23: error: unknown type name 'FILE'
rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
                      ^
/usr/local/include/librsync.h:432:39: error: unknown type name 'FILE'
rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
                                      ^
/usr/local/include/librsync.h:437:27: error: unknown type name 'FILE'
rs_result rs_loadsig_file(FILE *, rs_signature_t **, rs_stats_t *);
                          ^
/usr/local/include/librsync.h:441:43: error: unknown type name 'FILE'
rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *);
                                          ^
/usr/local/include/librsync.h:441:59: error: unknown type name 'FILE'
rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *);
                                                          ^
/usr/local/include/librsync.h:443:25: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                        ^
/usr/local/include/librsync.h:443:43: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                                          ^
/usr/local/include/librsync.h:443:61: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                                                            ^
9 errors generated.
Comment 1 Nathan 2018-09-15 15:07:26 UTC
Been trying to reproduce this error on different versions of jails and archs and I can not reproduce it at all. Tried outside of poudriere as well and nothing wrong for me.

Looking at my compile output and Peter's our CFLAGS are different, which shouldn't be. Mine is -O2 and no funroll-loops nor does mine have -march=native
Comment 2 Peter Putzer 2018-09-15 15:14:30 UTC
(In reply to Nathan from comment #1)

I've disabled the optimization flags in make.conf and (as I expected) it does not make a difference:

[30/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
FAILED: CMakeFiles/sumset_test.dir/tests/sumset_test.c.o 
/usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
In file included from tests/sumset_test.c:27:
/usr/local/include/librsync.h:430:21: error: unknown type name 'FILE'
void rs_mdfour_file(FILE *in_file, char *result);
                    ^
/usr/local/include/librsync.h:432:23: error: unknown type name 'FILE'
rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
                      ^
/usr/local/include/librsync.h:432:39: error: unknown type name 'FILE'
rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
                                      ^
/usr/local/include/librsync.h:437:27: error: unknown type name 'FILE'
rs_result rs_loadsig_file(FILE *, rs_signature_t **, rs_stats_t *);
                          ^
/usr/local/include/librsync.h:441:43: error: unknown type name 'FILE'
rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *);
                                          ^
/usr/local/include/librsync.h:441:59: error: unknown type name 'FILE'
rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *);
                                                          ^
/usr/local/include/librsync.h:443:25: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                        ^
/usr/local/include/librsync.h:443:43: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                                          ^
/usr/local/include/librsync.h:443:61: error: unknown type name 'FILE'
rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *);
                                                            ^
9 errors generated.
[31/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/util.c.o -MF CMakeFiles/sumset_test.dir/src/util.c.o.d -o CMakeFiles/sumset_test.dir/src/util.c.o   -c src/util.c
[32/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/hex.c.o -MF CMakeFiles/sumset_test.dir/src/hex.c.o.d -o CMakeFiles/sumset_test.dir/src/hex.c.o   -c src/hex.c
[33/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/checksum.c.o -MF CMakeFiles/sumset_test.dir/src/checksum.c.o.d -o CMakeFiles/sumset_test.dir/src/checksum.c.o   -c src/checksum.c
[34/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/trace.c.o -MF CMakeFiles/sumset_test.dir/src/trace.c.o.d -o CMakeFiles/sumset_test.dir/src/trace.c.o   -c src/trace.c
[35/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/sumset.c.o -MF CMakeFiles/sumset_test.dir/src/sumset.c.o.d -o CMakeFiles/sumset_test.dir/src/sumset.c.o   -c src/sumset.c
[36/53] /usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/rollsum.c.o -MF CMakeFiles/sumset_test.dir/src/rollsum.c.o.d -o CMakeFiles/sumset_test.dir/src/rollsum.c.o   -c src/rollsum.c
[37/53] /usr/local/libexec/ccache/world/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/blake2/blake2b-ref.c.o -MF CMakeFiles/rsync.dir/src/blake2/blake2b-ref.c.o.d -o CMakeFiles/rsync.dir/src/blake2/blake2b-ref.c.o   -c src/blake2/blake2b-ref.c
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/net/librsync2
Comment 3 Nathan 2018-09-15 15:17:07 UTC
Created attachment 197112 [details]
Header patch

@Peter try applying this patch to the source and see if it fixes your issue. If it does I'll make a new Makefile for librsync. I have a suspicion that <stdio.h> isn't being included, which is needed for FILE
Comment 4 Nathan 2018-09-15 15:19:53 UTC
(In reply to Nathan from comment #3)
Can simply make extract, cd into source dir apply patch, then go back into port's dir with Makefile,pkg-plist, etc and run make makepatch so it gets included into build
Comment 5 Peter Putzer 2018-09-15 15:25:08 UTC
Does not work, unfortunately. I noticed that the compile seems to use the installed /usr/local/include/librsync.h instead of the one from the work directory?
Comment 6 Peter Putzer 2018-09-15 15:27:56 UTC
Yup, that's it. I copied the original unpatched librsync.h to /usr/local/include and then the build went through.
Comment 7 Nathan 2018-09-15 15:33:05 UTC
(In reply to Peter Putzer from comment #6)
Hmm I'll try to investigate but going to be a way for a bit today, so may be a bit before I can
Comment 8 Nathan 2018-09-15 17:04:24 UTC
Created attachment 197114 [details]
Patch test

Peter try this patch, it SHOULD not need to worry about librsync.h so much now because I put <stdio.h> in the test file that fails
Comment 9 Peter Putzer 2018-09-15 18:00:10 UTC
(In reply to Nathan from comment #8)

Unfortunately, I can't really test this anymore as I've already installed the new include. 

Anyway, I don't think adding <stdio.h> to the testfile is true solution as other type definitions could have changed. Using the old include file for compiling the library can result in weird breakage.
Comment 10 Nathan 2018-09-15 18:02:57 UTC
I have no idea why it is trying to pull from /usr/local/include/librsync2.h because 1. Not installed if not previously installed 2. Include looks like #include "librsync.h" and not <librsync.h>
Comment 11 Peter Putzer 2018-09-15 18:22:56 UTC
#include "something"

looks for the file "something" in the same directory as the compiled source file and then searches the include path (i.e. after the initial lookup its exactly the same as 

#include <something>

The include path (given on the command line by the -I directive) is searched in left-to-right order. 

Here's the command line from cmake:

/usr/local/libexec/ccache/world/cc  -I/usr/local/include -Isrc/blake2 -Isrc 

This means the directories are searched in this order:
/usr/local/include
<builddir>/src/blake2 
<builddir>/src
Comment 12 Bryan Drewery freebsd_committer 2018-10-04 20:24:10 UTC
I haven't been able to recreate this. It's a good example of why building in a
sandbox is important.
Though to be clear, I have tried building this with librsync2 already installed
and still am not able to recreate it.
Comment 13 Peter Putzer 2018-10-04 20:58:40 UTC
(In reply to Bryan Drewery from comment #12)

An old version of librsync2? (Obviously, if you've got 2.0.2 installed, it will work fine.) The include path order behavior of clang should be pretty stable, though.
Comment 14 Pavlos Georgiadis 2018-10-05 09:37:40 UTC
I still have a system where I can reproduce this.

I tried to do a "make extract", changed the sumset_test.c file manually to include the "#include <stdio.h>", run "make patch" (not sure if that was needed) and then run make. I am still getting the same error.

I am not in a hurry to upgrade this particular system, so I can try other solutions if you like.
Comment 15 Arnaud de Prelle 2018-10-05 10:01:05 UTC
(In reply to Pavlos Georgiadis from comment #14)

@Pavlos,

If you want to solve this compilation issue quickly, read my comment in the initial bug report (bugid 230154) :

"I solved this issue by appending this to my make.conf:
USE_GCC?=any
(...)"

The default system compiler won't work for a reason I didn't investigate (yet).
Using GCC from ports to compile solves this issue.
Comment 16 Pavlos Georgiadis 2018-10-05 10:06:04 UTC
(In reply to apn from comment #15)

Thanks. But I am not in a hurry and given that it's not easy to reproduce the issue, I can wait, in case the port maintainer wants to test anything.
Comment 17 stefan.witzel 2018-10-08 13:41:30 UTC
I have the same problem compiling www/hiawatha on FBSD 11.2. A cmake a/or clang problem?
Comment 18 stefan.witzel 2018-10-23 10:27:58 UTC
Workaround found?

The installation of librsync2 in a fresh jail (no librsync2 installed, FreeBSD amd64 11.2) succeeded, when I apply the following change to the Makefile:

USES=           cmake:noninja

Stefan