Closed sctincman closed 10 years ago
browndeer
commented
10 years ago Thanks for identifying these issues with arch Linux build. I will try to get these into the 1.6 branch. May I ask what hardware platform this was targeting with arch Linux?
sctincman
commented
10 years ago This was originally done on ARM (Odoid U3), but I have tested it on x86_64 (core i5) as well. Part of a preemptive effort to get Arch Linux running on the Parallella.
browndeer
commented
10 years ago Most of these issues should be addressed with commits to the stable-1.6 branch. The ELF related issues need to be looked at closer since it has been a complicated source of issues for cross-platform portability. The way Android was dealt with can be seen associated with the configure switch --enable-android-cross-compile. However it appears you are using an Android platform directly(?) so that would not be suitable. Need to make sure the changes do not break the build elsewhere. If you look at the dev-android branch there is an app note on cross-compiling with the Android NDK. This doc was not propagated forward to the 1.6 branch so you might not have seen it. It deals with the ELF issue directly with required patch to libelf.
sctincman
commented
10 years ago Excellent, thanks for the changes. I'll merge and test them as soon as I can.
Yes, this is just plain Linux running on Arm. But, I do see my error now. I had assumed since my system libelf (from elfutils upstream) defined Elf32_Xword as uint64 (even on 32-bit) this would be safe, but I see now it'll be picked up by the android build as well.
Perhaps this is better fixed by an additional typedef in the else clause from Android (unless MIC also has weirdness with libelf). Or changing the android typedef to define Elf64_Xword as Elf32_word?
sctincman
commented
10 years ago My apologies, I should have made this a separate branch before submitting a pull-request. I'm attempting to sync my tree up with the newest changes, and to prevent this request from getting messed up, I hope you do not mind if I close this and just open a separate bug report for the remaining libelf issue.
browndeer
commented
10 years ago No problem at all. Even if I do not literally pull these requests, the commits provide useful information for addressing the issues.
sctincman wrote:
My apologies, I should have made this a separate branch before submitting a pull-request. I'm attempting to sync my tree up with the newest changes, and to prevent this request from getting messed up, I hope you do not mind if I close this and just open a separate bug report for the remaining libelf issue.
— Reply to this email directly or view it on GitHub https://github.com/browndeer/coprthr/pull/16#issuecomment-44442293.
David Richie, Ph.D. Brown Deer Technology 1641 Denwright Court Forest Hill, MD 21050 410-459-3848 drichie@browndeertechnology.com www.browndeertechnology.com
sctincman
commented
10 years ago True, and while I clobbered this syncing, I had first moved them to a new branch, "arch-compilation-fixes", if you need to reference them.
Mostly related to properly linking legacy libelf without conflicting with system's libelf
There is also a conflict related to linking flex in xclnm, and the only solution I found is not to link it. I do not have another platform to test this, but I think it's related to newer versions of flex changing "yylex" behavioir. I've left this as a separate commit so it can be left out of the merge if '-lfl' is needed in that case.