search

ascii-boxes / boxes

Command line ASCII boxes unlimited!
https://boxes.thomasjensen.com/
GNU General Public License v3.0
599 stars 78 forks source link

v2.1.0: fatal error: boxes.h: No such file or directory #79

Closed tim77 closed 3 years ago

tim77 commented 3 years ago

Hello. 2.1.0 won't compile on Fedora.

make[2]: *** [<builtin>: unicode.o] Error 1
make[2]: Entering directory '/builddir/build/BUILD/boxes-2.1.0/out'
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection   -c -o boxes.o ../src/boxes.c
make[2]: Leaving directory '/builddir/build/BUILD/boxes-2.1.0/out'
../src/boxes.c:27:10: fatal error: boxes.h: No such file or directory
   27 | #include "boxes.h"
      |          ^~~~~~~~~
compilation terminated.

Full build log f34.

Environment (please complete the following information):

tsjensen commented 3 years ago

Wow, thanks for trying it out right away, that's fast! 👍

There was in fact an internal change to the Makefile which creates all generated files in out/. boxes.h is a generated file (from boxes.in.h). The Makefile changes to the out/ directory and uses the VPATH functionality to find sources in src/ and src/misc/.

I notice that for some reason in the log fragment you posted, the build exits the out dir before trying to compile boxes.c. That's unexpected - compilation of all files requires that the working directory is out/. Are you using our Makefiles?

tsjensen commented 3 years ago

Also, boxes.h is created by the top-level Makefile, whereas compilation happens within the Makefile in src/.

tim77 commented 3 years ago

Are you using our Makefiles?

Yes. Using default, canonical macros in Fedora for it:

%make_build

which equivalent of

/usr/bin/make -O -j8 V=1 VERBOSE=1

And all this look like this:

%set_build_flags
%make_build \
    CFLAGS='%{optflags}' \
    debug \
    GLOBALCONF=%{cfgfile} \
    LDFLAGS='%{build_ldflags}' \
    %{nil}

%set_build_flags =

  CFLAGS="${CFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ; 
  FFLAGS="${FFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FFLAGS ; 
  FCFLAGS="${FCFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ; 
  LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld }" ; export LDFLAGS ; 
  LT_SYS_LIBRARY_PATH="${LT_SYS_LIBRARY_PATH:-/usr/lib64:}" ; export LT_SYS_LIBRARY_PATH ; 
  CC="${CC:-gcc}" ; export CC ; 
  CXX="${CXX:-g++}" ; export CXX
tsjensen commented 3 years ago

Ok, I'll try and look at this in greater detail tomorrow. We'll get it working, I'm sure.

tsjensen commented 3 years ago

Boxes builds fine on my Fedora, without even a single warning, and all tests are green. I used the fedora:latest Docker container.
I kind of expected that, with what our past experience. 😉 The problem must somehow be caused by the source RPM.

Can you share the spec file and full build log? The one that I have is still on 2.0.0. Thanks!

tim77 commented 3 years ago

Koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=66203173 SRPM https://kojipkgs.fedoraproject.org//work/tasks/3136/66203136/boxes-2.1.0-1.fc35.src.rpm

tsjensen commented 3 years ago

I could reproduce the problem, but you'll have to help me solve it. 😕

I noticed a few things:

Unrelated, I noticed a few minor things in the spec which might be interesting to you after we resolve the main problem:

cuihaoleo commented 3 years ago

Maybe relevant (or not). On ArchLinux, we got fatal error: parser.h: No such file or directory when making in parallel (like make -j10 ). make -j1 runs with no issue.

Full log here.

In file included from ../src/boxes.c:33:
../src/parsing.h:28:10: fatal error: parser.h: No such file or directory
   28 | #include "parser.h"
      |          ^~~~~~~~~~
compilation terminated.
In file included from ../src/list.c:31:
../src/parsing.h:28:10: fatal error: parser.h: No such file or directory
   28 | #include "parser.h"
      |          ^~~~
tim77 commented 3 years ago

I assume this could caused because include paths no specified. This code not works look like https://github.com/ascii-boxes/boxes/blob/ba5ce91c849a707f851a401dbee6177aba0e79f2/src/Makefile#L69

I am not sure this related with new features in GCC or not, but maybe this also could help you:

The license should be GPL-2.0-only instead of GPLv2+.

Thanks, i'll fix this for sure in next update.

Boxes v2.1.0 requires vim-common for the build because it provides the xxd tool we use in some of the new tests.

Added.

Boxes is currently built with debug info included. For production, it should therefore probably be %make_build build ... instead of %make_build debug ... (or just leave out the first argument entirely).

RPM catch this debuginfo during build and put in separate debuginfo packages which not shipped with main package. Optimizations flags override as well by default Fedora build macroses.

tsjensen commented 3 years ago

Thanks @cuihaoleo! You really helped me out of a tight spot there.

I made a slight change to the Makefile to adjust for this effect, and now the source RPM builds fine on my Fedora. The final changes to the RPM spec also include the adjustment of the path were the executable is being created:

12c12
< License:        GPLv2+
---
> License:        GPL-2.0-only
21a22
> BuildRequires:  vim-common
61c62
<     CFLAGS='-I. -I../src %{optflags}' \
---
>     CFLAGS='%{optflags}' \
72c73
< install -Dp -m 0755 src/%{name}     %{buildroot}%{_bindir}/%{name}
---
> install -Dp -m 0755 out/%{name}     %{buildroot}%{_bindir}/%{name}
tim77 commented 3 years ago

https://github.com/ascii-boxes/boxes/commit/d1a1cf158016f24ee9d4785e3e07b82329964d0f and making -j1 doesn't help. See koji build https://koji.fedoraproject.org/koji/taskinfo?taskID=66356685.

tsjensen commented 3 years ago

Yes, you need to fix the spec file, too. (diff above)

But then it should work. At least it did on my machine, using your rpm commands. 😃

tim77 commented 3 years ago

You can check the spec in SRPM. It's already with this fixes.

tsjensen commented 3 years ago

Dang, but the log file you linked does not show them. 😕 Are you sure?

I don't know how to "check the SRPM". But I looked at this log, which does not have the flags: https://kojipkgs.fedoraproject.org//work/tasks/6685/66356685/build.log

TimB87 commented 3 years ago

CRUX maintainer here, -j1 fixes it over here as well.

tsjensen commented 3 years ago

@TimB87 That's great to hear! I hope you don't even need -j1 with the Makefile change from d1a1cf1. But either way, you're fine.

TimB87 commented 3 years ago

Just tried it and yes, that fixed it

tim77 commented 3 years ago

@tsjensen Yes, i am sure.

does not have the flags

Which exactly? Package MUST compile with default Fedora build flags https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

I tried even build and force with %global _smp_mflags %nil .

99% of this make file mess could be solved by port Boxes to Cmake/Meson.

tsjensen commented 3 years ago

@tim77 Well, the -I flags are required, because otherwise gcc can't find the includes.
I'm not an expert on this, but the page you linked says:

Adding to [...] these flags is permitted if there’s a good reason to do so;

which seems to me that since we haven't yet migrated to another build system (and will probably not be able to do that for a long time because there are simply too many platforms to support), you have a good reason. 😉

tim77 commented 3 years ago

@tsjensen i built it finally with proper, canonical build flags. Even with -j8 compiles fine. For all arches.

Closing as resolved. If you wish and when you will ready we can send you fully functional PR with Meson port. 😉 Thanks!

tsjensen commented 3 years ago

Fantastic! Great work @tim77! ⭐