Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-compilation Go and Goc "symbol not found" error message on ARM #41

Open
ro31337 opened this issue Jul 19, 2022 · 0 comments
Open

Comments

@ro31337
Copy link

ro31337 commented Jul 19, 2022

I'm trying to build a Go program for my LinkSys MR8300 V1.1 router, which has armv7l processor (uname -a output), which is ARM v7, 32-bit CPU. I have OpenWrt operating system installed on the router.

The idea of the app is to connect USB coin acceptor, and enable internet for 30 minutes when you drop a coin. I have working app on the Ubuntu desktop which understands the device, and on desktop everything's fine.

However, the router is 32 bit, and ARM, so things are little bit different and more complicated.

cat /proc/cpuinfo on my router gives something like this:

processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 26.81
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

I'm using cross-compilation, since the router has only 19MB of disk space (and not all of the development packages are available).

For cross-compilation I'm using x86_64 Ubuntu desktop, and toolchain provided by OpenWrt. I'm already past the point when you need to configure and make the toolchain. I was able to compile and execute the basic C programs on my router, like:

#include <stdio.h>

int main()
{
  printf("Hello World");
  return 0;
}

And even Go programs like:

package main

func main() {
        println("Coin acceptor device control program")
}

When I upload binaries to the router they work, there is no any problem with that.

Problems start when I try to use USB library inside the router. Since it's cross-compilation, I should mention environment variables I have:

STAGING_DIR=/home/ro/work/openwrt/staging_dir
TOOLCHAIN_DIR=/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi
LDCFLAGS=/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi/usr/lib
LD_LIBRARY_PATH=/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi/usr/lib
LDFLAGS=-L/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi/usr/lib
CGO_LDFLAGS=-L/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi/usr/lib
CFLAGS=-I/home/ro/work/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.3.0_musl_eabi/include
CC=arm-openwrt-linux-gcc
GOARCH=arm
CROSS_COMPILE=arm-openwrt-linux-gcc
CGO_ENABLED=1
GOOS=linux
GOARM=7

With these environment variables go get github.com/karalabe/hid command works as expected (there is hid.a binary in my /home/ro/go/pkg/linux_arm/github.com/karalabe folder).

However, this library has dependencies on some C libraries... So here is where GOC comes into play I guess.

As I mentioned before, I can compile simple apps on my Desktop and upload them to the router, and these apps work! However, when I try to use the library, things go little bit off the script.

Here is the app I have:

main.go

package main

import (
        "fmt"
)

func main() {
        println("Hello")

        devices := FindAll(0x0079)

        if len(devices) == 0 {
                fmt.Println("No coin acceptor found")
                return
        }

        println("Found coin acceptor")
}

device.go

package main

import (
	"errors"
	"github.com/karalabe/hid"
)

type Device struct {
	info hid.DeviceInfo
	dev  *hid.Device

	Name string
	PID  uint16
}

func (device *Device) Open() error {
	if device.dev != nil {
		return errors.New("device: Device handle is not null, but Open() called")
	}

	var err error
	device.dev, err = device.info.Open()

	return err
}

func (device *Device) Close() error {
	if device.dev == nil {
		return errors.New("device: Close() called for Device with null handle")
	}

	err := device.dev.Close()
	device.dev = nil

	return err
}

// Find all products with the given product ID.
func FindAll(product uint16) []Device {
	deviceInfo := hid.Enumerate(0x1e7d, product)

	if len(deviceInfo) == 0 {
		return []Device{}
	}

	devices := make([]Device, len(deviceInfo))

	for i, info := range deviceInfo {
		devices[i] = Device{
			info: info,
			Name: info.Product,
			PID:  product,
		}
	}

	return devices
}

Command I use to build a thing:

go build ./main.go ./device.go

The binary gets produced, and things look normal. Until the point when I upload and run the binary on the router. It pretty much says:

Error relocating ./main: __pthread_cond_timedwait_time64: symbol not found
Error relocating ./main: __nanosleep_time64: symbol not found
Error relocating ./main: __stat_time64: symbol not found
Error relocating ./main: __clock_gettime64: symbol not found

And that's it. It doesn't even print "Hello".

One thing to notice is that it has references to (and complains about) 64-bit functions for some reason. So, to sum this up:

  • This is 32-bit ARM CPU.
  • I can run simple C and Go programs, so I assume that my C and Go compiles provide correct binaries for the 32-bit CPU.
  • When I try to attach the library none of the compilers (I assume the app gets compiled using Go and Goc) complains about using 64-bit functions.
  • The binary itself complains about 64-bit functions.

I'm wondering what am I missing? What flags should I specify to the compiler(s) so there is no 64-bit functions usage? Maybe there is something inside these USB libraries written in C? I kinda ran out of any ideas and pretty much stuck at this point, since I cannot use my USB device with embedded OpenWrt device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant