Comment 1 Raphael Kubo da Costa 2016-01-27 21:05:44 UTC

It's running out of memory because you're linking a debug version of WebKit. Doing that requires quite a lot of resources.

With that said, it looks like this is the opposite of what you want when you did WITH_DEBUG=. Since bsd.qt.mk does `if defined(WITH_DEBUG)' it will build a debug version instead of the default release one. Is there a reason for setting WITH_DEBUG like that instead of just not setting it at all?

6GBytes of RAM, 2 GByte of swap. 64GByte of disk. But ZFS (as an experiment) so the file system likely is more memory hungry than if I'd used UFS.

I do not remember top showing it being nearly out of memory but I'll have to retry at some point if I want to be sure.

I would have guessed that the file format has some 4GB limit that might have been reached, explaining why the terminology reads like a file truncation instead of out-of-memory.

Looking around some I found one 2012 reference to code in ar that was reported to then look like:

	  /* Catch an attempt to grow an archive past its 4Gb limit.  */
	  if (archive_member_file_ptr != (file_ptr) offset)
	    {
	      bfd_set_error (bfd_error_file_truncated);
	      return FALSE;
	    }

If this was the issue it might imply needing the library to be split up in order to fit for  what is now qt's debug/libWebCore.a builds.

Looks like you are right about WITH_DEBUG= : the WITH_DEBUG= is some stray text that should not be in my make.conf . share/mk/*'s (bsd.lib.mk and bsd.prog.mk) use the following sort logic to add -g:

.if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \
    empty(DEBUG_FLAGS:M-gdwarf-*)
CFLAGS+= -g
CTFFLAGS+= -g
.endif

And that is the only reason that I can think of for the WITH_DEBUG= existing. So I'll remove it but still use WITH_DEBUG_FILES= and see what happens.

man ports reports that:

MAKE VARIABLES
. . .
     WITH_DEBUG                    (bool) If set, debugging symbols are
                                   installed for ports binaries.

Thuis my WITH_DEBUG= use was realistic by FreeBSD rules.

So it appears to me that its attempting to build debug/libWebCore.a instead (or in addition) is a conflicting use of WITH_DEBUG , especially since it fails and blocks the build. It would seem that for FreeBSD to have its WITH_DEBUG convention for ports, an alternate name for the alternate use would need to be used by the specific port.

Also even if having -g with release builds makes a release/libWebCore.a completely this report is still valid because any deliberately attempted build of debug/libWebCore.a would fail as my accidental WITH_DEBUG use did.

While not explicitly documented in "man ports" WITH_DEBUG= for ports controls:

STRIP
MAKE_ENV (via a +=)
STRIP_CMD
DEBUG_FLAGS (via a ?=)

Avoiding defining WITH_DEBUG at all but still providing gdb a better context for analyzing tracebacks and such would require the explicit, manual control of  at least the above 4 items in make.conf files used for ports activities.

In the specific context this would be to avoid the currently impossible debug/libWebCore.a that would otherwise stop the build.

(In reply to Mark Millard from comment #4)

As of /usr/ports -r415874 www/webkit-qt5 still misinterprets FreeBSD's WITH_DEBUG= (from /etc/make.conf ) and still fails to build as a result --failing the same way as reported before: File truncated.

Comment 6 Tobias C. Berner 2018-10-20 18:28:30 UTC

If you don't want debug, don't define WITH_DEBUG.

If you set WITH_DEBUG globabally, set undef it via .undef WITH_DEBUG for qt5-webkit.