Undefined symbols on macOS during static build #618
Labels
No Label
bug
duplicate
enhancement
invalid
question
up for grabs
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jcarr/git2go#618
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Howdy,
First of, thanks for this work 💌
I'm trying to statically build a binary but it seems that I'm missing a lot of symbols. Googling/installing potential missing packages didn't fix anything. I looked at many different repositories (basically this) but couldn't find anything up-to date or that fixed my issue.
Setup
macOS 10.15.5 (19F101)
go version go1.13.5 darwin/amd64
git2go tags/v30.0.3
libgit2 tags/v1.0.0
For non-static tests I use
libgit2 v1.0.0
installed this way:Code
Results for
dynamic
With
libgit2
installed viabrew
, results are as expected:Without
libgit2
installed,dynamic
building fails as expected:Results for
static
Preparation, as explained in here:
There are a few tests failed and some missing elements, but since the build was not aborted, I assumed it was not problematic.
output
output
Do you see anything that can explain why all those symbols are missing?
Thanks,
thanks for writing such a nice report!
I think I managed to reproduce the issue: What I think is happening is that since
go build
is being invoked without the-tags=static
bit (which after reading theREADME.md
is semi-implied and only mentioned in the Running the tests section in passing, so we should probably do something to make it more explicit that it's required), the code ingit_static.go
is ignored and the one ingit_dynamic.go
kicks in, which causespkg-config
to be all sorts of confused and pass in the wrong flags.But passing in
-tags=static
would cause the go build system to look for the file in the wrong location, so what I do in my projects is to have the following in thego.mod
file:(or the correct relative path to the
git2go
checkout wheremake install-static
was run).I'll try to amend the
README.md
file to include all this information to avoid confusion. And I hope this solves your problem!btw, https://github.com/libgit2/git2go/pull/619 should take care of one of the innocuous warnings you found (yay for fewer red herrings!).
Hi @lhchavez, thanks so much for this answer 😃
Following your advice I made my setup work. For the sake of completion, here's a working setup:
main.go
remains unchanged.In
./vendor
I did the following:I couldn't find a way to have the
replace
point to the installedgit2go
inside$GOPATH
, so I'll have to vendor it for now. I imagine that it can be used only for building, so it's not too problematic (unless there's something I've missed).Also removed
-ldflags '-extldflags "-static"'
from thego build
command, it's not supported on macOS apparently. I used that in the past to have 100% static binary to runFROM scratch
in docker, but I macOS doesn't like that (ref).Thanks again, feel free to close this 🙂
After a bit more thought, would https://github.com/libgit2/git2go/pull/621 (the introduction of the
-tags static,system
) help you remove some of the workarounds?Neat! 🙂
Is there any drawbacks to use a staticaly built version of
libgit2
/git2go
?For now I think I will stick to vendor
git2go
and have a clear control over it (i.e.brew install something
feels more magical to me). My current setup is now:git2go
-tags=static
everywhereI've found it has no impact on performance, testing or anything.
Aside from having slightly larger binaries, not that I know of. The other main downside of statically-linked libraries is that updating the dependencies requires rebuilding all the binaries that use them. But in this case, the whole go ecosystem is built around the idea that most binaries are statically-linked anyways.
Sounds good. I do the same thing (vendoring
git2go
) myself, but wanted to see if this was something that was useful to other folks.Same here. In fact, bundling the statically-built library can have debugging advantages, like https://github.com/libgit2/git2go/pull/577
Thanks for the info 🙂