I finally mentioned this on the upstream list and Russ Cox pointed out
that you can use the -pkgdir argument to the go tool here, you can do
something like go install -pkgdir ~/.gopkgdir instead of plain go
install.
Cheers,
mwh
* Michael Hudson-Doyle:
> Totally random thought, but could multiarch help here?
What you describe might help for the supported linux platforms. If one
has to configure all sorts of secondary architectures, this does not
seem like a very feasible developer setup, though.
I'd also like to be able
On 16 February 2016 at 11:13, Tianon Gravi wrote:
> On 11 February 2016 at 17:50, Michael Hudson-Doyle
> wrote:
>> It's the standard library packages, GOARCH=arm go install runtime is
>> going to try to create $GOROOT/pkg/linux_arm/runtime.a.
>
> This still seems odd to me, especially since doing
On 11 February 2016 at 17:50, Michael Hudson-Doyle
wrote:
> I'm not sure I want to be the one that takes that one upstream.
Totally fair -- I just meant that it's something that probably ought
to be taken upstream, not necessarily that I expected you to do so;
sorry for the confusion.
>> Any cha
On 12 February 2016 at 12:44, Tianon Gravi wrote:
> On 4 February 2016 at 16:56, Michael Hudson-Doyle
> wrote:
>> I guess it could be fixed by going back to building lots of
>> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
>> appealing, it would be nicer to allow the go instal
On 4 February 2016 at 16:56, Michael Hudson-Doyle
wrote:
> I guess it could be fixed by going back to building lots of
> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
> appealing, it would be nicer to allow the go install command to work
> (which would also allow the user to us
* Michael Hudson-Doyle:
> I guess it could be fixed by going back to building lots of
> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
> appealing,
Another option may be building *one* extra package that contains the
stdlib and whatever bits may be necessary for building for n
On 4 February 2016 at 02:12, Hilko Bengen wrote:
> * Tianon Gravi:
>
>> I'm not positive whether all were required for this to work, but given
>> that it _did_ work, I think this is in the realm of possible with the
>> changes of Go 1.5 and am inclined to close this bug as "fixed" --
>> thoughts?
* Tianon Gravi:
> I'm not positive whether all were required for this to work, but given
> that it _did_ work, I think this is in the realm of possible with the
> changes of Go 1.5 and am inclined to close this bug as "fixed" --
> thoughts? :)
Unfortunately, it's not that easy. :-(
Last time I c
On 7 March 2015 at 09:21, Hilko Bengen wrote:
> As far as I can see, it does not. The only notable change is that
> cgo.a files are installed for more than one architecture.
>
>> Also, what's the impact on the future Go 1.5, especially the new,
>> simpler cross-compile[1] that no longer requires r
* Tianon Gravi:
> Does compiling the stdlib with this force-enabled have any
> implications for existing users?
As far as I can see, it does not. The only notable change is that
cgo.a files are installed for more than one architecture.
> Also, what's the impact on the future Go 1.5, especially t
On 27 January 2015 at 09:51, Hilko Bengen wrote:
> Apparently, it is possible to build a CGO-enabled Golang cross compiler
> on all platforms if CGO_ENABLED=1 is set at build-time. I have
> successfully built Windows executables that use fopen(), fread()
> functions from the C standard library usi
Package: src:golang
Severity: wishlist
Version: 2:1.3.3-1
Tags: patch
Apparently, it is possible to build a CGO-enabled Golang cross compiler
on all platforms if CGO_ENABLED=1 is set at build-time. I have
successfully built Windows executables that use fopen(), fread()
functions from the C standar
13 matches
Mail list logo
