win avr gcc - nonconstant expression for length - avr-gcc

Have been tring to build this bootloader for a few days now.
https://github.com/ahtn/kp_boot_32u4
Windows pc, under mingG, WINavr and Python installed.
Im stuck at creating the elf file...
Linking: build/default-atmega32u4/kp_boot_32u4-1024-default-atmega32u4.elf
avr-gcc -mmcu=atmega32u4 -I. -Isrc -Wno-error=unused-function -DBOOT_SIZE=BOOT_SIZE_10 -DCHIP_ID=CHIP_ID_ATmega32U4 -g -DUSB_VID=0x1209 -DUSB_PID=0xBB05 -DF_CPU=16000000UL -DF_USB=UL -DBOARD=BOARD_default -DARCH=ARCH_AVR8 -D ____ -Os -fno-strict-aliasing -Wstrict-prototypes -Wa,-adhlns=build/default-atmega32u4/kp_boot_32u4-1024-default-atmega32u4.elf -std=gnu99 -Wall -Werror -MMD -MP -MF build/default-atmega32u4/obj/.dep/kp_boot_32u4-1024-default-atmega32u4.elf.d build/default-atmega32u4/obj/usb/device_descriptors.o build/default-atmega32u4/obj/main.o build/default-atmega32u4/obj/usb.o build/default-atmega32u4/obj/spm.o --output build/default-atmega32u4/kp_boot_32u4-1024-default-atmega32u4.elf -T ./ld_scripts/avr5.xn -Wl,--section-start=.text=0x7c00 -Wl,--section-start=.boot_extra=0x7ff0 -Wl,--undefined=.boot_extra -Wl,-Map=build/default-atmega32u4/kp_boot_32u4-1024-default-atmega32u4.map,--cref -Wl,--gc-sections -flto
./ld_scripts/avr5.xn:18: nonconstant expression for length
make: *** [avr-makefile/avr.mk:253: build/default-atmega32u4/kp_boot_32u4-1024-default-atmega32u4.elf] Error 1
I uploaded a palou elf to the build folder and the make process completes ok. After a bit of research i have seen many others get the error, but wondering if there is another version of avr-gcc i could use?? to be honest i am quite new to all this so may have bitten off more than i can chew (lock down mind activity)
......
**__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xffa0;**
.....
and causes error in memory section...
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = __TEXT_REGION_LENGTH__
data (rw!x) : ORIGIN = 0x800060, LENGTH = __DATA_REGION_LENGTH__
Thanks
M

These ** in avr5.xn is no valid linker script syntax. Fix that.

same problem here, but my mistake was putting in the wrong vales for boot section, because I could not use python.
SPM_CALL_POS = 0x8000
BOOT_SECTION_START = 0x7c00
made it work.

Related

Unable to cross compile Linux openGL program with mingw32. Config.log error: undefined reference to `_glEnable'

I am attempting to cross-compile an OpenGL program using Mingw32 but have run into a road block. After invoking mingw32-configure; the compilation is interrupted by
configure: error: lacking proper OpenGL support
I checked the config.log file and found the following entries:
configure:21709: checking GL/gl.h usability
configure:21726: ccache i686-pc-mingw32-g++ -c -O2 -g -pipe -Wall -,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields conftest.cpp >&5
configure:21732: $? = 0
configure:21746: result: yes
configure:21750: checking GL/gl.h presence
configure:21765: ccache i686-pc-mingw32-g++ -E conftest.cpp
configure:21771: $? = 0
configure:21785: result: yes
configure:21813: checking for GL/gl.h
configure:21820: result: yes
configure:21834: checking for glEnable in -lGL
configure:21869: ccache i686-pc-mingw32-g++ -o conftest.exe -O2 -g -pipe - Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms- bitfields conftest.cpp -lGL >&5
/tmp/ccjGmlvX.o: In function 'main':../rpmbuild/SOURCES/poker3d-1.1.36/conftest.cpp:34: undefined reference to `_glEnable'
collect2: ld returned 1 exit status
configure:21875: $? = 1
configure: failed program was:
| /* confdefs.h. */
I have added the llvm software rasterizer to my system after a suggestion on this website from another thread related to this problem and have also implemented a suggestion from the Mingw site to copy libopengl32.a to libGL.a. So far nothing has changed the errors that I get after each compile attempt.
Give me some advice on how to resolve this.
autotools/autoconf is abysmally bad for crosscompilation. The way the generated configure script works is, that for many tests it attempts to compile and execute short test snippet programs. Of course the whole "execute" part will miserably fail for cross compiled libraries, due to either lack in instruction set support (compiling for a different CPU) or targeting an entirely different OS.
At least in Linux one can work around this using the "misc binfmt" kernel support, which allows to register interpreters for non-native executable formats. For Windows targets you'd use Wine as an interpreter and for foreign CPUs you can use QEmu which not only can emulate whole machines, but focus CPU emulation on a single process/binary. And of course you can combine it.
However this is just a crutch and honestly you should probably ditch autoconf/autotools entirely and just write Makefiles. Today the *nix-ish systems are so similar that none of these compiled tests make a lot of sense at all.

cc1plus: error: unrecognized command line option "-fsysroot=<path>" with g++

Am trying to compile a large C++ project in a simulated 32bits environment (cel5.03-i386-2.3) on a 64bits machine. (The compiling worked well on 32bits machine before)
During this compiling some files fail as below. The weird thing is that the argument passed to g++ command is "--sysroot=" while in error message it becomes "-fsysroot=".
Why could this happen?
/usr/bin/g++ -MMD -MF /proj/src/.debug/lib/osiris/core/utils/WWNConverter.d -I/proj/src/lib/osiris -DDEBUG_LOG -DDEBUG -D_REENTRANT -DAPE_MODE -DSWAT_MODE -g -Werror -Wall -Wno-write-strings -fPIC -m32 --sysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot -rdynamic -I/proj/src -I/proj/src/.debug/include/private -I/proj/src/.debug/include/public -I/proj/src/lib/framework -I/proj/src/lib/osiris -I/proj/src/lib/prt -I/proj/src/lib/callhome -I/proj/src/lib/snmp -I/proj/src/.debug/external/pcre/include -I/proj/src/external/sqlite/include -I/proj/src/external/openssl/openssl-fips-1.2.3/include -I/proj/src/support/storage-driver/include -I/proj/src/external/json/include -DTARGET_OBJECT=libosiris.so -I/proj/src/.debug/external/pcre/include -I/proj/src/.debug/external/libcurl/include -o /proj/src/.debug/lib/osiris/core/utils/WWNConverter.o -c /proj/src/lib/osiris/core/utils/WWNConverter.cc
make[1]: *** [/proj/src/.debug/lib/osiris/core/utils/WWNConverter.o] Error 1
cc1plus: error: unrecognized command line option "-fsysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot"
The 32-bit compiler (GCC 3.4.6) is too old to support the --sysroot option, which was added to trunk with commit 102367, and did not make it into a release branch until GCC 4.1.0.
2005-07-25 Mark Mitchell <mark#codesourcery.com>
* gcc.c (option_map): Add --sysroot.
(process_command): Handle --sysroot.
(display_help): Document it.
* doc/cppopts.tex (-isysroot): Document.
* doc/invoke.texi (--sysroot): Document.
* doc/install.texi (--with-build-sysroot): Document.
* Makefile.in (inhibit_libc): New variable.
(INHIBIT_LIBC_CFLAGS): Likewise.
(LIBGCC2_CFLAGS): Include
$(INHIBIT_LIBC_CFLAGS).
(CRTSTUFF_CFLAGS): Include $(INHIBIT_LIBC_CFLAGS).
($(T)crtbegin.o): Do not use #inhibit_libc#.
($(T)crtend.o): Likewise.
($(T)crtbeginS.o): Do not use #inhibit_libc#.
($(T)crtendS.o): Likewise.
($(T)crtbeginT.o): Do not use #inhibit_libc#.
($(T)crtendT.o): Likewise.
(stmp-fixinc): Do not complain about missing headers if
inhibit_libc.
* configure.ac (inhibit_libc): Set it to true/false.
(--with-build-sysroot): New option. Use it to set
SYSTEM_HEADER_DIR.
* configure: Regenerated.

Compiling Yap on windows 8

I am trying to compile yap on my PC since it seems YAP default installers don't come with the Depth limit flag enabled. I need this to work on an ILP project on Aleph.
The thing is, that I am forced to use a PC with windows 8 without enough memory for a Linux Virtual machine.
I got cygwin to attempt to install it, but once I get to the 'make' stage of the installation ( http://www.dcc.fc.up.pt/~vsc/Yap/Yap4.3/yap.html#SEC2 ) I get this following error
$ make
Makefile:714: warning: overriding recipe for target 'yap.dll'
Makefile:545: warning: ignoring old recipe for target 'yap.dll'
gcc -mno-cygwin -c -O3 -fomit-frame-pointer -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -DCUT_C=1 -DCOROUTINING=1 -DRATIONAL_TREES=1 -DDEPTH_LIMIT=1 -DHAVE_CONFIG_H -D_YAP_NOT_INSTALLED_=1 -I. -I../H -I../OPTYap -I../BEAM -I../MYDDAS ../C/agc.c -o agc.o
gcc: error: unrecognized command line option ‘-mno-cygwin’
Makefile:488: recipe for target 'agc.o' failed
make: *** [agc.o] Error 1
I assume it's due to the latest YAP being outdated right now, does anyone know what to do to work around this?
It seems long time has passed since the question is asked. But I would like to answer since the problem is still relevant (I had this problem lately).
Asking at YAP-users mailing list, I was able to solve this problem. You can check the details here.
In short, using MSYS2 or MinGW-w64 (with toolchain installed) and making few changes in the source code makes it possible.
Changes are:
Adding #include <stdio.h> in blob.c file.
Refactoring H with HEAD (or some other name) in whole project. Which was defined in Regs.h, line 590.

Compile cyanoboot: No rule to make target

I'm trying to compile the cyanoboot project found here. I have no experience with c++ compiling but I've followed the read-me and seem to have hit a brick wall. I've extracted the downloaded source files and navigated to them in cygwin, I then run the command:
make clean
which looks like it is successful. After that I run
make omap4430sdp_config
which also seems to work but doesn't create any files(not sure if it should?). Then, when I run the final make command I get the error:
makefile:98: /cygdrive/c/cyanoboot/config.mk: No such file or directory
make: *** No rule to make target `/cygdrive/c/cyanoboot/config.mk'. Stop.
This config.mk file definitely does exist, you can see it at the git hub link above and I haven't changed any files. I've been struggling with this for a few hours now and I just cant figure it out. Any help is much appreciated. Thanks.
This package is new to me. But, there are multiple processors supported, for example i386/m68k/arm. Therefore you will likely need environment set up properly, for example ARCH=arm and CROSS_COMPILE=arm-linux-gnueabi-
To check if make config worked, you can look for modified or new files. Doing it myself, here you see a link has been added:
~/cmn/CMNookTablet-acclaim_cyanoboot-02c6247$ find . | xargs ls -alt | more
lrwxrwxrwx 1 joe joe 7 Oct 24 10:03 ./include/asm -> asm-arm
...
I tried your build with my toolchain, got this FWIW
...
arm-linux-gnueabi-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -D_KERNEL_ -DTEXT_BASE=0x80e80000 -I/home/joe/cmn/CMNookTablet-acclaim_cyanoboot-02c6247/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6/include -pipe -DCONFIG_ARM -D_ARM_ -march=armv7-a -mabi=apcs-gnu -Wall -Wstrict-prototypes -c -o hal_services.o hal_services.c
{standard input}: Assembler messages:
{standard input}:276: Error: selected processor does not support Thumb mode `smc #0'
make[1]: * [hal_services.o] Error 1
make[1]: Leaving directory `/home/joe/cmn/CMNookTablet-acclaim_cyanoboot-02c6247/board/omap4430sdp'
make: * [board/omap4430sdp/libomap4430sdp.a] Error 2

error: syntax error before '#' token (why?)

I include the amalgamation sqlite code in my iPhone project, and remove the reference to the iPhone sqlite framework.
My main target compile fine.
I have a second target for unit testing with the google framework. When compile I get:
error: syntax error before '#' token
I don't understand why. I have set both projects to sdk 2.
UPDATE: I include the link to the sqlite code & google. I must add that the target compile just fine for months before I added the sqlite code. I don't post sample code because I get 1263 errors - so I get error in all files -, but this is a sample traceback:
#class NSString, Protocol; <== ERROR HERE
Traceback:
cd /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone
setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.0 -x c-header -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D__IPHONE_OS_VERSION_MIN_REQUIRED=20000 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk -fvisibility=hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-generated-files.hmap -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-own-target-headers.hmap -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-all-target-headers.hmap -iquote /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-project-headers.hmap -F/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/Debug-iphonesimulator -F/Volumes/CrashReporter-1.0-rc2/CrashReporter-iPhone -F/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/Debug-iphonesimulator/include -I/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/usr/include/libxml2 "-I/Developer/RemObjects Software/Source" -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/DerivedSources/i386 -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/DerivedSources -c /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h -o /var/folders/EA/EAmC8fuyElexZfnpnjdyr++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/UIKit-dqqtnrciylhdtjbmyglpcezxchmz/UIKit.h.gch
In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12,
from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIAccelerometer.h:8,
from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:9:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:120:
error: syntax error before '#' token
I finally figure out the problem.
I copy this from the iPhone target to the Testing target:
GCC_DYNAMIC_NO_PIC = NO
GCC_OPTIMIZATION_LEVEL = 0
GCC_PRECOMPILE_PREFIX_HEADER = YES
GCC_PREFIX_HEADER = JhonSell_Prefix.pch
GCC_PREPROCESSOR_DEFINITIONS = DEBUG
But why before I have not issues? I truly not understand.
With very little to go on, my guess would be including an Objective C header from a C/C++ implementation file, hence compiling the header in C/C++ instead of Objective C/Objective C++.
Looking at your updated information, you are actually compiling a header file, namely UIKit.h. The compiler has no idea what type of header file it is, so it defaults to C, which of course does not have #class and hence the syntax error.
So you will have to figure out why Xcode wants to compile UIKit.h in your second target.
Your gcc command line is compiling a .h file to a .gch file.
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.0
# ...
-x c-header -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs # ...
# ...
# THE INPUT FILE:
/Developer/Platforms/iPhoneSimulator.platform/Developer/
SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Framework/
UIKit.framework/Headers/UIKit.h
# THE OUTPUT FILE:
-o /var/folders/EA/EAmC8fuyElexZfnpnjdyr++++TI/
-Caches-/com.apple.Xcode.501/
SharedPrecompiledHeaders/UIKit-dqqtnrciylhdtjbmyglpcezxchmz/UIKit.h.gch
I.e. UIKit.h into UIKit.h.gch: translating a header file into a "precompiled" header that can be included faster because it is in a tokenized form.
Looks like the compiler doesn't know it's supposed to be precompiling a header; it is configured incorrectly somehow, and is just treating that as code to be actually compiled, and choking because the code is Objective C.