-
Notifications
You must be signed in to change notification settings - Fork 440
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
Linker issues when compiling for ARM target + FEC detection question #90
Comments
Chiming in - I've built liquid-dsp (for windytan's redsea amongst others) just fine on Ubuntu 16.04 and Debian 8 and 9, on both 32b and 64b ARM platforms. Cheers! |
Did you have to do anything special, say, before running the bootstrap
script, or while running the configure script, aside from specifying host
and build?
…On Tue, May 16, 2017 at 06:34 Ian Daniher ***@***.***> wrote:
Chiming in - I've built liquid-dsp (for windytan's redsea amongst others)
just fine on Ubuntu 16.04 and Debian 8 and 9, on both 32b and 64b ARM
platforms.
Cheers!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL3tMCNH5-0CK7gjLv46mu-nNVkHe_ywks5r6YmqgaJpZM4NbfLn>
.
|
Not that I recall. What distro are you targetting? |
It's a custom Busybox distro built using LinuxLink. Though we are using the
vendor provided toolchain. The difference comes right at link time; the
native compiler has a "-L/path/libfec.a" and the vendor provided one does
not. Is this something we could force using the configure script? Or is it
possible this needs to happen during the build step?
…On Tue, May 16, 2017 at 08:23 Ian Daniher ***@***.***> wrote:
Not that I recall. What distro are you targetting?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL3tMAnuzOERV8lrGAQVvDpyjQFkNVffks5r6aMzgaJpZM4NbfLn>
.
|
We fixed this by defining CPPFLAGS and CFLAGS to manually include the headers and static libraries required during the CONFIGURE_COMMAND part of our ExternalProject_Add() |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm a Linux dev for a university CubeSat team, and we hope to use your frontend to apply Reed-Solomon encoding to our radio transmissions for FEC.
How can we detect the number of bit errors if we don't have the original message present on the receiving end? All of the example programs simply use the original message to do this, but I thought Reed-Solomon has some sort of built in "parity checking" that you can use to gauge if you're past the number of correctable errors.
We're compiling libfec for the MitySOM335x and are seeing the following errors:
Related to not finding malloc:
Everything compiles and works fine natively, so it's possible that our CMake setup is not passing options appropriately to autoconf. Here's what we're using to pull in your project:
The important bit is the ${CDH_AUTOCONF_HOST} and ${CDH_AUTOCONF_BUILD} variables, which have respective values of
--host=arm-arago-linux-gnueabi
and--build=i386-pc-linux-gnu
I think this has something to do with the include directories used by cmake not being properly passed into autoconf, though that's just a guess. Have you all successfully built this library for ARM targets before?
The text was updated successfully, but these errors were encountered: