I am trying to build openssl-1.0.2j on Linux 64-bit with ASM enabled. Openssl-1.0.1u is the latest but not a good option for us. Without no-asm option I get the following error (with no-asm its OK):
No rule to make target `modexp512-x86_64.o', needed by `lib'
I tried different compilers on different CentOS VMs (CentOS 5.11 with gcc-4.1.2, CentOS 6.0 with gcc-4.4.4 and CentOS 7.1 with gcc-4.8.3) and got he same result.
We are using openssl-1.0.1l which built fine without "no-asm" option.
Because of the latest security vulnerability we need to move to a newer version of openssl.
I also found that when I pass "no-asm" option I pass the error above but I get an error about "ENGINE_load_rsax" being undefined.
Why am I getting the error related to modexp512-x86_64.o' when ASM is enabled? How do I fix it?
Here is how I ran the config to isolate the issue and the first portion of the output:
./config shared
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring for linux-x86_64
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC =gcc
CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
EX_LIBS =-ldl
CPUID_OBJ =x86_64cpuid.o
BN_ASM =x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC =des_enc.o fcrypt_b.o
AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC =bf_enc.o
CAST_ENC =c_enc.o
RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC =rc5_enc.o
MD5_OBJ_ASM =md5-x86_64.o
SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
ENGINES_OBJ =
PROCESSOR =
RANLIB =/usr/bin/ranlib
ARFLAGS =
PERL =/usr/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_UNROLL used
DES_INT used
RC4_CHUNK is unsigned long
I don't need engines in one of my builds so I ran config as follow and the build worked fine:
./config no-engines shared
I had to run make depend after the ./config thought as requested by ./config output.
At least I am no longer blocked for one of my builds.
I still need to be able to build without "no-engines" option for other builds.
In worse case scenario I will be forced to remove modexp512-x86_64.o from the Makefile after running ./config and then build.
Related
My goal is to add my Qt project to a Jenkins buildserver, for nightly builds. Therefore I want to compile my project from the command line. I copied the buildsteps located in the build configuration:
"/opt/fslc-x11/2.5/sysroots/x86_64-fslcsdk-linux/usr/bin/qt5/qmake" "/home/xxxx/repositories/xxx/xxx.pro" -spec linux-oe-g++ && /usr/bin/make qmake_all
"/usr/bin/make"
I execute these commands in the build directory. The problem lies in the qmake command. The qmake command generates the makefile, but this makefile is different when I generate it in the command line instead of in QtCreator. The binary result after make is ofcourse very different.
It seems that the qmake command from the command line creates a debug makefile instead of a release makefile:
CFLAGS = -pipe -02 -pipe -g -feliminate-unused-debug-types --sysroot=.........
The -02 -pipe -g -feliminate-unused-debug-types part is the only thing added when I run qmake in the command line (checked with diff).
I've tried the following:
Added CONFIG+=release to the qmake command
Added CONFIG-=DEBUG to the qmake command
Furthermore I've verified that the system environment and the terminal emulator is the same.
My question comes down to:
Why does qmake add the (debug) flags when running from the command line?
Does QtCreator add more to the environment that I might have missed?
Let me know if you need more information about the settings or the makefile that is generated.
Ok. So long story short: I've tried compiling for the local Linux distro with the standard qmake and my problem was solved.
It seems that problem lies at the custom qmake of the target (x86_64-fslcsdk-linux). I'm not gonna put more time in this issue, so feel free to add a more satisfying answer. I'll be happy to try it out :).
Hello I am trying to build wxWidgets 3.0 for use with code blocks. When I run the command given on the manual
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport
It says an error include \include/setup/.h:121:27: fatal error:
../../../lib/vc_x64_lib/mswu/wx/setup.h
It also says
C:\wxWidgets-3.0.4\build\msw>mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport
if not exist ..\..\lib\gcc_dll\mswu mkdir ..\..\lib\gcc_dll\mswu
gcc -c -o gcc_mswudll\wxregex_regcomp.o -O2 -mthreads -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_dll\mswu -D__WXMSW__ -D_UNICODE -MTgcc_mswudll\wxregex_regcomp.o -MFgcc_mswudll\wxregex_regcomp.o.d -MD -MP ../../src/regex/regcomp.c
In file included from ..\..\include/wx/platform.h:183:0,
from ..\..\include/wx/defs.h:27,
from ../../src/regex/regcustom.h:39,
from ../../src/regex/regguts.h:38,
from ../../src/regex/regcomp.c:33:
..\..\include/wx/setup.h:12:6: error: #error "This file should only be included when using Microsoft Visual C++"
#error "This file should only be included when using Microsoft Visual C++"
^
In file included from ..\..\include/wx/version.h:16:0,
from ..\..\include/wx/setup.h:19,
from ..\..\include/wx/platform.h:183,
from ..\..\include/wx/defs.h:27,
from ../../src/regex/regcustom.h:39,
from ../../src/regex/regguts.h:38,
from ../../src/regex/regcomp.c:33:
..\..\include/wx/setup.h:113:31: error: pasting "/" and "vc_x64_lib" does not give a valid preprocessing token
wxCONCAT6(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, wxSUFFIX, /wx/setup.h)
The manual I’m following is : http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef
You must have copied the file include/msvc/wx/setup.h to include/wx/setup.h manually, there is no other explanation for this file being there. You must not do it and now you need to remove the file you created and undo any other changes you may have done for the build to work.
If anything you try still gives errors then follow these instructions:
Remove the whole of the wxWidgets folder, in your case
C:\wxWidgets-3.0.4
Re-install wxWidgets, even in that same directory
Remove anything related to your old gcc (likely a dir and the PATH var, see below), and download an install a more recent version of gcc. From Mingw 32
mingw-get-setup.exe,
from Mingw 64 or from TDM combined
32/64. You will need to set this compiler as the default one to C::B later, for your app.
Add if needed your mingw/bin dir to the Windows PATH environment
var.
Open an command box window and copy&paste this line:
mingw32-make -f makefile.gcc BUILD=release UNICODE=1 USE_OPENGL=1
CXXFLAGS="-std=gnu++11 -fno-keep-inline-dllexport"
Note I've removed the MONOLITHIC=1 flag, sometimes it's a source of problems. The only consequence is that you have to add to your project settings a few libs (base, core, etc and in a proper order) instead of an only big one. Take a look at <wxWidgets dir>\lib
Addin mingw\bin to the PATH is an option. C::B doesn't need it. It's the command box who needs it. If you don't want to pollute the PATH var then you have to add it each time you open a command box to use the compiler:
Execute PATH=%PATH%;C:\MinGW\bin (where MinGW is where you installed the compiler) before using the compiler in this command box.
I'm trying to use Coverity Scan with an embedded application written in C++17 (ARM GCC Embedded v7.2). The application itself builds well and error/warning-free; however, the Coverity Scan Self-Build tool (cov-analysis-linux64-2017.07, the latest) fails to compile certain C++ files with the following error (abridged):
[19888] EXECUTING: /home/pavel/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/as -I . -I src -I src/os_config -I eigen -I senoval -I legilimens -I popcop/c++ -I build/current_build_info -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -meabi=5 -alms=build/lst/ch.lst -o build/obj/ch.o /tmp/ccK73Qaa.s
"/home/pavel/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/bits/c++17_warning.h", line 32:
error #35: #error directive: This file requires compiler and library
support for the ISO C++ 2017 standard. This support must be enabled
with the -std=c++17 or -std=gnu++17 compiler options.
#error This file requires compiler and library support \
^
As can be seen, the build tool did not pass the option -std=c++17 to the assembler. By the way, the application's own build system does not make direct calls to the assembler; the Self-Build tool does it on its own. This is how the Coverity Self-Build process is configured:
cov-configure --comptype gcc --compiler arm-none-eabi-gcc --template
make clean
cov-build --dir build/cov-int make -j8
cd build
tar czvf coverity.tgz cov-int
How do I configure the Self-Build tool to build C++17 code correctly?
I'm trying to build a NaCl extension on 64-bit Windows 8.1 using CMake. The same code works on Ubuntu without any problems. Everything goes well until CMake tries to link with this command:
cmake -E cmake_link_script link.txt
CMake: Error running link command: %1 is not a valid Win32 application
The link.txt is as follows:
C:/nacl_sdk/pepper_39/toolchain/win_pnacl/bin/pnacl-ar cr libfoo.a CMakeFiles/foo.dir/Foo.cc.o
C:/nacl_sdk/pepper_39/toolchain/win_pnacl/bin/pnacl-ranlib libfoo.a
This happens with both NMake and Unix makefile generators (the NaCl SDK contains make.exe for Windows).
If I run those commands manually, they succeed. What could be wrong here?
Just like eugensk00 suggested adding ".bat" in toolchain definitions seems to work. It is required to add both for ar and ranlib though:
set(CMAKE_AR "${PLATFORM_PREFIX}/bin/pnacl-ar.bat" CACHE STRING "")
set(CMAKE_RANLIB "${PLATFORM_PREFIX}/bin/pnacl-ranlib.bat" CACHE STRING "")
I'm trying to cross-compile Qt 4.7.1 from source, here are some notes on my setup:
my expected output is the shared object libraries that are required to be present in order to run a Qt application.
My target platform is a TI AM335x processor which is of the ARM Cortex-A8 architecture.
My development platform is a x86 64-bit Ubuntu virtual machine
My understanding of how this should work is that I download the toolchain for my target platform (this is the Linaro toolchain from TI), I download the source code for Qt 4.7.1, I set the mkspec to use my tool chain, run configure, then just need to run make/make install and I should be able to find all the .so's where I told it to install to. I'm having a lot of problems getting this idea to work however.
First I downloaded the TI SDK version: ti-sdk-am335x-evm-06.00.00.00 which has the arm tool's at:
[root_install_dir]/linux-devkit/sysroots/i686-arago-linux/usr/bin
I updated my $PATH with that directory:
mike#mike-VirtualBox:~$ echo $PATH
/home/mike/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin
:/usr/local/Trolltech/Qt-4.8.5/bin:/home/mike/bin:/usr/lib/lightdm/lightdm:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/mike/bin
I then created my own mkspec based on the closest example:
cp -R [qt_install_dir]/mkspecs/qws/linux-arm-gnueabi-g++/ [qt_install_dir]/mkspecs/qws/linux-am335x-g++
and I modified the linux-am335x-g++/qmake.conf to point to the tools from the TI sdk:
# modifications to g++.conf
QMAKE_CC = arm-linux-gnueabihf-gcc
QMAKE_CXX = arm-linux-gnueabihf-g++
QMAKE_LINK = arm-linux-gnueabihf-g++
QMAKE_LINK_SHLIB = arm-linux-gnueabihf-g++
# modifications to linux.conf
QMAKE_AR = arm-linux-gnueabihf-ar cqs
QMAKE_OBJCOPY = arm-linux-gnueabihf-objcopy
QMAKE_STRIP = arm-linux-gnueabihf-strip
Then I ran a configure command:
./configure -prefix /home/mike/qt4.7.1_source/my_qt -embedded arm -platform qws/linux-x86_64-g++ -xplatform qws/linux-am335x-g++ -no-mmx -no-3dnow -no-sse -no-sse2 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -fast -opensource
It runs for a while then completes and says it's ready to do make/make install at this point I run make and that's where it starts to fail:
/home/mike/qt4.7.1_source/qt-everywhere-opensource-src-4.7.1/bin/moc
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_HAVE_NEON -DQT_NO_DEBUG -I../../mkspecs/qws/linux-am335x-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared-emb-arm -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared-emb-arm kernel/qobject.h -o .moc/release-shared-emb-arm/moc_qobject.cpp arm-linux-gnueabihf-g++ -c
-include .pch/release-shared-emb-arm/QtCore -pipe -fno-exceptions -mfpu=neon -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_HAVE_NEON -DQT_NO_DEBUG -I../../mkspecs/qws/linux-am335x-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared-emb-arm -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared-emb-arm -o .obj/release-shared-emb-arm/qobject.o kernel/qobject.cpp {standard input}: Assembler messages:
{standard input}:1294: Error: selected processor does not support Thumb mode 'swp r6,r4,[r3]'
make[1]: [.obj/release-shared-emb-arm/qobject.o] Error 1* make[1]: Leaving directory
'/home/mike/qt4.7.1_source/qt-everywhere-opensource-src-4.7.1/src/corelib'
make: * [sub-corelib-make_default-ordered] Error 2
So, the question...
Why is the compiler complaining that the thumb mode is not supported? Since this is a cross compile tool chain for an ARM based processor, it should be supported. The fact that it's not makes me feel that make is somehow picking up the wrong version of g++.
Any thoughts on what went wrong and how to fix this?
{standard input}:1294: Error: selected processor does not support Thumb mode 'swp r6,r4,[r3]'
Why is the compiler complaining that the thumb mode is not supported?
Note, the compiler is complaining about the swp instruction not being available for thumb mode. Your CPU supports thumb, thumb2, and ARM. The Cortex series deprecates the use of swp and prefers ldrex/strex pairs.
Any thoughts on what went wrong and how to fix this?
You need to get gcc to define __ARM_ARCH_7__; this is done with either -mcpu=cortex-a8 or the combination -mtune=cortex-a8 and -march=armv7-a or what ever you like depending on how many types of boards you want Qt to run on.
In detail, see qatomic_arm.h for where a sub-file is selected. You have a very generic ARM selected (I guess), so you get qatomic_armv5.hNote1 where you can see the code around line 125. The right file for your CPU is qatomic_armv7.h, which mainly just includes qatomic_armv6.h. In this file you can find ldrex/strex which is the wholesome goodness that your gcc is requesting.
I also suggest you do not compile with -fast. There is another question where the OP says this solved his issue; but I think this is different.
You can try to pass -armfpa to configure. ./configure -embedded arm --help is useful. configure appears to have selected NEON, so it seems to know you have a more advanced CPU (there is no NEON on an armv5, but this maybe a fault of configure).
For certain, you don't want the swp code and the ldrex/strex is preferred for your system, even if swp could somehow work. I would at least resolve this. Alter the -xplatform qws/linux-am335x-g++ to update -mcpu or possibly pass an explicit -D__ARM_ARCH_7__. You can get a list of defines with arm-gcc -mcpu=cortex-a8 -dM -E - < /dev/null, to verify that the __ARM_ARCH_7__ is being defined. It looks like it is moc failing, so maybe the -D__ARM_ARCH_7_ solution will be needed.
You might also try to alter -mthumb in the compiler option. It is probably best to use -mcpu=cortex-a8 and -mthumb for your system, if you can get that to compile/build. Omitting -mthumb will make the code slightly larger. You might also try -Os. For some reason, I have huge builds with other optimizations and more recent gcc versions. It appears to be due to some C++ feature as normal 'C' doesn't behave this way; but this may just be my compiler. I looked and believe it is the exception tables, but I never confirmed anything and moved on. I am sure you are aware of how long Qt takes to compile.
Note1: The qatomic_armv5.h code is fairly confused and newer gcc or binutils will choke even when this is the correct file to use.
asm volatile("swpb %0,%2,[%3]"
: "=&r"(ret), "=m" (*ptr)
: "r"(newval), "r"(ptr)
: "cc", "memory");
This specifies some inline assembler parameters which are never used. Not to mention the condition codes are not used, etc.
asm volatile("swpb %0,%1,[%2]"
: "=r"(ret)
: "0"(newval), "r"(ptr)
: "memory");
will compile with newer gcc and binutils. It also uses less registers and is optimal for the way Qt is currently using it; there maybe cases where ret needs to be preserved to compare to newval but it is just a user space spin lock currently.
The bracket [x] is a memory operand register and must be different than the other two parameters for a valid swp. I believe the first form was used to stop %0 from being the same as %3. The 2nd form avoids this by making %0 and %1 the same, so %2 must be different.
the answer by usr: artless noise did in fact fix my issue, but since I want to make sure there is a very clear trail for myself (if needed) or others, I want to state exactly what the fix was:
First, I updated my .configure command to:
./configure -prefix /home/mike/qt4.7.1_source/my_qt -embedded arm -platform qws/linux-x86_64-g++ -xplatform qws/linux-am335x-g++ -no-mmx -no-3dnow -no-sse -no-sse2 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -opensource -qt-mouse-tslib
The only difference from the question's configure command is the removal of the -fast option.
Then in my the linux-am335x-g++/qmake.conf file, I added a few command line options:
QMAKE_CFLAGS= -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
QMAKE_CXXFLAGS= -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
With these two change I can now see everything build and install Qt4.7.1 successfully.
I also tried Qt4.8.5 and everything works the same except one more option has to be added to the ./configure command:
-no-pch
This is to avoid an error regarding a: .pch
directory and files in side showing "No such file or directory"