I am running Angstrom ( v2012.12) on my BeagleBone Black (Linux beaglebone 3.8.13 #1 SMP Thu Sep 12 10:27:06 CEST 2013 armv7l GNU/Linux). I am using the following gcc:
COLLECT_GCC=arm-angstrom-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.7.3/lto-wrapper
...
gcc version 4.7.3 20130205
I needed to install some library on BBB and while running the script I got this error: "gcc: error: unrecognized command line option -m32". After googling around I figured out that I need a cross compilation to be able to do that (I hope that is the right way, perhaps I am doing something wrong). I started looking for the appropriate toolchain: angstrom-eglibc-i686-armv7a-vfp-neon-v2012.12-toolchain.gz, but I did not find too much. Since http://www.angstrom-distribution.org/toolchains is still out of order I only found a few place where I could get the archive, but it was corrupted.
So my questions are the following.
Am I correct with all this cross compilation stuff, would it help we to solve my problem?
If I am on the right track can somebody share a toolchain packet or give a valid link.
I would really appreciate any help. Many thanks in advance
I found a workaround to that problem. Eventually I adjusted the installation script to omit undesired options ("-m32" in this case) and it worked.
Related
everyone.
I am currently using a phycore am65x embedded board. I'm a student, and I don't know much because it's my first time dealing with Embedded. So I need your help. As mentioned earlier, the phycore am65x board does not cover packages. It turned out that it was an arago project (yocto) and apt-get didn't work. The problem I am trying to solve is that the goal is to install gcc on the board and compile c on the board (error erasing gcc). How can I fix this? I need your help.
Reference
uname -a: Linux am65xx-phycore-kit 4.14.79-g9d8d0716d0 #1 SMP PREEMPT Wed Jul 10 17:37:42 UTC 2019 aarch64 GNU/Linux
cat /etc/issue:
Arago Project http://arago-project.org \n \l
Arago 2018.10 \n \l
PHYTEC: BSP-Yocto-TISDK-AM65xx-ALPHA1
It should be fairly simple to install gcc in any linux distribution. Go to this site, https://gcc.gnu.org/wiki/InstallingGCC download the tar and install it according the instructions on the same site. Alternatively, if you have access to the Yocto project and can bitbake it again you can add to the local.conf
IMAGE_INSTALL_append= " libgcc"
or something similar.
https://gcc.gnu.org/wiki/InstallingGCC
Well as life tends to be frustrating, i have found yet another interesting bug in the great conglomerate of which makes up VS-Code and it's list of 'useful' extensions...
Back Story:
To begin - i purchased a new Sony - Spresense Main Board and Expansion Board for development and testing purposes. Everything arrived in great shape with the highest quality of product and packaging.
The First Step:
As with every micro-controller purchased, I always test every aspect offered with the device when it comes to programming. I used the well known Arduino ide to throw a few basic examples on the Spresense main board. They all flashed correctly, worked properly and i was happy to see the device works!
The Problem:
At this point i had gotten my fill of using the arduino ide... I decided to download the vscode extension , following the vscode setup guide provided by Sony Spresense Web Site.
I noted the "setup guide" was using out of date versions from the most up to date available versions.
I tried using the both older and most recent version with same issues.
Every step was followed perfectly and matches the setup guide to the T.
VsCode installs and loads the extension, workspace and workspace configuration properly.
I also followed the instruction for installing the MSYS2 on windows and verified it was working correctly
The All Stop Error:
Excited to see my first hello world printf statment cruise thru the serial terminal i began the project spresense application build.
The Makefile proceeds thru the steps checking directories and performing required duties.
Suddenly towards the end of the make build i get --- BUILD ERROR
make[3]: Entering directory '/c/msys64/home/Anon/spresense/sdk/apps/builtin'
In file included from C:/msys64/home/Anon/spresense/nuttx/include/sys/types.h:47:0,
from C:/msys64/home/Anon/spresense/nuttx/include/nuttx/lib/builtin.h:51,
from ./builtin_list.c:44:
C:/msys64/home/Anon/spresense/nuttx/include/stdint.h:49:12: fatal error: C:/msys64/home/Anon/spresense/nuttx/include/arch/types.h: Invalid argument
include <arch/types.h>
compilation terminated.
ERROR: arm-none-eabi-gcc failed: 1
command: arm-none-eabi-gcc -M -fno-builtin -mabi=aapcs -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -Wundef -g -Os -fno-strict-aliasing -fno-strength-reduce -fomit-frame-pointer -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -I. -isystem /c/msys64/home/Anon/spresense/nuttx/include -isystem /c/msys64/home/Anon/spresense/nuttx/../sdk/include -D__KERNEL__ -pipe -gdwarf-3 -I /c/msys64/home/Anon/spresense/sdk/apps/include ./builtin_list.c
make[3]: *** [/c/msys64/home/Anon/spresense/sdk/apps/Application.mk:209: .depend] Error 1
make[3]: Leaving directory '/c/msys64/home/Anon/spresense/sdk/apps/builtin'
The Make proceeds to throw 10 or so more errors of the same variety, all invalid argument..
I feel like this should be working... I mean with all the fan fair behind this product line one would think the basic setup guide and IDE should work out of the box...
I think i am figuring out why this product line is failing miserably in the public realm...
The Most Basic of Code
#include <sdk/config.h>
#include <stdio.h>
int myAppS_main(int argc, char *argv[])
{
printf("Hello Spresense!!!");
return 0;
}
I have spent a few days trying to make heads or tails of this but from what i can tell, Sony has a broken extension offered thru vscode.
I have to admit i am a bit stumped....
Developing under win10, may try using linux as this appears to be an issue with Win10 using MSYS2 terminal.
I did a same steps with my spresense board, lastweek.
But I did not face this problem...
And I interested of this.
So, if you provide more information, I will investigate it!
Does the file C：/msys64/home/Anon/spresense/nuttx/include/arch/types.h exist? And can you open the file?
What did you choice in SDK Config? (Nothing as default?) If you OK to provide a "sdk.config", could you share it in this page?
Did you use your spresense sdk (/c/msys64/home/Anon/spresense) for another things?(Build check, or configuration or etc...)
What is your MSYS2 version?
And I think, you might can recover your environment with next command, could you try it?
$ cd /c/msys64/home/Anon/spresense/sdk
$ make distclean
Well,
Thanks to #cmm for the confirmation on the build integrity.
I was able to install the dev stack on another windows 10 computer, without the latest feature update. Just to be sure that was not creating an issue.
In my great quest for knowledge, i feel i may have found a solution to my problem after researching this in great length.
What I could verify:
VS Code was fully updated
MSYS2 was properly installed and updated fully from terminal
VS Code extension version is 1.20 updated to current release
Terminal was set in VS Code to MSYS directory and accepted for changes
SDK configuration was default with no additional config options
Project folder location and SDK location are properly set in workspace config
Every step was completed as per the Getting Started with SDK guide described
What I Think Happened
...... Internet Security Program........
During the install of MSYS2 and Vs Code ext i was not paying close attention to the install process. I simply let it run as i went about my work. During this process unbeknownst to me a number of attempts were made and blocked by my firewall and internet security protocols.. I really cannot believe how stupid this whole issue might actually be...
It appears certain sub modules are fetched from different server locations. I checked my firewall logs and for some reason these connection attempts are flagged and blocked.
Always Watch Your INSTALL!!
After whitelisting the flagged connection attempts and full dev stack refresh/re install i was able to build past the issues that plagued me so intensively...
To anyone that encounters this issue, i believe the issue lies in the install process and ensuring proper connections to external servers during MSYS install.
I have to say... This one threw me for one heck of a loop.... :P
I am getting this error:
Error in invoking target 'client_sharedlib' of makefile '/u01/app/oracle/product/12.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk'.
Looking in the make.log, I see this error:
/usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a
Doing: locate libpthread_nonshared, I get this response:
/home/romio/libpthread_nonshared.a
/usr/lib/x86_64-linux-gnu/libpthread_nonshared.a
which I guess means that the relevant lib is already on my computer.
But I don't know how to proceed from here. How do I tell the program to look the place with the library is? I come from Windows, so I'm yet very weak with Linux. I am running on Ubuntu 16.04
And I guess moving the package to the location oracle is searching must be a bad idea, since there might be other programs that use the package in its current location?
You are using an unsupported linux distribution. You are pretty much on your own. I'd suggest to use a supported linux distribution.
I am trying to install Sybase ASE 12.5.4 on a Sun OS Solaris 11 machine but I am getting the following messages when launching the setup file :
-bash-4.1$ ./setup
InstallShield Wizard
Initializing InstallShield Wizard...
Searching for Java(tm) Virtual Machine...
Bad System Call (core dumped)
Would you have any idea of what could cause this? I want to run a trace on this to see what's missing exactly but I cannot find how to.
Thank you for your help.
Cheers
Do not use this hacks on production systems!
Many system calls were deprecated in Solaris 11, access seem to be deleted:
$ grep access /usr/include/sys/syscall.h
#define SYS_faccessat 45
Some of them are still accessible from Solaris 10 brand zones, some seem to be gone forever. Instead you have to use "at"-functions with AT_FDCWD param, in your case it is faccessat. That change was hidden by libc, but if Sybase brings their own libc things go bad, if they statically link with it, it is even worse.
If access is a shared library function in their own libc, you can still workaround that by using LD_PRELOAD hack. Write the following source:
#include <unistd.h>
#include <sys/fcntl.h>
int access(const char *fname, int amode) {
return (faccessat(AT_FDCWD, fname, amode, 0));
}
Compile it with GCC or Solaris Studio (depends on what Sybase used, probably Solaris Studio) into shared library:
$ gcc -shared -fPIC xaccess.c -o libaccess.so
Export LD_PRELOAD variable:
$ export LD_PRELOAD=./libaccess.so
And pray for luck because it may fail at another system calls, or you used wrong compiler, etc. Note that Sybase binaries may not run correctly too!
Have I warned about hacks on production systems? Instead, use brand Solaris 10 zones or Solaris 10 LDoms/VMs
Thank you all for your replies.
myaut was right when saying:
Many system calls were deprecated in Solaris 11, access seem to be deleted
My problem therefore seemed related to a incompatibility between Sybase ASE 12.5.4 and Solaris 11 as this link shows: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc35889_1254/html/installsol/X22779.htm
Sybase ASE 12.5.4 is compatible with Solaris 2.8 (therefore Solaris 8) and I got from the SAP forum that it is 100% compatible with Solaris 9 and most likely with Solaris 10 too but clearly, it doesn't seem to be with Solaris 11.
I have managed to launch the setup from a Solaris 10 machine and it seems to work perfectly fine.
Thank you for your help.
Regards,
I have tried one day to install glibc-2.11 for sublime text.
My system is centoS 5.5 64, every time I attempted to install glibc-2.11, it ends up with configure: error: assembler too old, .cfi_personality support missing. I know it is that my system is too old. But I want to know if there is anyone have good ways to solve it.
P.S. The app of sublime test requires GLIBC 2.11.
I know it is that my system is too old.
Please note that unless done very carefully, updating glibc may easily render your system un-bootable.
The solution to configure problem is easy: update binutils first. This will give you assembler that supports .cfi directives.
Once that's done, you should be able to configure and build glibc itself.
P.S. If you don't want to update the system binutils, you can configure binutils to use a different --prefix, and set your PATH to point to that alternate location while configuring and building glibc.