Bug 202662 - Fix lang/go build with clang 3.7.0
Summary: Fix lang/go build with clang 3.7.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Julien Laffaye
URL:
Keywords:
Depends on:
Blocks: 201377
  Show dependency treegraph
 
Reported: 2015-08-25 20:13 UTC by Dimitry Andric
Modified: 2015-11-13 09:44 UTC (History)
2 users (show)

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


Attachments
Fix go's ldelf.c to not complain about unnamed symbols (548 bytes, patch)
2015-08-25 20:13 UTC, Dimitry Andric
no flags Details | Diff
Fix signed left-shifting in src/cmd/6c/txt.c (565 bytes, patch)
2015-08-25 20:14 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer freebsd_triage 2015-08-25 20:13:46 UTC
Created attachment 160360 [details]
Fix go's ldelf.c to not complain about unnamed symbols

During the exp-run in bug 201377, it was found that lang/go gives errors with a recent clang 3.7.0 snapshot:

http://package18.nyi.freebsd.org/data/headi386PR201377-default/2015-07-31_12h04m22s/logs/errors/go-1.4.2,1.log

These errors, about unnamed symbols, are very similar to this upstream issue:

https://github.com/golang/go/issues/8876

I propose the attached patch for ldelf.c, which makes it ignore unnamed symbols, similar to those starting with .Linfo_string*.

Even with this patch, on amd64, there is still another issue, where a few negative numbers are left-shifted:

/usr/work/share/dim/ports/lang/go/work/go/src/cmd/6c/txt.c:995:28: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
                                f->vconst |= (vlong)~0 << 32;
                                             ~~~~~~~~~ ^

For this, I propose the next patch, for src/cmd/6c/txt.c, which just casts the constant to uvlong.  This should result in no functional change, but I am unsure how to run any go test suite to verify.

Alternatively, the makefile(s) can be changed to squelch the warning, if you like that better.
Comment 1 Dimitry Andric freebsd_committer freebsd_triage 2015-08-25 20:14:29 UTC
Created attachment 160361 [details]
Fix signed left-shifting in src/cmd/6c/txt.c
Comment 2 Julien Laffaye freebsd_committer freebsd_triage 2015-08-25 21:06:01 UTC
I'd like to discuss these issues with upstream.
Would you open an issue on their github or should I do it?
Comment 3 Dimitry Andric freebsd_committer freebsd_triage 2015-08-25 21:25:27 UTC
Maybe upstream is more familiar with you, if you have already submitted issues before?  I have some other ports from the exp-run to make fixes for, so if you could do it, please have a go.
Comment 4 Julien Laffaye freebsd_committer freebsd_triage 2015-09-27 19:58:26 UTC
Is it better with r398046 ?
Comment 5 Niklaas Baudet von Gersdorff 2015-11-01 15:17:38 UTC
Is this here related?

http://sprunge.us/aOiO

Interesting are lines 26-28 and 227+.

I tried to compile lang/go and got the problems above. This was done on a RPi2 with 11.0-CURRENT.

niklaas@rpi2$ uname -a
FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r289846: Sat Oct 24 07:03:15 UTC 2015     root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2  arm

niklaas@rpi2$ clang --version
FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
Target: armv6--freebsd11.0-gnueabi
Thread model: posix
Comment 6 Dimitry Andric freebsd_committer freebsd_triage 2015-11-01 17:37:29 UTC
(In reply to Niklaas Baudet von Gersdorff from comment #5)
> Is this here related?
> 
> http://sprunge.us/aOiO
> 
> Interesting are lines 26-28 and 227+.

The "-t: not found" messages on lines 26-28 are not new, but they never seem have been fatal.  I have not looked into them very deeply.  Most likely caused by some Linuxism or Bashism.

The "crypto/tls: /usr/ports/lang/go14/work/go/pkg/tool/freebsd_arm/5g: signal: killed" message is probably something entirely different from what was reported earlier in this bug.

Is there any chance you can figure out what signal killed the '5g' process?  Or some form of backtrace?
Comment 7 Niklaas Baudet von Gersdorff 2015-11-01 18:13:17 UTC
(In reply to Dimitry Andric from comment #6)
How would I do that?
Comment 8 Dimitry Andric freebsd_committer freebsd_triage 2015-11-01 18:40:41 UTC
(In reply to Niklaas Baudet von Gersdorff from comment #7)
> (In reply to Dimitry Andric from comment #6)
> How would I do that?

For the signal, look in dmesg.  For a backtrace, run the program in gdb.
Comment 9 Niklaas Baudet von Gersdorff 2015-11-01 19:33:43 UTC
(In reply to Dimitry Andric from comment #8)

Well, this is for the killed signal:

Nov  1 20:27:04 rpi2 kernel: pid 99008 (5g), uid 0, was killed: out of swap space

No wonder:

# Custom /etc/fstab for FreeBSD embedded images
/dev/ufs/rootfs   /       ufs     rw      1       1
/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0
md /tmp mfs rw,noatime,-s1g 0 0

Filesystem                Size    Used   Avail Capacity  Mounted on
/dev/ufs/rootfs            14G    3.7G    9.2G    28%    /
devfs                     1.0K    1.0K      0B   100%    /dev
/dev/msdosfs/MSDOSBOOT     50M    7.4M     43M    15%    /boot/msdos
/dev/md0                  992M     23M    889M     3%    /tmp

Backtrace follows.
Comment 10 Niklaas Baudet von Gersdorff 2015-11-01 19:41:05 UTC
(In reply to Dimitry Andric from comment #8)
How would I exactly run the program in gdb?

I started gdb and then did `make install`. When compilation is aborted I do `bt` but get

(gdb) bt
No stack.
Comment 11 Dimitry Andric freebsd_committer freebsd_triage 2015-11-01 22:35:18 UTC
(In reply to Niklaas Baudet von Gersdorff from comment #9)
> (In reply to Dimitry Andric from comment #8)
> Well, this is for the killed signal:
> 
> Nov  1 20:27:04 rpi2 kernel: pid 99008 (5g), uid 0, was killed: out of swap
> space

Ah, yes.  This really means the process ran out of memory (I'm assuming you have no swap on RPi).  I don't know how much memory the program actually needs on arm.  Maybe you can add some temporary swap via swapon(8) on a file, and see if it gets to the end?
Comment 12 Niklaas Baudet von Gersdorff 2015-11-02 04:28:52 UTC
(In reply to Dimitry Andric from comment #11)

I did so and let it run over night since it always takes a while to compile. I mad some progress: http://sprunge.us/NWTK

   345	##### Building packages and commands for freebsd/arm.
   346	runtime: this system has multiple CPUs and must use
   347	atomic synchronization instructions. Recompile using GOARM=7.
   348	*** Error code 1

So I added "GOARM=7" to the Makefile. It's compiling at the moment. I'll keep you updated.
Comment 13 Niklaas Baudet von Gersdorff 2015-11-02 04:46:49 UTC
(In reply to Niklaas Baudet von Gersdorff from comment #12)
Some progress, but not completely successful: http://sprunge.us/cYTg.
Comment 14 Antoine Brodin freebsd_committer freebsd_triage 2015-11-13 09:44:38 UTC
Close: today lang/go builds fine on both i386 and amd64 with clang 3.7.0.