Hi Michele „Dynamic libraries included in the container" was the answer I was looking for. Thanks
Regards Felix > Am 12.12.2018 um 10:49 schrieb Michele Sciabarra <[email protected]>: > > To answer to the second part of your question: > > if you compile a Go program with the native go compiler, the final executable > links statically everything including the garbage collector and other stuff. > If you use gccgo, those things are dynamic libraries and are not included in > the executable. > > I created the gccgo image using ubuntu (bionic) and installing the gccgo > package, hence all the required dynamic libraries are included in the docker > image. > > Furthermore, the executable is created by the image itself (using the > precompilation feature of the "actionloop" image) so the executable is > created BY the image FOR the image and the dynamic libraries match. > > The same happens for the switf image, to create say an executable for swift > 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and > it will produce an action that can be run in the same image. > > -- > Michele Sciabarra > [email protected] > > ----- Original message ----- > From: Felix Meschberger <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Wed, 12 Dec 2018 09:09:58 +0000 > > Hi > > From the sidelines… > > I understand that there is limited bandwidth to support all sorts of runtimes > .. But I wonder, whether such a thing would not have a space in some sort of > an „unsupported“ contrib area ? > > I myself like the idea of smaller binaries but wonder how you solve the > dynmic linking issue of provisioning the dependency dynamic libraries in the > container ? > > Regards > Felix > >> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <[email protected]>: >> >> I am perfectly fine if we do not provide a gccgo runtime, it was not a big >> work, and I did it to see if it is possible to generate small executables >> also for go, since the swift one is very small. >> >> Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both >> in run and init time (a personal satisfaction) if the init time is NOT a >> problem, I agree that there are no reasons to provide also an official gccgo >> version. >> >> On Slack Markus asked to measure also the Init time but in all honesty I do >> not know how important is to provide also faster init time. >> >> -- >> Michele Sciabarra >> [email protected] >> >> ----- Original message ----- >> From: Carlos Santana <[email protected]> >> To: [email protected] >> Subject: Re: I created a variant of the go runtime that is faster at init >> time >> Date: Tue, 11 Dec 2018 07:58:19 -0800 >> >> Let’s stick with the 1.11 stock compiler, produces greater portability abs >> allows us to make updates to the base linux image with low risk for braking >> an exec built previously >> >> Not worth for the init, in general a busy app doesn’t suffer a lot of cold >> start and on the flip side a infrequent app can leverage stemcell a/prewarm >> >> I think if you want to investigate maybe opening an issue or start >> discussion with go community on how the compiler can be improve if if their >> flags that we are not using to optimized the binary >> >> — Carlos >> >> >> On Tue, Dec 11, 2018 at 7:46 AM David P Grove <[email protected]> wrote: >> >>> >>> Sorry. >>> >>> I mean do not bother providing a gccgo variant of the go runtime. Stick >>> with the official golang compiler at 1.11. I don't see the small speedup >>> in init time as being enough to justify supporting two variants of go >>> actions. >>> >>> --dave >>> >>> >>> Michele Sciabarra <[email protected]> wrote on 12/11/2018 10:37:56 AM: >>> >>>> From: Michele Sciabarra <[email protected]> >>>> To: [email protected] >>>> Date: 12/11/2018 10:38 AM >>>> Subject: Re: I created a variant of the go runtime that is faster atinit >>> time >>>> >>>> Sorry not sure what you mean. Do you suggest I apply the change to use >>>> gccgo in the official runtime, even if it is stuck at go 1.10 (the >>>> latest is go 1.11) or I drop the idea of providing another runtime that >>>> is faster to initialize? Would not be better to release both a gccgo >>>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first >>>> produces smaller binaries but it is a bit slower and it is stuck to go >>>> 1.10, the second is faster but it is slower to initialize because the >>>> executable is bigger.-- >>>> Michele Sciabarra >>>> [email protected] >>>> >>>> >>>> >>>> ----- Original message ----- >>>> From: David P Grove <[email protected]> >>>> To: [email protected] >>>> Subject: Re: I created a variant of the go runtime that is faster at >>>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500 >>>> >>>> Michele Sciabarra <[email protected]> wrote on 12/11/2018 >>>> 07:23:14 AM:> >>>>> Then I created a variant of the go runtime, using GccGo. GccGo is a >>>>> Go compiler, updated to Go version 1.10, that compiles using the Gcc >>>>> compiler infrastructure. As a result, it produces dynamically linked >>>>> executables that are smaller than the binaries produced by the >>>>> standard Go compiler. >>>>> ... >>>>> >>>>> GccGo is a bit slower than Go (but it is still the second faster >>>>> runtime) but it is now the faster at init time because the >>>>> executable is around 50k (and zipped it is only 17k). >>>>> >>>>> I am unsure if replace GccGo in the official runtime or provide >>>>> both. The fact that the executable is small so it leads to faster >>>>> init time I think it is important, but the GccGo compiler it is a >>>>> bit behind in term of language support. >>>>> >>>> >>>> My advice is to stick with the official runtime. I think that is >>>> betterfor end users. >>>> >>>> --dave >>>> >>> >> -- >> Carlos Santana >> <[email protected]> >
