Ah, you'll note: fork/exec implicated here.
Looks like this guy strikes again:
https://github.com/golang/go/issues/15658
It pains me to say but Go on FreeBSD is (and has always been)
broken. Should be fine if you don't exec. Something that might
help, is setting GOMAXPROCS=1.
Derek
On
Agree with previous sentiments, and:
On 17-04-18 10:59 PM, Christopher Hall wrote:
You should use built in golang vendoring to ensure these
dependencies, as their is no guarantee that someone won't update the
library port and your app would break, so doing that is very fragile
Currently the
On 16-05-12 02:08 PM, Ed Maste wrote:
Baptiste and I have been looking at reproducible builds in the FreeBSD
ports tree, and one thing we'll need is a consistent timestamp that
doesn't change when a port is rebuilt without changes.
Just wondering if any work has gone into consuming these
On 16-02-19 08:42 PM, Derek (freebsd lists) wrote:
On 16-02-19 02:16 PM, Brooks Davis wrote:
On Fri, Feb 19, 2016 at 07:13:04AM -0500, Derek (freebsd lists)
wrote:
I can provide more detail, but would like to know if I'm doing
something horribly wrong first (i.e. trying to access the network
On 16-02-19 02:16 PM, Brooks Davis wrote:
On Fri, Feb 19, 2016 at 07:13:04AM -0500, Derek (freebsd lists) wrote:
I can provide more detail, but would like to know if I'm doing
something horribly wrong first (i.e. trying to access the network
with gb as a make target, versus some other way to do
Hi,
I'm attempting to port a project over, and it is dependent on a
"vendorizing" program, which then pulls in the source of the
dependencies to build. (The final artifact is statically linked,
so there shouldn't be a problem as far as installing unversioned
libraries outside of the
