FAQ
Hi,

I'm trying to statically link an ar archive file "libfoo.a" using cgo.
I tried this in the header of one my files:

// #cgo: LDFLAGS: libfoo.a
import "C"

And this actually makes "go build", "go test", etc. to all work fine
from that directory.

But when another library depends on that Go library, running `go test`
is getting me an error about clang not being able to find "libfoo.a".
Why is it even looking for that if I statically linked? (I clearly
didn't).

Also, I tried adding "-static" to the LDFLAGS but then I get errors
about libcrt0.a not being found, which looks like a weird gcc error to
me, and not sure why its looking for the runtime with Go.

Any tips?

Thanks,
Mitchell

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Mar 26, 2014 at 1:18 am

    On Tue, Mar 25, 2014 at 4:35 PM, Mitchell Hashimoto wrote:

    I'm trying to statically link an ar archive file "libfoo.a" using cgo.
    I tried this in the header of one my files:

    // #cgo: LDFLAGS: libfoo.a
    import "C"

    And this actually makes "go build", "go test", etc. to all work fine
    from that directory.

    But when another library depends on that Go library, running `go test`
    is getting me an error about clang not being able to find "libfoo.a".
    Why is it even looking for that if I statically linked? (I clearly
    didn't).
    The static linking occurs at, well, link time. It does not occur when
    you build the package itself, but when you build your main package.
    At link time your main package is going to look for libfoo.a, and not
    find it.

    If possible, an easy workaround should be to use an absolute path to
    libfoo.a.

    Also, I tried adding "-static" to the LDFLAGS but then I get errors
    about libcrt0.a not being found, which looks like a weird gcc error to
    me, and not sure why its looking for the runtime with Go.
    I don't know what went wrong here, but libcrt0.a does not sound right.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mitchell Hashimoto at Mar 26, 2014 at 4:21 am
    Ian,

    Thanks for the quick response. A real quick question below:
    On Tue, Mar 25, 2014 at 6:18 PM, Ian Lance Taylor wrote:
    On Tue, Mar 25, 2014 at 4:35 PM, Mitchell Hashimoto
    wrote:
    I'm trying to statically link an ar archive file "libfoo.a" using cgo.
    I tried this in the header of one my files:

    // #cgo: LDFLAGS: libfoo.a
    import "C"

    And this actually makes "go build", "go test", etc. to all work fine
    from that directory.

    But when another library depends on that Go library, running `go test`
    is getting me an error about clang not being able to find "libfoo.a".
    Why is it even looking for that if I statically linked? (I clearly
    didn't).
    The static linking occurs at, well, link time. It does not occur when
    you build the package itself, but when you build your main package.
    At link time your main package is going to look for libfoo.a, and not
    find it.

    If possible, an easy workaround should be to use an absolute path to
    libfoo.a.
    Extremely obvious in retrospect, thanks!

    One question: can I use env vars or something in that LDFLAGS param?
    It'd be great if I could do `LDFLAGS: $GOPATH/blah`

    Best,
    Mitchell
    Also, I tried adding "-static" to the LDFLAGS but then I get errors
    about libcrt0.a not being found, which looks like a weird gcc error to
    me, and not sure why its looking for the runtime with Go.
    I don't know what went wrong here, but libcrt0.a does not sound right.

    Ian
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 26, 2014 at 5:48 am

    On Tue, Mar 25, 2014 at 9:20 PM, Mitchell Hashimoto wrote:

    One question: can I use env vars or something in that LDFLAGS param?
    It'd be great if I could do `LDFLAGS: $GOPATH/blah`
    You can't.

    On the other hand, you can set CGO_LDFLAGS in the environment.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Hemington at Mar 26, 2014 at 5:50 am
    I don't think so. I believe this is all related to relative paths not
    working in cgo LDFLAGS (issue 5428<https://code.google.com/p/go/issues/detail?id=5428>
    ).

    Stephen
    On Tuesday, March 25, 2014 9:20:34 PM UTC-7, Mitchell Hashimoto wrote:

    Ian,

    Thanks for the quick response. A real quick question below:
    On Tue, Mar 25, 2014 at 6:18 PM, Ian Lance Taylor wrote:
    On Tue, Mar 25, 2014 at 4:35 PM, Mitchell Hashimoto
    <mitchell....@gmail.com <javascript:>> wrote:
    I'm trying to statically link an ar archive file "libfoo.a" using cgo.
    I tried this in the header of one my files:

    // #cgo: LDFLAGS: libfoo.a
    import "C"

    And this actually makes "go build", "go test", etc. to all work fine
    from that directory.

    But when another library depends on that Go library, running `go test`
    is getting me an error about clang not being able to find "libfoo.a".
    Why is it even looking for that if I statically linked? (I clearly
    didn't).
    The static linking occurs at, well, link time. It does not occur when
    you build the package itself, but when you build your main package.
    At link time your main package is going to look for libfoo.a, and not
    find it.

    If possible, an easy workaround should be to use an absolute path to
    libfoo.a.
    Extremely obvious in retrospect, thanks!

    One question: can I use env vars or something in that LDFLAGS param?
    It'd be great if I could do `LDFLAGS: $GOPATH/blah`

    Best,
    Mitchell
    Also, I tried adding "-static" to the LDFLAGS but then I get errors
    about libcrt0.a not being found, which looks like a weird gcc error to
    me, and not sure why its looking for the runtime with Go.
    I don't know what went wrong here, but libcrt0.a does not sound right.

    Ian
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Drew Wells at Dec 26, 2014 at 2:11 pm
    libcrt0.a is because OS X does not make available static libs for gcc (or
    static libs for any system level libraries). I also am not getting static
    compiled libs using this mechanism. The output bin is definitely larger
    when specifying libfoo.a, but I still get dynamic link errors from the
    output binary when dynamic libs are removed from system folder.
    On Tuesday, March 25, 2014 6:35:51 PM UTC-5, Mitchell Hashimoto wrote:

    Hi,

    I'm trying to statically link an ar archive file "libfoo.a" using cgo.
    I tried this in the header of one my files:

    // #cgo: LDFLAGS: libfoo.a
    import "C"

    And this actually makes "go build", "go test", etc. to all work fine
    from that directory.

    But when another library depends on that Go library, running `go test`
    is getting me an error about clang not being able to find "libfoo.a".
    Why is it even looking for that if I statically linked? (I clearly
    didn't).

    Also, I tried adding "-static" to the LDFLAGS but then I get errors
    about libcrt0.a not being found, which looks like a weird gcc error to
    me, and not sure why its looking for the runtime with Go.

    Any tips?

    Thanks,
    Mitchell
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marvin Humphrey at Dec 26, 2014 at 5:21 pm
    Hi,

    Note: this thread has been revived from 9 months ago.

    I'll comment below on one aspect of the original post which was never
    addressed.
    On Fri, Dec 26, 2014 at 6:11 AM, Drew Wells wrote:
    libcrt0.a is because OS X does not make available static libs for gcc
    (or static libs for any system level libraries).
    Indeed.

         https://developer.apple.com/library/mac/qa/qa1118/_index.html

         Apple does not support statically linked binaries on Mac OS X. A
         statically linked binary assumes binary compatibility at the kernel
         system call interface, and we do not make any guarantees on that
         front. Rather, we strive to ensure binary compatibility in each
         dynamically linked system library and framework.
    On Tuesday, March 25, 2014 6:35:51 PM UTC-5, Mitchell Hashimoto wrote:

    I'm trying to statically link an ar archive file "libfoo.a" using
    cgo. I tried this in the header of one my files:

    // #cgo: LDFLAGS: libfoo.a
    import "C"

    And this actually makes "go build", "go test", etc. to all work fine
    from that directory.

    But when another library depends on that Go library, running `go
    test` is getting me an error about clang not being able to find
    "libfoo.a". Why is it even looking for that if I statically linked?
    (I clearly didn't).
    This is a side effect of a subtle but documented behavior.

    Let's say that the Go package which incorporates `libfoo.a` is named
    `gofoo`. That "cgo: LDFLAGS" directive present in the `gofoo/gofoo.go`
    source code gets added to the linker flags for **any** program which
    incorporates `gofoo` -- such as the tests for that downstream package
    which depends on `gofoo`.

         http://golang.org/cmd/cgo/#hdr-Using_cgo_with_the_go_command

         All the CPPFLAGS and CXXFLAGS directives in a package are
         concatenated and used to compile C++ files in that package. All the
         LDFLAGS directives in any package in the program are concatenated
         and used at link time.

    If you examine the `gofoo.a` file which gets installed under $GOPATH/pkg
    as a result of `go build gofoo`, you will see that it does not contain
    `libfoo.a`. (Interesting commands include `otool -L libfoo.a`,
    `otool -t -v libfoo.a`, and `nm libfoo.a`.)

    Since `libfoo.a` was not embedded in `gofoo.a` when `gofoo.a` was built,
    `libfoo.a` must continue to remain available for as long as other
    programs need to be built which `import "gofoo"`. However, at least
    `libfoo.a` won't need to be present at runtime.

    Marvin Humphrey

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 25, '14 at 11:36p
activeDec 26, '14 at 5:21p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase