Date: Thu, 06 Jul 2017 23:38:56 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: Jose Alonso Cardenas Marquez <acm@FreeBSD.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r445203 - head/lang/ldc Message-ID: <201707070638.v676cuPX003225@slippy.cwsent.com> In-Reply-To: Message from Jose Alonso Cardenas Marquez <acm@FreeBSD.org> of "Fri, 07 Jul 2017 03:15:03 -0000." <201707070315.v673F3Gl061343@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <201707070315.v673F3Gl061343@repo.freebsd.org>, Jose Alonso Cardenas Marquez writes: > Author: acm > Date: Fri Jul 7 03:15:02 2017 > New Revision: 445203 > URL: https://svnweb.freebsd.org/changeset/ports/445203 > > Log: > - Update to 1.2.0 > > Modified: > head/lang/ldc/Makefile > head/lang/ldc/distinfo > head/lang/ldc/pkg-plist Hi, I get the following, a segfault. This is not specifically caused by your commit though, instead inode64 on 12-CURRENT. [111/905] cd /export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src && /export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/bin/ldc2 --output-o -c -I/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/r untime/druntime/src -I/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0 -src/runtime/druntime/src/gc /export/wrkdir/amd64/usr/ports/lang/ldc/work/ld c-1.2.0-src/runtime/druntime/src/core/sys/freebsd/execinfo.d -of/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/runtime/src/co re/sys/freebsd/execinfo-debug.o -w -g -link-debuglib FAILED: runtime/src/core/sys/freebsd/execinfo-debug.o cd /export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src && /export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/bin/ldc2 --output-o -c -I/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/r untime/druntime/src -I/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0 -src/runtime/druntime/src/gc /export/wrkdir/amd64/usr/ports/lang/ldc/work/ld c-1.2.0-src/runtime/druntime/src/core/sys/freebsd/execinfo.d -of/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/runtime/src/co re/sys/freebsd/execinfo-debug.o -w -g -link-debuglib 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/lang/ldc ===>>> make build failed for lang/ldc ===>>> Aborting update ===>>> You can restart from the point of failure with this command line: portmaster <flags> lang/ldc This command has been saved to /tmp/portmasterfail.txt Summary: Exiting due to failure at amd64, RC=1 slippy# slippy# gdb /export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2.0-src/bin/l dc2 ldc2.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `/export/wrkdir/amd64/usr/ports/lang/ldc/work/ldc-1.2. 0-src/bin/ldc2 --output-o -'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libconfig.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libconfig.so.9 Reading symbols from /usr/lib/librt.so.1...Reading symbols from /usr/lib/debug//usr/lib/librt.so.1.debug...done. done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libncurses.so.8...Reading symbols from /usr/lib/debug//lib/libncurses.so.8.debug...done. done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done. done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libc++.so.1...Reading symbols from /usr/lib/debug//usr/lib/libc++.so.1.debug...done. done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...Reading symbols from /usr/lib/debug//lib/libcxxrt.so.1.debug...done. done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libgcc_s.so.1...Reading symbols from /usr/lib/debug//lib/libgcc_s.so.1.debug...done. done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000000000000 in ?? () (gdb) Interestingly I'm seeing the same issue with lang/dmd2. I've determined that dmd2's issue is stack corruption caused incorrect D stat_t and dirent_t definitions. I'm willing to bet that ldc, which is based on DMD D (with an llvm backend), likely has the same issue. I've opened a ticket with dlang.org. The issue is that for lang/dmd2 and lang/ldc to support pre-inode64 and post-inode64 systems we must be able to conditionally include old and new versions of stat and dirent structs. Unfortunately D only supports a version() statement (akin an #ifdef) and D supports version(FreeBSD) and is not able to conditionally compile based on __FreeBSD_version. (It would have been simpler had they used simple stubs to interface with the O/S. <sigh> ) I think our todo in both cases will be: 1. See if our upline can support a version() statement that can be used to compare against __FreeBSD_version or failing that a major.minor version number, or 2. Replacing the direct D calls of stat() and fstat() with calls to a stub written in C or C++. This too can only be sustainably provided by our upline. 3. Failing 1 and 2 above, the makefile changes and patches to both ports will be inelegant hacks at best. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201707070638.v676cuPX003225>