I'm trying to get my work laptop build environment working on my home PC.
(Working from home for a few months, you just guessed why).
Using GNU MCU Eclipse. I've installed the same version on my home machine as I installed in late 2018 on my work machine. The project I'm working on uses an external makefile to build for an ARM (SAM4L) target. Clearly there was a step that I did way back then that I've forgotten this time around.
I have the same build tools, toolchain, and Eclipse version installed on both machines (albeit in slightly different locations). On both machines, "where make.exe" and "where sh.exe" at the windows command prompt finds the executables in the Windows Build tools.
My work machine builds successfully, but my home machine gets stuck with $(shell ... ) calls within the makefile.
The first line that gives me trouble:
DATE := $(shell date +%Y%m%d)
The console output is:
process_begin: CreateProcess(NULL, date +%Y%m%d, ...) failed.
make: Makefile:26: pipe: No error
Similar errors occur with subseqent calls to $(shell uname) e.g.:
os_type ?= $(strip $(shell uname))
ifeq ($(os_type),windows32)
os := Windows
gives the error:
process_begin: CreateProcess(NULL, uname, ...) failed.
make[1]: ../../../thirdparty/asf/sam/utils/make/Makefile.sam.in:105: pipe: No error
The only other difference is that my work machine has another installation of MinGW/msys providing a separate sh and make, but these aren't in my Windows path. Nevertheless it's possible these are being used by Eclipse, but I don't see how. I've spent most of the day trawling through the configuration on both machines (Project->properties), and I can't see a difference.
[Edit] - I Just confirmed that both installs call the Make that is in the Windows Build tools, and both are the same version. (and not the same as the other tools in the build-tools that are from a busybox build)
~/eclipse/GNU MCU Eclipse/Build Tools/2.11-20180428-1604/bin $ ./make --version
GNU Make 4.2.1
Built for x86_64-w64-mingw32
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
Any guidance??
OK, Easy when you see it.
I didn't have a date or uname command in my Build tools. Because the build tools are based on BusyBox i just needed to copy busybox.exe to date.exe and to uname.exe to provide the required functions. (also needed test command). Clearly I worked this out 18 months ago. I've written a howto doc for next time :-) .
C:\...\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin>sh -c "cp busybox.exe date.exe"
C:\...\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin>sh -c "cp busybox.exe uname.exe"
C:\...\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin>sh -c "cp busybox.exe test.exe"
Hopefully this helps someone in the future.
Related
I was trying to activate the option -Wmismatched-tags on gcc (detect inconsistent class/struct declaration, which might happens when using forward declaration), but on Ubuntu I get
c++: error: unrecognized command line option '-Wmismatched-tags'
My gcc version:
# gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
Looking here it seems like it was integrated in gcc 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Am I doing something wrong, or is the option actually not available anymore?
I am aware of Can GCC produce struct/class name mismatches like VS?, however the answer is 10 years old and I was hoping things had improved in the meantime.
Background: I need this in a project where we also build with clang, and where these inconsistencies are treated as error.
Looking here it seems like it was integrated in gcc 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Actually, it doesn't. It was reported in 2014 but as OP explained in
#5th post:
I can't speak for MS, but the original warning I posted was produced
by clang. It does seem to worry about mismatched tags.
In gcc -Wmismatched-tags was introduced only in December 2019 and
became a part of GCC 10 release:
$ git describe e8f1ade269a39ea86a76a2440818e1512ed480ee
basepoints/gcc-10-5517-ge8f1ade269a
Luckily, these days we have docker and official GCC releases are
officially distributed as docker images:
$ docker search gcc
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
gcc The GNU Compiler Collection is a compiling s… 587 [OK]
(...)
so you can just do:
docker run --rm -it gcc
and either mount your source directory into the docker container or
use TRAMP integration for docker
containers or any other
preferred tool to put your code into the container and use the newest gcc inside it:
root#53d309d5d619:/# g++ --version
g++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root#53d309d5d619:/# g++ hello.cpp -o hello -Wmismatched-tags
I've tried to configure GCC 9.3.0 to produce executable files for DOS. However, for a simple "Hello world!" program in C, it outputs:
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0xd6): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x10b): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x131): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x141): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x3d4): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(getenv.o):getenv.c:(.text+0x4): more undefined references to `_environ' follow
collect2: error: ld returned 1 exit status
djgpp-gcc -v outputs:
Using built-in specs.
COLLECT_GCC=djgpp-gcc
COLLECT_LTO_WRAPPER=/home/teo.samarzija/djgpp-9.3.0/libexec/gcc/djgpp/9.3.0/lto-wrapper
Target: djgpp
Configured with: ../gcc-9.3.0/configure --target=djgpp --prefix=/home/teo.samarzija/djgpp-9.3.0 --enable-languages=c,c++,objc,ada,fortran,go
Thread model: single
gcc version 9.3.0 (GCC)
I've also compiled the newest version of the GNU linker and GNU Assembler, they output as their versions:
GNU ld (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
and
GNU assembler (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
Any idea what I am doing wrong? Have GCC or GAS or GLD stopped supporting DOS some time in the past? I suppose not, because they compile for DOS as a target without warning about that.
I only stumbled on this question because of a more recent Stackoverflow question you asked about some code that didn't run properly in 32-bit Windows 10 inside an NTVDM virtual DOS session.
The problem is that you have not properly built a DJGPP cross compiler and all the needed components. You do not show us what commands you use for the build process and which versions of the dependencies were used and where they came from.
1st thing you need to do is build a DJGPP cross compiler. There are some people who maintain scripts to do just that. One build environment/script in particular I have used successfully is from the user Andrew Wu on Github. It is very simple to use. It appears you are using a Unix type environment based on the output you have shown us. Since you managed to build DJGPP (albeit one that doesn't work) I will assume you have all the necessary build tools installed already. First retrieve the scripts with:
git clone https://github.com/andrewwutw/build-djgpp
Change into the project directory with:
cd build-djgpp
Review the README.md file! It tells you what versions are supported by the script, build requirements for the type of OS you are on etc. At present they support versions all the way to 10.1.0. If you have everything needed choose a version to build (I'll use 9.3.0 since it is the version you are using) and then start the build. You will have to build as root or use sudo as it installs to directory /usr/local/djgpp
./build-djgpp.sh 9.3.0
It will take a while but when finished it should be installed and ready to use. The naming convention is a bit different than prefixing the commands with djgpp-. This script builds things with a more complete target prefix i586-pc-msdosdjgpp-
To add it to your path and set up other environment variables use:
. /usr/local/djgpp/setenv
If you wish it to be done each time you are logged in add that line to your shell login script. For BASH that is in the file ~/.bashrc
Create a file called hello.c containing:
#include<stdio.h>
int main()
{
printf("Hello, world!\n");
}
Compile it to a file called hello.exe:
i586-pc-msdosdjgpp-gcc -O3 -Wall -Wextra hello.c -o hello.exe
Assuming you have a DPMI host installed (like CWSDPMI.EXE), hello.exe should run in MS-DOS, FreeDOS, DOSBox, a Windows NTVDM session etc. When run it should display:
Hello, world!
If you don't wish to build from scratch, Andrew Wu has a number of pre-built packages for a number of the latest DJGPP releases. Platforms they are available for are MacOS, Linux 32, Linux 64, MinGW, and a MinGW standalone version that doesn't need the MinGW environment to run.
I wanted to upgrade to binutils 2.26 , so i followed the steps here : How to convert default binutils into binutils-2.26? to solve the same "unrecognized relocation" error.
Now my default linker is 2.26
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
So how to force "make" to use the default linker ?
It depends upon your Makefile (which you could debug with remake -x). Notice that make has a lot of builtin rules. Use make -p to also print them. Notice the rules mentioning LINK.c or LINK.cc etc, and notice that LD is not much used. Notice also that ld is almost never used directly (most of the time, some other program like gcc or g++ runs it).
And it is also a matter of the PATH variable. So try setting it so that your new ld comes before the old one.
Generally, you link with the gcc or g++ program (so it is GCC which matters, not make; read about Invoking GCC and its -fuse-ld=), and that gcc or g++ will run the linker (you might, but I don't recommend to, change its spec file which governs what actual programs are run by gcc or g++ which are only drivers to other programs such as cc1, as, ld, collect2 etc...). To understand what programs gcc or g++ is running, pass it the -v flag.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
On my Debian system /usr/bin/x86_64-linux-gnu-ld (it is generally started by gcc, not directly by make) is a symlink. You might (but I don't recommend that) just change that symlink.
BTW, you are using an ancient Ubuntu 14. You'll better upgrade your entire distribution (e.g. to Ubuntu 18.04.1 LTS at end of 2018), because there is not only ld but many other programs which are really old on your system.
Upgrading your distribution will take less time than upgrading, compiling, installing and configuring each individual tool.
My final goal is to install Nagios on my Synology DiskStation DS1813+ with DSM 6.0.1-7393 Update 1. But I can't even begin compiling the package...
When I try to use gcc on my Synology DiskStation I always get the following error message:
$ gcc hello.c -o hello.o
/lib/libc.so.6: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Here's my shell environment. I have tried it with different LD_LIBRARY_PATH settings, but even omitting it doesn't make a difference.
$ env
TERM=xterm-256color
SHELL=/bin/sh
SSH_CLIENT=192.168.2.110 51079 22
OLDPWD=/var/services/homes/egi
SSH_TTY=/dev/pts/7
LC_ALL=en_US.utf8
USER=egi
LD_LIBRARY_PATH=/opt/lib:
PAGER=more
MAIL=/var/mail/egi
PATH=/opt/sbin:/opt/bin:/sbin:/bin:/usr/sbin:/usr/bin
PWD=/var/services/homes/egi/exer
LANG=en_US.utf8
PS1=[\u#\h \W]$
SHLVL=1
HOME=/var/services/homes/egi
TERMINFO=/usr/share/terminfo
LOGNAME=shunyam
SSH_CONNECTION=xxx.xxx.xxx.xxx 51079 yyy.yyy.yyy.yyy 22
PGDATA=/var/services/pgsql
CC=gcc
_=/opt/bin/env
The compiler has been installed with ipkg and its specs look like this:
$ gcc --verbose
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../gcc-4.2.1/configure --build=i386-pc-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu --prefix=/opt --disable-nls --disable-static --with-as=/home/slug/optware/syno-i686/toolchain/gcc-4.2.1-glibc-2.3.6/i686-linux-gnu/bin/i686-linux-gnu-as --with-ld=/home/slug/optware/syno-i686/toolchain/gcc-4.2.1-glibc-2.3.6/i686-linux-gnu/bin/i686-linux-gnu-ld --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.2.1
The library that causes the problem returns this information:
$ /lib/libc.so.6
GNU C Library (crosstool-NG 1.20.0) stable release version 2.20-2014.11, by Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.9.3 20150311 (prerelease).
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
There is also a linker script at /opt/lib/libc.so:
$ cat /opt/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /opt/lib/libc_nonshared.a )
The library can't actually be broken, otherwise nothing would work at all.
Alongside with gcc all other required packages have also been installed with ipkg.
Weirdly enough I seem to be the only person with that issue as I have found no relevant posts on Google. Synology's support told me that they are not supporting installing command command line packages.
When I first installed gcc on this Diskstation about two years ago, everything was working fine. I have noticed this problem a few months ago (probably after a DSM update).
Has anyone also come across this issue or has a clue on how to get it working again? Thanks!
I had this exact same problem. GCC use to work and now with DSM 6.1 it broke. I think it's after they switched to 64-bit with DSM 6.0 I believe. Your question actually gave me the answer so I wanted to share it here. I changed /lib/libc.so.6 to /lib32/libc.so.6 in the file /opt/lib/libc.so.
$ cat /opt/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib32/libc.so.6 /opt/lib/libc_nonshared.a )
After making the change above optware GCC compiled my test file without any environment variables set just like you would expect on a normal Linux system.
It looks like I've been using some other g++:
/volume1/homes/user/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-g++
It came from this file: gcc473_glibc217_x86_64_cedarview-GPL.tgz.
Other people have problems too with DSM 6: https://forum.synology.com/enu/viewtopic.php?t=116803
It's suggested to use the Debian Chroot Package from SynoCommunity instead.
You just have to change lib by lib32 like this :
cat /opt/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib32/libc.so.6 /opt/lib/libc_nonshared.a )
I am trying to install a simulation software on windows using MingW32 and cmake.
The problem I have is after I use :
cmake .. -DCMAKE_INSTALL_PREFIX="/cygdrive/c/Gromacs467" -DGMX_X11=OFF -DGMX_GPU=OFF -DGMX_MPI=OFF -DGMX_PREFER_STATIC_LIBS=ON -DGMX_CPU_ACCELERATION=SSE2 -DBUILD_SHARED_LIBS=NO -DGMX_BUILD_OWN_FFTW=ON -VMDDIR="C:\Program Files (x86)\University of Illinois\VMD" -G "MinGW Makefiles"
From a Microsoft visual studio, (Otherwise I ran in other issue).
I then start a MinGW console and go to the repertory where my Makefile was created, and enter the command make, and here is what I get :
c:\Temp\gromacs-4.6.7\cmake_build>make
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.
And naturally the make command does not actually execute. Why do I get the windows version ? No idea....
Interestingly enough, the name of the MniGW32 console change to add make at the end if I enter it more than once, and keeps on doing it later.
make --version gives the normal output, so I do not understand where the problem comes from.
c:\Temp\gromacs-4.6.7\cmake_build>make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
If you use cmake ... -G "MinGW Makefiles" you will need to call mingw32-make.
And just a hint: I assume you were previously building with Cygwin and for MinGW32 it should be -DCMAKE_INSTALL_PREFIX="/c/Gromacs467" instead of -DCMAKE_INSTALL_PREFIX="/cygdrive/c/Gromacs467"
References
CMake Error at CMakeLists.txt:30 (project): No CMAKE_C_COMPILER could be found
How to compile makefile using MinGW?
Instead of calling make directly, you can let CMake invoke the build for you with the following syntax:
cmake --build <build-dir> --target <target-name> --config <build-type>
The --target and --config arguments are optional and <build-dir> must point to your CMake project's build directory. The main advantage to invoking your build this way is that CMake has already determined the build tool and knows where to find it and how to invoke it correctly. Invoking your build via CMake in this manner is likely to be more robust.
Basic CMake documentation for the --build option available here and some related material can be found in this blog post, particularly the section "Abstracting away the build tool" (disclosure: I wrote the blog article).