I am trying to cross-compile an application (tvheadend) for ARM (raspberry pi 2), using a x64 machine and this toolchain.
I am using the following command line to configure the compilation:
./configure --arch=arm-linux-gnueabihf --cc=arm-linux-gnueabihf-gcc --disable-avahi --release --cflags=-DOPENSSL_USE_DEPRECATED and then I just make.
The problem happens during the compilation of the source file src/utils.c: such file includes string.h, which is correctly selected from the toolchain include directory (let's say ARMTOOLCHAIN/usr/include), but then string2.h, which is inside ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf/bits, is selected from the system directory, instead of ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf/bits.
In file included from /usr/include/x86_64-linux-gnu/bits/byteswap.h:35:0,
from ARMTOOLCHAIN/usr/include/endian.h:61,
from /usr/include/x86_64-linux-gnu/bits/string2.h:51,
from ARMTOOLCHAIN/usr/include/string.h:637,
from src/utils.c:21:
src/utils.c: In function ‘sbuf_put_be16’:
src/utils.c:397:9: error: invalid 'asm': invalid operand for code 'w'
u16 = htons(u16);
^
The problem is that the compiler does not search inside ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf for the bits subdir. I tried to specify -IARMTOOLCHAIN/usr/include/arm-linux-gnueabihf as an option, and to create a symlink to bits inside ARMTOOLCHAIN/usr/include (so to avoid arm-linux-gnueabihf), but none of these works.
Try modifying cflags as follows in your configure invocation:
--cflags="-DOPENSSL_USE_DEPRECATED -nostdinc -nostdinc++"
Related
So I am making a desktop application using C and the Win32 API. I am also using CMake/Make in conjunction with MinGW. Everything went smoothly until I wanted to add an .rc file to the executable. From my understanding you write an .rc file which is then compiled to a .res file, then presumably you are supposed to embed it in the executable. Here's the problem however, when I attempt to compile the .rc file with the GNU utility windres it fails to compile. I always get the following error messages:
C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\windres.exe: can't open file `page:': Invalid argument
C:\Code\C\test\resources.rc:4: fatal error: when writing output to : No such file or directory
4 | IDI_TEST_ICON ICON "test.ico"
|
compilation terminated.
C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\windres.exe: preprocessing failed.
This occurs with every .rc file I've tried, for completeness however, here is the current test file I am trying to compile:
#include <windows.h>
#include "resource.h"
IDI_TEST_ICON ICON "test.ico"
And the resource.h file:
#define IDI_TEST_ICON 101
So the final question is the following: Why doesn't windres compile the .rc file successfully? And what can I do about in the context of using MinGW?
Edit 1:
Worth noting is that I also converted the .rc file to ANSI format since windres is notorious for yielding peculiar errors when formatted in UTF-8. Yet, the same errors occur.
windres actually generates an object file (in COFF format)
So you should run the command like this:
windres resource.rc -o resource.o
When I check the format of the generated file like this:
file resource.o
I get the following result:
resource.o: Intel amd64 COFF object file, no line number info, not stripped, 1 section, symbol offset=0x3c4c, 1 symbols
So you just need to include the generated .o file in the link step to include the resource.
For example when you run the following command you will get an .exe that won't run, but it will show the icon in Explorer:
gcc -shared -o resource.exe resource.o
After a lot of digging in old forum threads I managed to find a "solution" that works. However I still find it peculiar that this solves the problem. I followed Brecht Sanders advise and downloaded a standalone build from winlibs.com. Even this didn't solve the problem which led me to investigate possible RC_COMPILER_FLAGS which ultimately led me to the --use-temp-file flag.
This flag acts as an alternate approach to compile .rc files since it excludes the use of popen (or the equivalent of it in Windows). According to the documentation this flag should be used if the implemenation of popen is buggy on the host. What is interesting here is that the documentation states that this is known to happen on certain non-english versions of Windows. In my case I am using the Swedish language version of Windows which might explain why this is occuring.
Thus the final solution turns out to be:
windres -i resource.rc -o resource.o --use-temp-file
Which ultimately yields an object file which can then be included in the add_executable call in CMake.
I have a stm32f103 project that is initialized using stm32cubemx and I'm using neovim for editing and arm-none-eabi-gcc for compilation of code (whit auto-generated makefile).
I also have installed clangd LSP and also bear to generate compile_commands.json file. Everyting works fine except that there's two errors:
stdio.h file not found
Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)
I looked at core_cm3.h file and __FPU_USED is disabled, which is exactly what clang says.
/** __FPU_USED indicates whether an FPU is used or not.
This core does not support an FPU at all
*/
#define __FPU_USED 0U
But I couldn't find any line in my makefile flags that enables the FPU for compilation.
# fpu
# NONE for Cortex-M0/M0+/M3
# float-abi
# mcu
MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI)
I also commented out $(FPU) and $(FLOAT-ABI), but the error still exists.
Although I can compile the project without any problems (because gcc has no complaints), but these errors are kind of on my nerve.
Is there a way to fix these errors? Or is there any gcc-based LSPs to use instead of clangd?
There's also ccls on neovim's LSP list but I was unable to install it.
s there a way to fix these errors?
https://clangd.llvm.org/config#files You can:
create clangd configuration file
specify -sysroot command to specify the location of your buildchain (/usr/arm-none-eabi/ on my system)
and other needed options (-isysroot -nostdlib etc.) if you use them.
I would advise anyway to move CMake and generate compile_command.json anyway.
is there any gcc-based LSPs to use instead of clangd?
I am not aware of any.
I am trying to run a c code on my Windows laptop using the 64-bit MinGW compiler. There are a few lines in the beginning of the code that direct to other files such as:
#include <openssl/e_os2.h>
When compiling the code the following error shows up:
C:\MinGW\bin\openssl\apps>gcc s_server.c
s_server.c:21:27: fatal error: openssl/e_os2.h: No such file or directory
#include <openssl/e_os2.h>
^
compilation terminated.
I made sure the files were in the correct locations, however the error still occurs. I am thinking the error occurs because I am running a 32-bit binary on a 64-bit system. Are there any ways to work around this issue given that I don't have a Linux system?
C:\MinGW\bin\openssl\apps>gcc s_server.c
s_server.c:21:27: fatal error: openssl/e_os2.h: No such file or directory
#include <openssl/e_os2.h>
^
compilation terminated.
I believe you need a -I argument during compile. The headers are not located in the apps/ directory. Instead, they are located at ../include/ (relative to apps/).
So maybe a compile command like:
# from apps/ directory
gcc -I ../include/ s_server.c
You will probably have additional problems because you need to link against libssl and libcrypto. Be aware you will still have work to do.
Here is what it looks like on Linux:
openssl$ find . -name e_os2.h
./include/openssl/e_os2.h
openssl$ cd apps
apps$ ls ../include/openssl/e_os2.h
../include/openssl/e_os2.h
Since the relative path is ../include/openssl/e_os2.h and the source file #include "openssl/e_os2.h", you only need to include ../include using -I.
I am running a 32-bit binary on a 64-bit system...
You need to build OpenSSL as 32-bit. Run ./Configure LIST to get a list of MinGW targets. Then, configure with the appropriate triplet.
You may need to add -m32 to the command line for your program.
I want to run serial commands from a Bealgebone to a 4Dsystems display. Therefore I copied the c library found here into a directory and created a test program main.c:
#include "Picaso_const4D.h"
#include "Picaso_Serial_4DLibrary.h"
int main(int argc,char *argv[])
{
OpenComm("/dev/ttyUSB0", B115200); // Matches with the display "Comms" rate
gfx_BGcolour(0xFFFF);
gfx_Cls();
gfx_CircleFilled(120,160,80,BLUE);
while (1) {}
}
Now when I do gcc -o main main.c its says
main.c:2:37: fatal error: Picaso_Serial_4DLibrary.h: No such file or
directory
So I try linking it:
gcc main.c -L. -lPICASO_SERIAL_4DLIBRARY
which gives me the same error. Then I tried to create a static library:
gcc -Wall -g -c -o PICASO_SERIAL_4DLIBRARY PICASO_SERIAL_4DLIBRARY.C
which gives me this:
PICASO_SERIAL_4DLIBRARY.C:1:21: fatal error: windows.h: No such file
or directory compilation terminated.
What am I doing wrong? the git page clearly says this library is created for people who do not run windows.
Thanks in advance!
You're not getting a linker error; you're getting a preprocessor error. Specifically, your preprocessor can't find Picaso_Serial_4DLibrary.h. Make sure that it's in your include path; you can add directories to your include path using the -I argument to gcc.
You've had two problems. First was the picaso_whatever.h file that couldn't be found. You fixed that with the -I you added. But, now, the picaso.h wants windows.h
What are you building on? WinX or BSD/Linux?
If you're compiling on WinX, you need to install the "platform sdk" for visual studio.
If you're using mingw or cygwin, you need to do something else.
If on WinX, cd to the C: directory. Do find . -type f -name windows.h and add a -I for the containing directory.
If under Linux, repeat the find at the source tree top level. Otherwise, there is probably some compatibility cross-build library that you need to install.
Or, you'll have to find WinX that has it as Picaso clearly includes it. You could try commenting out one or more of the #include's for it and see if things are better or worse.
If you can't find a real one, create an empty windows.h and add -I to it and see how bad [or good] things are.
You may need the mingw cross-compiler. See https://forums.wxwidgets.org/viewtopic.php?t=7729
UPDATE:
Okay ... Wow ... You are on the right track and close, but this is, IMO, ugly WinX stuff.
The primary need of Picaso is getting a serial comm port connection, so the need from within windows.h is [thankfully] minimal. It needs basic boilerplate definitions for WORD, DWORD, etc.
mingw or cygwin will provide their own copies of windows.h. These are "clean room" reimplementations, so no copyright issues.
mingw is a collection of compile/build tools that let you use gcc/ld/make build utilities.
cygwin is more like: I'd like a complete shell-like environment similar to BSD/Linux. You get bash, ls, gcc, tar, and just about any GNU utility you want.
Caveat: I use cygwin, but have never used mingw. The mingw version of windows.h [and a suite of .h files that it includes underneath], being open source, can be reused by other projects (e.g. cygwin, wine).
Under Linux, wine (windows emulator) is a program/suite that attempts to allow you to run WinX binaries under Linux (e.g. wine mywinpgm).
I git cloned the Picaso library and after some fiddling, I was able to get it to compile after pointing it to wine's version of windows.h
Picaso's OpenComm is doing CreateFile [a win32 API call]. So, you'll probably need cygwin. You're opening /dev/ttyUSB0. /dev/* implies cygwin. But, /dev/ttyUSB0 is a Linux-like name. You may need some WinX-style name like "COM:" or whatever. Under the cygwin terminal [which gives you a bash prompt], do ls /dev and see what's available.
You can get cygwin from: http://cygwin.com/ If you have a 64 bit system, be sure to use the 64 bit version of the installer: setup-x86_64.exe It's semi-graphical and will want two directories, one for the "root" FS and one to store packages. On my system, I use C:\cygwin64 and C:\cygwin64_packages--YMMV.
Note that the installer won't install gcc by default. You can [graphically] select which packages to install. You may also need some "devel" packages. They have libraries and .h files that a non-developer wouldn't need. As, docs mention, you can rerun the installer as often as you need. You can add packages that you forgot to specify or even remove ones that you installed that you don't need anymore.
Remember that you'll need to adjust makefile -I and/or -L option appropriately. Also, when building the picaso library, gcc generated a ton of warnings about overflow of a "large integer". The code was doing:
#define control_code -279
unsigned char buf[2];
buf[0] = control_code >> 8;
buf[1] = control_code;
The code is okay, and the warning is correct [because the code is sloppy]. If the code had done:
#define control_code -279
unsigned char buf[2];
buf[0] = (unsigned) control_code >> 8;
buf[1] = (unsigned) control_code;
it probably would have been silent. Use -Wno-overflow in your Makefile to get rid of the warnings rather that edit 50 or so lines
I would like to be able to use talloc in an embedded project I am working on, but have been unable to determine how I go about incorporating it into my development environment. The environment in question is a vendor-supplied Windows IDE that uses ARM GCC 4.4.1, and I am using it to target an ARM7 device.
I have gotten to the stage where the compiler is complaining about conflicting types:
In file included from .\talloc-2.0.8\talloc.c:33:
.\talloc-2.0.8\lib\replace/replace.h:626: error: conflicting types for 'ptrdiff_t'
c:\program files (x86)\cypress\psoc creator\2.2\psoc creator\import\gnu_cs\arm\4.4.1\bin\../lib/gcc/arm-none-eabi/4.4.1/include/stddef.h:149: note: previous declaration of 'ptrdiff_t' was here
.\talloc-2.0.8\lib\replace/replace.h:848: error: conflicting types for 'useconds_t'
c:\program files (x86)\cypress\psoc creator\2.2\psoc creator\import\gnu_cs\arm\4.4.1\bin\../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/sys/types.h:253: note: previous declaration of 'useconds_t' was here
.\talloc-2.0.8\talloc.c:123: error: expected specifier-qualifier-list before 'uint8_t'
I noticed that replace.h tries to include a file called config.h that does not exist in the talloc source tree - a problem I got around by creating a blank file by that name. Is the idea to use config.h to inform talloc what functions are already defined by the system? Is this just a matter of using the #define directive to prevent replace.h from trying to replace existing types?
Given that this is the first time I have attempted to use code that I did not write myself in a project, I am somewhat confused as to how to go about reconciling these conflicts.
config.h should be generated automatically. For tmalloc, it's done by waf (python-based build system).
$ python ./buildtools/bin/waf configure
Checking for program gcc or cc : /usr/lib/ccache/gcc
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/bin/ar
Checking for program ranlib : /usr/bin/ranlib
Checking for gcc : ok
Checking for program git : /usr/bin/git
Check for -MD : yes
....
$ python ./buildtools/bin/waf build
.....