On Thursday, March 19, 2020 at 10:21:31 AM UTC-4, Nitish Saboo wrote: > > Hi Jake, > > Is there some reason that you want, or need, to be using go build this > way, by specifying files? Or is it just curiosity about how the tools work? > >>There is no particular reason to use go build by specifying the files. I > was trying different ways to compile the project and ended up with this > scenario. > I am curious to know the reason for this. > > The typical way to use go build is to build without specifying individual > files. If you are using CGO, I would certainly recommend that you do it by > building as a package, just to keep things simple. Not that CGO is ever > simple. > >> I will try compiling the package without specifying the individual > files. > Right, as I said, this is the standard way. You should always build the package this way, unless you have a specific use case that requires compiling a single file.
But the following case works all fine whether we pass the individual file > or not.: > The reason that works is because the package you are building only contains one file, 'main.go'. The other files are actually in different packages, so they are pulled in by import. So `go build -v - x` builds the package `nitish`, which only contains one file, `main.go`. Since the package name is `nitish` you get an executable named `nitish`. `go build -v - x main.go` is a special use of the tool. I mostly use it for quick code tests, when the playground will not suffice, or for using go to write quick scripts. It will not build the package `nitish`, instead it will build only the single file, and produce an executable named after the file, in this case `main.exe`. Since the `nitish` package only contains one file, the result is otherwise the same (AFAIK). Hope this has some useful information. > > > > *Case 1----------* > I have a project called 'nitish' where the folder structure looks like the > following: > > nitish > main.go > util > util.go > lib > node.c > node.h > a.go > > When I try compiling this project in the following ways: > > 1) go build -v - x > > >> This creates a binary called 'nitish' > > 2) go build -v - x main.go > > >> This creates a binary called 'main' > > ldd output of both the binaries is the same. > > Thanks, > Nitish > > > On Thu, Mar 19, 2020 at 7:18 PM Jake Montgomery <jake...@gmail.com > <javascript:>> wrote: > >> Nitish, >> >> Is there some reason that you want, or need, to be using go build this >> way, by specifying files? Or is it just curiosity about how the tools work? >> The typical way to use go build is to build without specifying individual >> files. If you are using CGO, I would certainly recommend that you do it by >> building as a package, just to keep things simple. Not that CGO is ever >> simple. >> >> >> On Wednesday, March 18, 2020 at 10:27:19 AM UTC-4, Nitish Saboo wrote: >>> >>> Hi Gregor, >>> >>> Do you mean like this 'go build -v -x main.go node.c' ? But it does not >>> compile and gives the following output: >>> >>> WORK=/tmp/go-build714119815 >>> named files must be .go files >>> >>> Thanks, >>> Nitish >>> >>> On Wed, Mar 18, 2020 at 7:44 PM Gregor Best <be...@pferdewetten.de> >>> wrote: >>> >>>> Hi, >>>> >>>> it looks like my initial reply wasn't entirely correct. It should build >>>> if you pass in both the `.go` file and the `.c` file. >>>> On 18.03.20 15:02, Nitish Saboo wrote: >>>> >>>> Hi Gregor, >>>> >>>> nitish >>>> main.go >>>> node.c >>>> node.h >>>> >>>> I compiled using 'go build -v -x main.go' >>>> But if my cgo directive is defined in main.go, this should have >>>> compiled successfully..right? But it fails with the following whereas 'go >>>> build -v -x' works fine. >>>> >>>> /tmp/go-build439591561/b001/_x002.o: In function >>>> `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': >>>> /tmp/go-build/cgo-gcc-prolog:86: undefined reference to >>>> `load_pattern_db' >>>> collect2: error: ld returned 1 exit status >>>> >>>> package main >>>> >>>> //#include <stdlib.h> >>>> //#include "node.h" >>>> import "C" >>>> import ( >>>> "fmt" >>>> _ "fmt" >>>> "os" >>>> "path" >>>> "unsafe" >>>> ) >>>> >>>> Please let me know what am I missing here? >>>> >>>> Thanks, >>>> Nitish >>>> >>>> On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo <nitish...@gmail.com> >>>> wrote: >>>> >>>>> Hi Gregor, >>>>> >>>>> Got your point.Thank you for your response. >>>>> That explains why the binaries have different names post compilation. >>>>> >>>>> Thanks, >>>>> Nitish >>>>> >>>>> >>>>> On Wed, Mar 18, 2020 at 7:06 PM Gregor Best <be...@pferdewetten.de> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> In both `go build main.go`-examples, you tell the compiler to _only_ >>>>>> build `main.go`. >>>>>> >>>>>> In your first example, `main.go` probably imports both `util` and >>>>>> `lib` (you might want to give them less generic names by the way). The >>>>>> go >>>>>> compiler thus knows "to build `main.go`, I need to build both `util` and >>>>>> `lib` and link them in". >>>>>> >>>>>> In the second example, it has no way of knowing where >>>>>> `load_pattern_db` comes from, since you didn't tell it to compile a file >>>>>> that defines that function. >>>>>> >>>>>> The examples where you omit the `main.go` tell the compiler "build >>>>>> the package in this directory", which includes all `.go`-files in the >>>>>> directory. `node.c` and `node.h` are likely built because of `cgo` >>>>>> directives in `a.go`. >>>>>> >>>>>> The compiler and linker did exactly as you told them to. >>>>>> On 18.03.20 14:17, Nitish Saboo wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> *Case 1 ---------- * >>>>>> I have a project called 'nitish' where the folder structure looks >>>>>> like the following: >>>>>> >>>>>> nitish >>>>>> main.go >>>>>> util >>>>>> util.go >>>>>> lib >>>>>> node.c >>>>>> node.h >>>>>> a.go >>>>>> >>>>>> When I try compiling this project in the following ways: >>>>>> >>>>>> 1) go build -v - x >>>>>> >>>>>> >> This creates a binary called 'nitish' >>>>>> >>>>>> 2) go build -v - x main.go >>>>>> >>>>>> >> This creates a binary called 'main' >>>>>> >>>>>> ldd output of both the binaries is the same. >>>>>> >>>>>> >>>>>> >>>>>> *Case 2 ----------* >>>>>> >>>>>> Now, when I restructure the project 'nitish' in the following manner: >>>>>> >>>>>> nitish >>>>>> main.go >>>>>> util.go >>>>>> node.c >>>>>> node.h >>>>>> a.go >>>>>> >>>>>> When I try compiling this project in the following ways: >>>>>> >>>>>> 1) go build -v - x >>>>>> >>>>>> >> This creates a binary called 'nitish' >>>>>> >>>>>> 2) go build -v - x main.go >>>>>> >>>>>> >> This error out with the following: >>>>>> >>>>>> /tmp/go-build074530518/b001/_x002.o: In function >>>>>> `_cgo_8eab385aa676_Cfunc_load_pattern_db': >>>>>> /tmp/go-build/cgo-gcc-prolog:86: undefined reference to >>>>>> `load_pattern_db' >>>>>> collect2: error: ld returned 1 exit status >>>>>> >>>>>> >>>>>> 1) In Case 1, why the binaries are created with different names >>>>>> though both the binaries have the same 'ldd output' and work the same >>>>>> manner? >>>>>> >>>>>> 2) Why we see an error with the command 'go build -v - x main.go' in >>>>>> Case 2 but not in Case 1? >>>>>> >>>>>> Thanks, >>>>>> Nitish >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "golang-nuts" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to golan...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>>> -- >>>>>> Gregor Best >>>>>> be...@pferdewetten.de >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "golang-nuts" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to golan...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/d23423e6-f204-8e63-436b-aa3730013392%40pferdewetten.de >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/d23423e6-f204-8e63-436b-aa3730013392%40pferdewetten.de?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> -- >>>> Gregor Best >>>> be...@pferdewetten.de >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/cfddeb60-03af-4f87-a6a8-74f76fb069a5%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/cfddeb60-03af-4f87-a6a8-74f76fb069a5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a0d2fca4-951d-4661-bf08-8010d13bd48b%40googlegroups.com.
