I am trying to prepare development environment as Docker container for pretty old project written in C.
I chose Ubuntu 20.04, previously it was CentOS 6.5 - no conflict between these two OSs.
Compiler: GCC 10
Unfortunately, file called "sigset.h" cannot be found - this file is marked as obselete.
Any idea how to fix it without interfering with the code?
Related
I'm using the MYD-Y6ULX-HMI series boards supports the Linux kernel version 4.1.15, and provided with rich hardware and software resource. They recommend to use Ubuntu 16.04 64bit distribution. For more details about the devkit
-> http://www.myirtech.com/list.asp?id=602
-> http://d.myirtech.com/MYD-Y6ULX-HMI/
By referring their usermanual,
(1) Installed virtualBox with Ubuntu 16.04 64bit distribution
(2) Installed software package and made the working directory in root.
(3) Installed Yocto toolchain:gcc version 5.3.0(GCC) - for driver(metatoolchain)
After installation sourced the env file:
source /opt/myir-imx6ulx-fb/4.1.15-2.0.1/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
and checked the compiler version:
arm-poky-linux-gnueabi-gcc --version
(4) Now trying to make u-boot config and compiling it with that able to generate config file but facing issue while compiling it,
(a) Sourced the metaToolChain
(b) Entered the U-bootsource file directory
(c) given sudo make distclean
(d) Exported the env variables CROSS_COMPILER and ARCH
(e) sudo make
the core board of one i'm using is MYC-Y6ULY2-356N256D-50-C
(f) sudo make
But cant able to compile. Can any one please help on this to solve the issue?
enter image description here
enter image description here
Do not use sudo here. It's a bad practice all around, but specifically in this case the environment from the user isn't passed to sudo, so CROSS_COMPILE is unset, so that's why you see that error.
So I've upgraded to a newer version of Linux kernel using Yocto. The new kernel version is for 4.1.15 and runs on an iMX6 chip. I've also included openssh-server, tools-sdk, and tools-debug for development recipes. The problem is that when I connect to build I get the following error:
loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))'
failed
Now if I type into the command prompt sh -c "LANG=en_US" I get the same error as above. If I type in sh -c "LANG=/usr/lib/locale/en_US" then I do not get an error. When I type locale everything is listed as POSIX and when I type locale -a I get:
C
POSIX
en_GB
en_US
The last two are stored under /usr/lib/locale. My version of gcc is 5.2 and my glibc is v2.22. I've looked all over the internet for other solutions but they are either for Ubuntu where the package manager comes in handy or it's some really specific fix like editing a file that I don't have in my Yocto build.
Edit:
The machine is for a SMARC-FiMX6 SoM and the instructions are here. I'm not sure what branch of Yocto is being pulled down.
After troubleshooting the problem is from the glibc library. A patch, #114739, is on the openembedded website which details what to do to fix this issue. Just patch the file, rebuild, and the issue is fixed. See here for details, the patch is at the bottom of the page.
I have a C project that uses a Makefile to compile so, basically I tell Xcode to rely on an external build tool (make).
Since I updated from Xcode 5 to Xcode 6, I am not able to Run that project (build still works). Each time I try to run the execute I get the following error message :
My Mac runs OS X 10.9.5, which is lower than project's minimum
deployment target. Change your project's minimum deployment target or
upgrade My Mac's to version of OS X.
I configured the MACOSX_DEPLOYMENT_TARGET to 10.9, and that did not change anything.
So, since I would like keep 10.9 for now, is there a way to tell Xcode that my project can run on 10.9 ?
Finally I just deleted and recreated the target and that solved the issue...
I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.
I am trying update my version of sqlite3 on mac os x 10.5.7 I downloaded the source code that is recommended for unix and unix like programs. I followed the compile and install directions in the readme file and everything seems to work fine. However, when i check the version number of sqlite3 it remains at 3.4.0 (the old version). Why is this? What am i doing wrong?
Most likely you installed it to a different location to the original — one that either appears later in the $PATH or not at all.