I am working on a small project of mine on Digilent Atlys and after all of the standard generating the netlist and bitstream, and exporting to SDK, I happen to get a weird error which states that the xil_cache.h is not present anywhere (even though it is there).
I need to mention that if I don't add an interrupt controller and a timer it works, but I really do need them.
Has anyone encountered this error before?
Error Message:
08:24:21 **** Build of configuration Debug for project hiworld ****
make all
'Building file: ../src/helloworld.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -I../../hiworld_bsp/microblaze_0/include -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v8.50.c -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/helloworld.d" -MT"src/helloworld.d" -o "src/helloworld.o" "../src/helloworld.c"
'Finished building: ../src/helloworld.c'
' '
'Building file: ../src/platform.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -I../../hiworld_bsp/microblaze_0/include -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v8.50.c -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/platform.d" -MT"src/platform.d" -o "src/platform.o" "../src/platform.c"
../src/platform.c:43:23: fatal error: xil_cache.h: No such file or directory
compilation terminated.
make: *** [src/platform.o] Error 1
08:24:21 Build Finished (took 734ms)
Try after setting below environmental variables:
XILINX = C:\Xilinx\14.5\ISE_DS
XILINX_EDK = C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64
this is suggested in the Xilinx forum and seems to solve the problem.
A user writes:
"Magic :-)
I created a batch file to launch it, as from what I know the path variables persit within that batch file
I set it to
set path=""
XILINX = C:\Xilinx\14.5\ISE_DS
XILINX_EDK = C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64
C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64\xsdk.exe
Interesting the shortcut to the SDK first contains a link to settings64.bat which I assumed set all these variables correctly, but it looks like it doesnt get them right!
I have to admit its been a trek just getting this far as the documentation is a bit blurry."
Here you can find the page.
Related
I'm stuck compiling a bitbake recipe for an Allwinner H2 SoC. It seems to be a problem of floating point unit compatibility. This is the compilation error log (abbreviated paths and added line breaks for a little better readability):
python3-scipy/1.3.3-r0/recipe-sysroot-native/[...]/gcc/arm-poky-linux-gnueabi/8.3.0/ld: error: build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so uses VFP register arguments, build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o) does not
python3-scipy/1.3.3-r0/recipe-sysroot-native/[...]/gcc/arm-poky-linux-gnueabi/8.3.0/ld:: failed to merge target specific data of file build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o)
[...]
| error: Command "/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -Wall -g -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard \
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security \
--sysroot=/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot -shared -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now \
-L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib/python3.7/site-packages/numpy/core/lib build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/_fftpackmodule.o \
build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/drfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zrfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfftnd.o \
build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dct.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dst.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/fortranobject.o \
-L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib -Lbuild/temp.linux-x86_64-3.7 -ldfftpack -lfftpack -lpython3.7m \
-lgfortran -o build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so -Wl,--version-script=build/temp.linux-x86_64-3.7/link-version-scipy.fftpack._fftpack.map" failed with exit status 1
| ERROR: 'python3 setup.py build ' execution failed.
I tried to enforce hard and soft FPU handling by setting target_FPU="soft", "hard" and "vfp-neon" in the machine configuration. In all cases compilation crashed at the same step. I further experimented with the compiler flags of the failing step, such as changing -mfloat-abi to soft, hard and vfp-neon. None lead to success.
Any hint on how to compile this recipe for this architecture is highly appreciated!
Edit: This is the recipe I'm trying to bitbake: meta-scipy
The error you see happen because the fortran compiler isn't passed the correct floating point arguments. I've created a pull request to meta-scipy which solves this, at least I can now build for Raspberry Pi without forcing soft-float.
This is rather a workaround but allowed to finally compile this recipe: Disable hard float ABI by changing the DEFAULTTUNE. This TUNE worked:
DEFAULTTUNE ?= "cortexa7t-neon"
As discussed here: https://github.com/gpanders/meta-scipy/issues/2#issuecomment-603266558
Im using poky version of yocto, and adding zbar library in my yocto build. I found a readymade recipe at http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/zbar/zbar_0.10.bb and modified it a bit to get working with poky. I got it working fine with imagemagick, and the compiled zbarimg works on the target board.
The modified recipe is available here: http://paste.ubuntu.com/25725000/
When I proceed configuring python support (--with-python) to the build, some dependency issues crept up, which Im unable to resolve.
It appears as if the compiler doesn't find the appropriate headers, since the include paths don't contain appropriate folder.
The full compiler command is:
arm-poky-linux-gnueabi-libtool: compile: arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc -DHAVE_CONFIG_H -I. -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10 -I./include -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/python2.7 -I/usr/include/python2.7 -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/include -Wall -Wno-parentheses -O2 -pipe -g -feliminate-unused-debug-types -c /home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/python/symbol.c -fPIC -DPIC -o python/.libs/python_zbar_la-symbol.o
You can see that sysroot variable is set, and it appears like the right location, and there is /usr/include/python2.7 there, though its pointing right at the host system include path.
There is a warning from compiler: cc1: warning: include location "/usr/include/python2.7" is unsafe for cross-compilation [-Wpoison-system-directories] which I don't know why it happens, but it seems like the python2.7 folder is appropriately looked at, just not under the sysroot (my host system doesn't have /usr/lib/python2.7)
If I go to the sysroot include (/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc/usr/include/) folder, I can see that it has a subfolder python2.7. If under this usr/include folder I add a symlink Python.h -> python2.7/Python.h, the compiler will complain about the next header file which is not found.
So to me it seems, all I should do is add the appropriate 'sysroot' + usr/include/python2.7 as include search folder it would compile happily - but Im not sure how..
The full compilation log is available here: http://paste.ubuntu.com/25725014/
This is a bug in the zbar configure script.
Try inheriting pythonnative so the configure script can run a compatible Python to know where to look.
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
Im developing an android app thats loading two shared libraries. One is external, its called libpcan.so . Usually its build to libpcan.so.0.6, this somehow cant be used by my android, i so changed the gcc flags compiling it from:
arm-linux-androideabi-gcc src/libpcan.c -fPIC -shared -O2 -Wall -Wl,-soname,-libpcan.so.0 -lc -I. -I../driver -DNO_RT -o -libpcan.so.0.6
ln -sf libpcan.so.0.6 libpcan.so
to
arm-linux-androideabi-gcc src/libpcan.c -fPIC -shared -O2 -Wall -lc -I. -I../driver -DNO_RT -o -libpcan.so
This .so has the same size as the so.0.6 so i assume it worked fine.
My own c-code is getting compiled with
arm-linux-androideabi -shared src/receivetest.c src/common.c -I. -I../lib -I../driver -L../lib -L/lib -L/usr/lib -L/usr/local/lib -o libreceivetest.so
I load both of these files, so the libpcan.so and the libreceivetest.so to my app
static {
System.loadLibrary("pcan");
System.loadLibrary("receivetest");
}
When I'm trying to launch that app i get the error message:
07-14 11:12:43.812: E/AndroidRuntime(753): java.lang.ExceptionInInitializerError
07-14 11:12:43.812: E/AndroidRuntime(753): Caused by: java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1306]: 36 cannot locate 'CAN_Open'...
My receivetest is using that function, but since it declared in the libpcan.so and im also loading that library, i don't know where that error could come from.
I'd just guess its an error in my clags, since I'm new to building .so files via using gcc in the shell i don't really understand all the flags im using.
It's quite long since i solved this. But I haven't ever marked this question as solved.
Thanks to jww for reminding me.
As I've said in the comment to my question, the link to the function CAN_Open was missing due to a missing parameter at compiling the .so-file. The function CAN_Open is a part of the libpcan.so and by skipping the link to that file the CAN_Open function just never made it into the receivetest.so .
I am using GCC for ARM (Red Suite 4 NXP). I am compiling static library files (.a) that are used for a final application. I need to configure the project so any developer can produce the exact same static library output. (This is mainly so a new developer can verify they have their setup correct.) I have two copies of my project (two checkouts from SVN). When I build with each, I notice some absolute path information in the static library .a output files. This means that SVN detects as a change. I'm using the ar -D (deterministic) option already. Are there any other options to remove path information? I tried gcc -s but this didn't work (it appears this is only for final executable, not libraries)
I don't know where/why the absolute paths are in the .a, but I can provide more information if someone can point me in the right direction.
I've looked at the strip utility man pages (haven't tried it yet), would this remove this path information?
Also, I am using Red Suite to manage the project, so I'm trying to do things the Red Suite way (and to let it do its thing). However, if there is a gcc or ar option I need to adjust, I do know how to do that. I just don't know what option to change.
Here is the build console output. This causes the absolute path of my project to be included into the resulting .a. That is what I am trying to fix.
**** Build of configuration Release for project lib_touch ****
make -j all
Building file: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/Touch.c
Building file: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchCalibration.c
Building file: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchPoint.c
Building file: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchEventQueue.c
Invoking: MCU C Compiler
Invoking: MCU C Compiler
arm-none-eabi-gcc -D__REDLIB__ -DNDEBUG -D__CODE_RED -D__USE_CMSIS=CMSISv2p00_LPC177x_8x -I"C:\Users\my_user_name\Documents\My Project Verification build\src\build\RedSuite4NXP\CMSISv2p00_LPC177x_8x\inc" -I../../../../board -I../../../../board/lpc1788 -I../../../../communication -I../../../../events -I../../../../geometry -I../../../../graphics -I../../../../hmilogic/include -I../../../../sound -I../../../../util -O3 -Wall -Werror -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -std=gnu99 -mcpu=cortex-m3 -mthumb -MMD -MP -MF"touch/Touch.d" -MT"touch/Touch.d" -o"touch/Touch.o" "C:/Users/my_user_name/Documents/My Project Verification build/src/touch/Touch.c"
arm-none-eabi-gcc -D__REDLIB__ -DNDEBUG -D__CODE_RED -D__USE_CMSIS=CMSISv2p00_LPC177x_8x -I"C:\Users\my_user_name\Documents\My Project Verification build\src\build\RedSuite4NXP\CMSISv2p00_LPC177x_8x\inc" -I../../../../board -I../../../../board/lpc1788 -I../../../../communication -I../../../../events -I../../../../geometry -I../../../../graphics -I../../../../hmilogic/include -I../../../../sound -I../../../../util -O3 -Wall -Werror -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -std=gnu99 -mcpu=cortex-m3 -mthumb -MMD -MP -MF"touch/TouchCalibration.d" -MT"touch/TouchCalibration.d" -o"touch/TouchCalibration.o" "C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchCalibration.c"
Invoking: MCU C Compiler
Invoking: MCU C Compiler
arm-none-eabi-gcc -D__REDLIB__ -DNDEBUG -D__CODE_RED -D__USE_CMSIS=CMSISv2p00_LPC177x_8x -I"C:\Users\my_user_name\Documents\My Project Verification build\src\build\RedSuite4NXP\CMSISv2p00_LPC177x_8x\inc" -I../../../../board -I../../../../board/lpc1788 -I../../../../communication -I../../../../events -I../../../../geometry -I../../../../graphics -I../../../../hmilogic/include -I../../../../sound -I../../../../util -O3 -Wall -Werror -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -std=gnu99 -mcpu=cortex-m3 -mthumb -MMD -MP -MF"touch/TouchEventQueue.d" -MT"touch/TouchEventQueue.d" -o"touch/TouchEventQueue.o" "C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchEventQueue.c"
Finished building: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/Touch.c
arm-none-eabi-gcc -D__REDLIB__ -DNDEBUG -D__CODE_RED -D__USE_CMSIS=CMSISv2p00_LPC177x_8x -I"C:\Users\my_user_name\Documents\My Project Verification build\src\build\RedSuite4NXP\CMSISv2p00_LPC177x_8x\inc" -I../../../../board -I../../../../board/lpc1788 -I../../../../communication -I../../../../events -I../../../../geometry -I../../../../graphics -I../../../../hmilogic/include -I../../../../sound -I../../../../util -O3 -Wall -Werror -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -std=gnu99 -mcpu=cortex-m3 -mthumb -MMD -MP -MF"touch/TouchPoint.d" -MT"touch/TouchPoint.d" -o"touch/TouchPoint.o" "C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchPoint.c"
Finished building: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchEventQueue.c
Finished building: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchCalibration.c
Finished building: C:/Users/my_user_name/Documents/My Project Verification build/src/touch/TouchPoint.c
Building target: lib_touch.a
Invoking: MCU Archiver
arm-none-eabi-ar -rD "lib_touch.a" ./touch/Touch.o ./touch/TouchCalibration.o ./touch/TouchEventQueue.o ./touch/TouchPoint.o
c:\code_red\RedSuiteNXP_4.3.0_1033\redsuite\tools\bin\arm-none-eabi-ar.exe: creating lib_touch.a
Finished building target: lib_touch.a
make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size "lib_touch.a" ; cp "lib_touch.a" "../../../../lib/lib_touch.a"; # arm-none-eabi-objdump -h -S "lib_touch.a" >"lib_touch.lss"
text data bss dec hex filename
1864 0 156 2020 7e4 Touch.o (ex lib_touch.a)
576 0 0 576 240 TouchCalibration.o (ex lib_touch.a)
320 0 0 320 140 TouchEventQueue.o (ex lib_touch.a)
96 0 0 96 60 TouchPoint.o (ex lib_touch.a)
UPDATE: MORE INFORMATION
I have done some more digging, and it appears the full file path is in front of a string constant. The path data within the .a file shows
C:/Users/my_user_name/Documents/My Project Verification build/src/touch/Touch.c.TouchIdleTimer
I have a string literal "TouchIdleTimer" within the file Touch.c. Is this the cause? How would I remove the path portion, or is it possible? TIA
Update
Via this answer to GCC: static linking only some libraries
Note: If you use full path of a .so file, it will again be linked in dynamically.
Enhanced Static Library Support in Code Red IDE v4: Creating static library projects
Searching around I'm seeing suggestions for -fPIC or -fpic. It was recommended in this comment thread in response to a question similar to yours.
3.2 Shared libraries and static libraries provides a nice breakdown of compiling shared and static libraries.
You stated static not shared libraries but just in case: How to Write Shared Libraries