I am trying to compile hdf5-1.8.22 using Intel oneAPI Base Toolkit/HPC Toolkit 2022.1. The configuration without Intel oneAPI was performed with the following command:
CC=$DIR/mpich/bin/mpicc FC=$DIR/mpich/bin/mpif90 CXX=$DIR/mpich/bin/mpicxx CFLAGS=-fPIC ./configure --prefix=$DIR/hdf5 --enable-parallel --enable-fortran --enable-production --enable-shared
The process completed successfully. The configuration with Intel oneAPI looks like this:
CC=$INTEL/oneapi/compiler/latest/linux/bin/intel64/icc CXX=$INTEL/oneapi/compiler/latest/linux/bin/intel64/icpc F77=$INTEL/oneapi/compiler/latest/linux/bin/intel64/ifort MPIF90=$INTEL/oneapi/mpi/latest/bin/mpif90 MPICC=$INTEL/oneapi/mpi/latest/bin/mpicc MPICXX=$INTEL/oneapi/mpi/latest/bin/mpiicpc CFLAGS="-fPIC -O3 -xHost -ip -fno-alias -align" FFLAGS="-fPIC -O3 -xHost -ip -fno-alias -align" CXXFLAGS="-fPIC -O3 -xHost -ip -fno-alias -align" FFLAGS="-I$INTEL/oneapi/mpi/latest/include -L$INTEL/oneapi/mpi/latest/lib" ./configure --prefix=$DIR/hdf5 --enable-parallel --enable-fortran --enable-production --enable-shared --enable-static --enable-hl --with-szlib=$DIR/szip-2.1 --with-zlib=$DIR/zlib-1.2.7
It fails with the following log:
checking for an ANSI C-conforming const... yes
checking if the compiler understands __inline__... yes
checking if the compiler understands __inline... yes
checking if the compiler understands inline... yes
checking for __attribute__ extension... yes
checking for __func__ extension... yes
checking for __FUNCTION__ extension... yes
checking for C99 designated initialization support... yes
checking how to print long long... %unknownd and %unknownu
checking Threads support system scope... no
checking enable debugging symbols... no
checking enable developer warnings... no
checking profiling... no
checking optimization level... high
checking for debug flags... none
checking whether function stack tracking is enabled... no
checking whether metadata trace file code is enabled... no
checking for API tracing... no
checking for instrumented library... no
checking whether to clear file buffers... yes
checking whether a memory checking tool will be used... no
checking for parallel support files... provided by compiler
checking whether a simple MPI-IO C program can be linked... no
configure: error: unable to link a simple MPI-IO C program
How to fix this error?
UPD:
If I use CC=mpiicc the full error log looks like this:
configure:4562: $? = 0
configure:4551: /../../intel/oneapi/mpi/latest/bin/mpiicc -qversion >&5
icc: command line warning #10006: ignoring unknown option '-qversion'
ld: cannot find -lmpifort
ld: cannot find -lmpi
configure:4562: $? = 1
configure:4582: checking whether the C compiler works
configure:4604: /../../intel/oneapi/mpi/latest/bin/mpiicc -fPIC -O3 -xHost -ip -fno-alias -align conftest.c >&5
ld: cannot find -lmpifort
ld: cannot find -lmpi
configure:4608: $? = 1
configure:4646: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "HDF5"
| #define PACKAGE_TARNAME "hdf5"
| #define PACKAGE_VERSION "1.8.22"
| #define PACKAGE_STRING "HDF5 1.8.22"
| #define PACKAGE_BUGREPORT "help#hdfgroup.org"
| #define PACKAGE_URL ""
| #define PACKAGE "hdf5"
| #define VERSION "1.8.22"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:4651: error: in `/../../hdf5-1.8.22':
configure:4653: error: C compiler cannot create executables
I found a solution, maybe not quite correct, but it solves my problem.
I changed the version from hdf5-1.8.22 to hdf5-1.12.1 and configured with the following command:
CC=$INTEL/oneapi/mpi/latest/bin/mpiicc CFLAGS="-I$INTEL/oneapi/mpi/latest/include -L$INTEL/oneapi/mpi/latest/lib/release -L$INTEL/oneapi/mpi/latest/lib -fPIC -O3 -xsse4.2 -align" FC=$INTEL/oneapi/mpi/latest/bin/mpiifort FCFLAGS="-I$INTEL/oneapi/mpi/latest/include -L$INTEL/oneapi/mpi/latest/lib/release -L$INTEL/oneapi/mpi/latest/lib -fPIC -O3 -xsse4.2 -lgfortran -nofor-main" ./configure --prefix=$DIR/hdf5 --enable-parallel --enable-fortran --enable-build-mode=production --enable-shared --enable-static --with-szlib=$DIR/szip-2.1 --with-zlib=$DIR/zlib-1.2.7
Related
I'm trying to get ASAN working with one program, but anything I did led to ASAN:DEADLYSIGNAL, so I tried to narrow it down and instrument a small test program with only a few compiler options, just to see if it will work at all:
$ cat > test.c <<EOF
int main(void) { return 0; }
EOF
Here's the command line:
$ gcc -g -O0 -fno-omit-frame-pointer -fsanitize=address test.c && ./a.out
ASAN:DEADLYSIGNAL
=================================================================
==5711==ERROR: AddressSanitizer: SEGV on unknown address 0xb7f11e70 (pc 0xb7f11e84 bp 0xb7ab6320 sp 0xbf92368c T16777215)
==5711==The signal is caused by a WRITE memory access.
#0 0xb7f11e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0xb7a24ff9 (/usr/lib/i386-linux-gnu/libasan.so.4+0x101ff9)
#2 0xb7a10f15 (/usr/lib/i386-linux-gnu/libasan.so.4+0xedf15)
#3 0xb7f0f91a (/lib/ld-linux.so.2+0xf91a)
#4 0xb7f00cb9 (/lib/ld-linux.so.2+0xcb9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in _dl_get_tls_static_info
==5711==ABORTING
(The same error I got for the "real" program.)
With -static-libasan the stack trace is just a bit more descriptive:
$ gcc -g -O0 -fno-omit-frame-pointer -fsanitize=address -static-libasan test.c && ./a.out
ASAN:DEADLYSIGNAL
=================================================================
==5719==ERROR: AddressSanitizer: SEGV on unknown address 0xb7fc6e70 (pc 0xb7fc6e84 bp 0x005f91a0 sp 0xbfe77c2c T16777215)
==5719==The signal is caused by a WRITE memory access.
#0 0xb7fc6e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0x560a49 in __sanitizer::InitTlsSize() (/home/gkirilov/test/a.out+0xe9a49)
#2 0x552e05 in __asan::AsanInitInternal() (/home/gkirilov/test/a.out+0xdbe05)
#3 0xb7fc491a (/lib/ld-linux.so.2+0xf91a)
#4 0xb7fb5cb9 (/lib/ld-linux.so.2+0xcb9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in _dl_get_tls_static_info
==5719==ABORTING
Here are some details about the system:
$ uname -a
Linux drinkpad 4.14.0-3-686-pae #1 SMP Debian 4.14.17-1 (2018-02-14) i686 GNU/Linux
$ gcc --version
gcc (Debian 7.3.0-11) 7.3.0
$ /lib/i386-linux-gnu/libc-2.27.so
Compiled by GNU CC version 7.3.0.
libc ABIs: UNIQUE IFUNC
I also tried clang-6 and gcc-8 (which brings ASAN v5 with it), again, with static and shared libasan, and I got the same messages.
Is my platform not supported? But then, I installed all tools from the official Debian repositories.
The home page of ASAN says that it has only been tested on 64-bit Ubuntu, but I think it is outdated, as the table just above it lists both Linux x86 and x86_64.
Am I doing anything wrong or is my platform not supported?
You are facing a known Asan bug (here's Glibc thread
and GCC bug). TLDR is that it fails on Glibc 2.25+ because Glibc changed some internal interfaces that Asan relied upon. Sadly this bug hasn't got enough attention yet.
I found these lines in the Qt WebEngine 5.5 and 5.6 recipe
To make Qt Web Engine compile for 5.6, I needed to delete these lines. Since I have no idea why qtwebengine-qmlplugins, qtwebengine-plugins, and qtwebengine-examples are all gone from the build. So when these lines try to remove the files from the plugin directories. It returns error.
Could someone explain what do they mean? especially the sed one. And what happened to the Qtwebengine plugins, qmlplugins and examples in Qt WebEngine 5.6?
do_install_append() {
rmdir ${D}${OE_QMAKE_PATH_PLUGINS}/${BPN} ${D}${OE_QMAKE_PATH_PLUGINS} || true
sed -i 's# -Wl,--start-group.*-Wl,--end-group##g; s#-L${B}[^ ]* # #g' ${D}${libdir}/pkgconfig/Qt5WebEngineCore.pc
}
Edit: This is the error from compiling
ERROR: Function failed: do_install (log file is located at /mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/temp/log.do_install.3412)
ERROR: Logfile of failure stored in: /mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/temp/log.do_install.3412
Log data follows:
| DEBUG: Executing shell function do_install
| NOTE: make -j 32 MAKEFLAGS=-j 32 OE_QMAKE_COMPILER=arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board OE_QMAKE_CC=arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board OE_QMAKE_CXX=arm-poky-linux-gnueabi-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board OE_QMAKE_CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types OE_QMAKE_CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types -fvisibility-inlines-hidden OE_QMAKE_LINK=arm-poky-linux-gnueabi-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board OE_QMAKE_LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed OE_QMAKE_AR=arm-poky-linux-gnueabi-ar OE_QMAKE_STRIP=echo OE_QMAKE_WAYLAND_SCANNER=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/x86_64-linux/usr/bin/wayland-scanner OE_QMAKE_INCDIR_QT=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board//usr/include/qt5 install INSTALL_ROOT=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/image
| make: Nothing to be done for `install'.
| rmdir: failed to remove '/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/image/usr/lib/qt5/plugins/qtwebengine': No such file or directory
| rmdir: failed to remove '/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/image/usr/lib/qt5/plugins': No such file or directory
| sed: can't read /mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/image/usr/lib/pkgconfig/Qt5WebEngineCore.pc: No such file or directory
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_install (log file is located at /mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/temp/log.do_install.3412)
ERROR: Task 1523 (/mountdata/hio-yocto-bsp/qt5jethro/sources/meta-qt5/recipes-qt/qt5/qtwebengine_git.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5404 tasks of which 5363 didn't need to be rerun and 1 failed.
No currently running tasks (5404 of 5417)
Edit: I found out that there is an extra / .../hio-imx6dl-board//usr/include.... I have removed the / in OE_QMAKE_INCDIR_QT='${STAGING_DIR_TARGET}/${OE_QMAKE_PATH_HEADERS}' but still get the same error above.
OE_QMAKE_INCDIR_QT=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/sysroots/hio-imx6dl-board//usr/include/qt5 install INSTALL_ROOT=/mountdata/hio-yocto-bsp/qt5jethro/qt5/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtwebengine/5.5.99+5.6.0-rc+gitAUTOINC+3f02c25de4_779a2388fc-r0/image
This error occurs due to missing dbus, multiple solutions possible:
Add dbus to your image.
Add line to qtwebengine_git.bb: DEPENDS += "dbus"
I am trying to compile the quazip source, under wdinwso 7 with QT5.4.
I tried compiling unders VS 2013, but the rc.exe file is not found. I made sure that the rc.exe and dll were in the kits and SDK folders for both vs2013 and vs2010.
So I followed this: http://www.maefloresta.com/portal/quazip
When i do so, I get the following error message, and am not sure where to start looking.
C:\development\QTCommon\quazip>mingw32-make
cd quazip\ && ( if not exist Makefile C:\development\QT\5.4\5.4\msvc2013_64\bin\
qmake.exe C:\development\QTCommon\quazip\quazip\quazip.pro -o Makefile ) && ming
w32-make -f Makefile
mingw32-make[1]: Entering directory 'C:/development/QTCommon/quazip/quazip'
mingw32-make -f Makefile.Release
mingw32-make[2]: Entering directory 'C:/development/QTCommon/quazip/quazip'
cl -c -nologo -Zm200 -Zc:wchar_t -FS -O2 -MD -Zc:strictStrings -W3 -w34100 -w341
89 -GR -EHsc -DUNICODE -DWIN32 -DQUAZIP_BUILD -DNOMINMAX -DQT_NO_DEBUG -DQT_CORE
_LIB -DNDEBUG -I"." -I"C:\development\QT\5.4\5.4\msvc2013_64\Src\qtbase\src\3rdp
arty\zlib" -I"C:\development\QT\5.4\5.4\msvc2013_64\include" -I"C:\development\Q
T\5.4\5.4\msvc2013_64\include\QtCore" -I"release" -I"C:\development\QT\5.4\5.4\m
svc2013_64\mkspecs\win32-msvc2013" -Forelease\ #<<
<< was unexpected at this time.
Makefile.Release:116: recipe for target '{release}.cpp{release\}.obj' failed
mingw32-make[2]: *** [{release}.cpp{release\}.obj] Error 255
mingw32-make[2]: Leaving directory 'C:/development/QTCommon/quazip/quazip'
Makefile:34: recipe for target 'release' failed
mingw32-make[1]: *** [release] Error 2
mingw32-make[1]: Leaving directory 'C:/development/QTCommon/quazip/quazip'
Makefile:41: recipe for target 'sub-quazip-make_first' failed
mingw32-make: *** [sub-quazip-make_first] Error 2
The makefile.release line found from quazip:
####### Implicit rules
.SUFFIXES: .c .cpp .cc .cxx
{release}.cpp{release\}.obj::
$(CXX) -c $(CXXFLAGS) $(INCPATH) -Forelease\ #<<
$<
<<
Any help would be great, for either the make or the vs 2013 issues.
Cheers.
If you are following the instructions from the link provided (http://www.maefloresta.com/portal/quazip) probably the origin of the problem could come because you are not build properly the QuaZIP libraries or because your include path or library path are wrong.
If you want a full example that works perfectly about how to use QuaZIP in Qt, I recommend you to check this entry of my blog: http://www.antonioborondo.com/2014/10/22/zipping-and-unzipping-files-with-qt/
Is there a way to make gnatmake tool recompile the Ada's runtime library ("RTS") with the project I'm building file by file? I want to integrate my custom preprocessor that adds some features to ada source code and then compiles it with gcc. I'm passing --GCC=<preprocessor> flag to the gnatmake utility, it figures out dependencies automatically and runs my preprocessor for all of my source files. However I want custom preprocessing to be done on code in the RTS as well, is there any way to do it?
The -a flag tells gnatmake to recompile any RTS files that need to be recompiled.
After a little experiment here it seems that if you copy system.ads (and maybe gnat.ads, interfac.ads .. yes) from the compiler’s adainclude/ directory to your source tree (I think you’ll need to touch it whenever you update your preprocessor), gnatmake may be able do what you want.
$ cp /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/system.ads .
$ gnatmake -a int
gcc -c int.adb
gcc -gnatpg -c -I./ -I- /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/s-stalib.adb
gcc -gnatpg -c -I./ -I- /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/a-except.adb
gcc -gnatpg -c -I./ -I- /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/s-valint.adb
gcc -gnatpg -c system.ads
...
gcc -gnatpg -c -I./ -I- /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/s-conca4.adb
gnatbind -x int.ali
gnatlink int.ali
and, after I realised I hadn’t used -gnata,
$ touch int.adb
$ gnatmake -a -gnata int
gcc -c -gnata int.adb
gcc -gnatpg -c -I./ -gnata -I- /opt/gcc-4.9.0/lib/gcc/x86_64-apple-darwin13/4.9.0/adainclude/s-assert.adb
gnatbind -x int.ali
gnatlink int.ali
(I do not want to use -f here, because it’ll rebuild everything.)
I've been trying to burn a program into ATtiny2313A-PU with my Arduino Uno R3 used as a programmer.
First I tried to program it from Arduino IDE 1.0.1 (Windows 7) and it seemed to uploade the sketch, but the blink program didn't work.
Then I found Michael Holachek's tutorial and followed his instructions:
uploaded ArduinoISP sketch to my Arduino Uno
wired the circuit on a breadboard
installed WinAVR on my Windows 7.
downloaded Michael's template files (Makefile and main.c) and edited Makefile to match my settings (external 8 MHz crystal). I used this online fuse calculator to get correct fuse parameters.
then, in cmd.exe, changed directory to the directory where I saved Makefile and main.c and ran 'make flash'
Makefile
DEVICE = attiny2313a
CLOCK = 8000000
PROGRAMMER = -c arduino -P COM5 -b 19200
OBJECTS = main.o
FUSES = -U lfuse:w:0x5e:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m
######################################################################
######################################################################
# Tune the lines below only if you know what you are doing:
AVRDUDE = avrdude $(PROGRAMMER) -p $(DEVICE)
COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)
# symbolic targets:
all: main.hex
.c.o:
$(COMPILE) -c $< -o $#
.S.o:
$(COMPILE) -x assembler-with-cpp -c $< -o $#
# "-x assembler-with-cpp" should not be necessary since this is the default
# file type for the .S (with capital S) extension. However, upper case
# characters are not always preserved on Windows. To ensure WinAVR
# compatibility define the file type manually.
.c.s:
$(COMPILE) -S $< -o $#
flash: all
$(AVRDUDE) -U flash:w:main.hex:i
fuse:
$(AVRDUDE) $(FUSES)
install: flash fuse
# if you use a bootloader, change the command below appropriately:
load: all
bootloadHID main.hex
clean:
rm -f main.hex main.elf $(OBJECTS)
# file targets:
main.elf: $(OBJECTS)
$(COMPILE) -o main.elf $(OBJECTS)
main.hex: main.elf
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
# If you have an EEPROM section, you must also create a hex file for the
# EEPROM and add it to the "flash" target.
# Targets for code debugging and analysis:
disasm: main.elf
avr-objdump -d main.elf
cpp:
$(COMPILE) -E main.c
main.c
Below is the output I got:
C:\Users>cd /D D:\electronics
D:\electronics>cd nikon/mi
D:\electronics\nikon\mi>make flash
avr-gcc -Wall -Os -DF_CPU=8000000 -mmcu=attiny2313a -c main.c -o main.o
main.c:6: error: stray '\342' in program
main.c:6: error: stray '\200' in program
main.c:6: error: stray '\250' in program
main.c: In function 'main':
main.c:9: error: stray '\342' in program
main.c:9: error: stray '\200' in program
main.c:9: error: stray '\250' in program
make: *** [main.o] Error 1
I suspect that I might brick the fuses on Attiny 2313a. If that is the case, I think I will have to build this AVR rescue shield.
Maybe the Makefile was configured incorrectly?
How can I identify the problem? How can I check whether the chip is still alive?
You are getting compile errors there. I would check the contents of main.c for what the compiler is telling you to check. It looks like in the copy and paste of the code, something was lost. Also
PORTD ^= (1 << PD6); // toggle PD6
can be replaced with
PIND = (1 << PD6); // or _BV(PD6), since you should be using avr-libc anyway.
as per Atmel's datasheets.
well, I googled a little bit more and found that the most common solution, when chips are identical, but have different suffixes (like attiny2313 and attiny2313a) is to use -F key for overriding the signature check.
So, I added the key in Makefile DEVICE = attiny2313 -F and my attiny2313a was programmed successfully!
TRON, thanks for pointing me in the direction of main.c! Unfortunately I can't upvote your answer because my reputation is 11.
I still wonder how those square characters could get there?