I want to produce codec without SIMD and assembler. I'm using basic functions -std=gnu++11 -ftree-vectorize -g0 -O3 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -DWIN32_LEAN_AND_MEAN=/"/" -DNOMINMAX.
The problem is that when I create AOM codecs in GCC 11.3.X they work. On newer compilers GCC 12.2 and gcc13.0 no longer work. What have new features been added to these compilers?
Strange thing. Other libraries have no problem:
libjpeg-turbo, libpng, libtiff, dav1d, libgav1, avif, svt-av1, openhtj2k, openjph, openjpeg2000, ...
Related
I am trying to build cmake source, which requires C++11.
The build halts and apparently the complaint is that C++11 is not detected. The g++ mode is actually set to -std=gnu++17
This is part of the console log
---------------------------------------------
CMake 3.18.20200919, Copyright 2000-2020 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++17
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
g++ -std=gnu++17 -DCMAKE_BOOTSTRAP -DCMake_HAVE_CXX_MAKE_UNIQUE=1 -c $HOME/Apps/CMake-master/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o
This is part of the error in the log file...
In file included from /usr/include/c++/5/unordered_map:35:0,
from cmake_bootstrap_11920_test.cxx:4:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
cmake_bootstrap_11920_test.cxx:7:2: error: #error "Compiler is not in a mode aware of C++11."
#error "Compiler is not in a mode aware of C++11."
^
cmake_bootstrap_11920_test.cxx:70:16: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
int Member = 1;
Looking around on the web, I noticed that C++11 is only available after gcc version 4.6.
I checked my version, and it seems to be above.
g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
I understand the -std=c++11 flag is used to enable the C++11 features in g++, but I don't seem to know what I am doing in this case.
I tried editing the CompileFlags.cmake file, but no change occurs.
I came upon this page which points to the cmake source I am using.
It says...
bootstrap: Require compiler mode aware of C++11
Some compilers have enough features enabled in their default modes to
pass our simple C++11 unique_ptr check but do not enable enough to build
CMake. Poison this case so that we choose one of the explicit `-std=`
options for such compilers.
Not sure what that means exactly.
How exactly do I change the g++ mode, to C++11, so that on running the bootstrap command, C++11 is used?
Or, in other words, how do I change std to point to C++11 (-std=c++11)?
First of all, you have g++ version 5.4.0 in your host PC installed, which is good, cause it means this is also supports the C++11, which you want to use.
To set it up, you could define it in your CMakeList.txt file:
set (CMAKE_CXX_STANDARD 11)
that should do the trick.
Please also check the documentation:
https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html
Usually, I would suggest to use the latest standard that you compiler is supporting (https://gcc.gnu.org/projects/cxx-status.html), cause you'll get also the latest features introduced in that standard. Exception for this rather in case you are working with legacy codes.
I'm using the Windows version of Clang (LLVM) 8 under Windows.
I'm compiling a code which uses OpenMP.
Under the lib folder of Clang there are 2 files which are OpenMP related:
libomp.lib.
libiomp5md.dll.
My questions are:
When I compile the code I use the flags -Xclang -fopenmp for the compiler. In in GCC and ICC using the flags tell the compiler to link the OpenMP library automatically. What about Clang? Does it do it automatically or must I link with libomp.lib manually? Is there a way to trigger automatic linking to the OpenMP library?
Answer: This was answered in Michael Klemm's answer below - Use the clang driver both for compiling and linking and then the -fopenmp will work as in GCC.
When I link with libomp.lib manually (Defining as a library for the linker) the output exe requires libomp.dll while the supplied OpenMP Dynamic Library is libiomp5md.dll. Is that a bug or is it because I link manually?
Answer: The libomp.dll is supplied in the bin folder and not the lib folder.
What's the proper way to utilize OpenMP in Clang under Windows? The clang-cl driver doesn't work with /openmp or -openmp as the MSVC's cl compiler.
Answer: Currently it can be done either with clang -fopenmp ..., clang-cl -Xclang -fopenmp ... or clang-cl /clang:-fopenmp ... (Which is equivalent of -Xclang -fopenmp).
Remark
On Windows I use Windows Driver of Clang using clang-cl.
Adding clarity to what the OpenMP libraries actually are, and how to use them on Windows with clang-cl
libomp.dll and libiomp5md.dll ARE THE SAME FILES!
When compiling for Windows, you link against libomp.lib OR libiomp5md.lib which will link to the same-named DLL at runtime, i.e. libomp.dll OR libiomp5md.dll respectively.
If you load 2 files that use the "different-name DLL," the interpreter will crash and give you a nasty error like: OMP: Error #15: Initializing libiomp5md.dll, but found libomp.dll already initialized.
Why? Because the program has no idea they are the same DLL, they have different names, so it assumes they are different. And it crashes. For this reason only, you can choose to swap which OpenMP DLL you link to in your program.
If your program doesn't crash and give you an error, you can keep using the same link to OpenMP. Otherwise, to silence the error, link to the one that is loaded by another program already.
If using clang-cl.exe which is the "drop-in" Clang replacement for MSVC cl.exe you should pass a compiler argument such as -Xclang -fopenmp which will convert the argument over to "Clang language." Don't forget to still pass to the linker the OpenMP LIB you chose, because on Windows, it won't be automatic.
That's all I've learned as brief as possible about OpenMP linking on Windows.
To compile and link OpenMP code with clang on Windows, you will have to pass -fopenmp to both the compiler and the linker:
clang -fopenmp -o bla.obj -c bla.c
clang -fopenmp -o bla.exe bla.obj
I am currently trying to compile libxml2 on Solaris. When I run the ./configure script provided with the sources, the gcc and g++ compilers are automatically used. However, I would like to use cc and CC compilers. So I run :
./configure CC=cc CXX=CC
It works but then, when I run "make", I get some errors which prevent the libraries to be generated.
When gcc and g++ are used, everything goes well with no errors, so I was wondering: can I use the librairies generated with gcc/g++ the same way I would have used them if I had successively generated them with cc/CC?
What are the differences between a lib generated with cc and the same lib generated with gcc on Solaris?
You can use either the gcc or cc C compilers pretty much interchangeably.
You can mix the g++ and CC C++ compilers in certain ways, but only on x86 Solaris and if your CC compiler is new enough to have the -compat=g option available.
The GNU g++ and the Solaris Studio CC C++ compilers default to completely different ABIs and C++ run-time libraries. On x86 Solaris platforms, newer versions (since version 12.?, if I remember correctly) provide a -compat=g option to use the g++ ABI and run-time libraries. The Studio 12.4 CC compiler adds a -std=v option to select different versions of the g++ or Sun C++ ABI and run-time libraries:
c++03 (zero-3, not oh-3)
Equivalent to the -compat=g option. It selects C++ 03 dialect and g++ ABI; it is binary compatible with g++ on Solaris and Linux It
sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++11
Selects C++ 11 dialect and g++ binary compatibility. It sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++0x (zero-x, not oh-x)
Equivalent to c++11.
and
The -std=c++03 provides compatibility with the gcc/g++ compiler on
all Oracle Solaris and Linux platforms.
With -std=c++03, binary compatibility extends only to shared
(dynamic or .so) libraries, not to individual .o files or archive (.a)
libraries. The gcc headers and libraries used are those provided with
the compiler, rather than the version of gcc installed on the system.
Note that the Studio 12.4 CC compiler uses the g++ headers and libraries supplied bundled with the CC compiler itself. 12.3 and earlier use the g++ headers and libraries installed on the system under /usr/sfw.
On SPARC Solaris, you have to use either g++ or CC for the entire application.
I am compiling a third-part software, with mpif90, that in my case is the mpi version of gcc. The package comes with a makefile. After compiling the object files, the makefile creates the archive with ar, but this fails because there are not input object files. In effect I tried to compile by hand the object files (.o) with
mpif90 -lmkl_gf -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -openmp -O3 -DMPI -c a.f90
and the a.o is not created, a .mod file is created instead. I don't have much experience with fortran, and I am a bit puzzled, because the -c flag should create an object, shouldn' it?
I have verified that gfortran does create the object file if I remove the flag openmp
Notes:
mpif90 -v
gcc version 4.4.3
OS : Ubuntu 10.04.4 LTS
I changed the flag openmp to fopenmp
http://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
In case anyone comes across this question in the future ... the flags used by the OP are specific to the intel fortran compiler while it seems the mpif90 wrapper is using the gfortran compiler. The proper flag to use OpenMP with gfortran is -fopenmp and the library is -lgomp. It is possible to use the intel library with a different vendors compiler, but its easiest to stick with one vendor.
I have learned to compile my own source over the years but always left some of the process to "mystery". I'm running into a bitch of a time getting ImageMagick and its myriad dependencies to work correctly on a PowerPC Mac OS X Server.
In setting flags for ./compile where does one typically uncover the various options (flags) that can be set and the descriptions of what each does?!?
For example, in the case of libwmf I'm using:
./configure --without-expat --with-xml --with-png=/usr/X11
...but not really knowing what each flag does. Now I'm having a png compatibility problem and want to find out why --with-png=/usr/X11 flag is being specified in install script I'm following...but can't find any documentation, etc. Any help?
Even a general response of how the UNIX Guru approaches this problem would be helpful.
./configure --help will give you the list of options that a configure script supports. To find out details about each option or the arguments you have to supply in particular cases, you will have to read the installation documentation of the particular package, if it has one. There are certain conventions that you will pick up over time, but they are just conventions. If you build a rather complicated package such as ImageMagick that pulls in dozens of library dependencies, and you use a less-than-common platform such as Mac with hand-compiled stuff, you might really have to dig deep and hard in some cases.
On my Mac, /usr/X11/lib contains a lot of libraries, including libpng.dylib and libpng.3.44.0.dylib in particular. Do you have those libraries? If not, you need to get X11 installed onto your Mac, and things are likely to go more smoothly.
MacOS X for Intel
I've downloaded ImageMagick 6.6.9-9 and configured, built and checked (but not installed) it with minimal issues. I have XCode 4 on my machine - and the only special option I used with ./configure was:
CC=/usr/bin/gcc ./configure
to ensure it picked up the system-provided GCC (4.2.1), not my private version of GCC 4.6.0. (A configuration test failed - for the sizeof(off_t) - because of a library issue. Using the system C compiler avoided that problem.) The ImageMagick configuration printed out:
ImageMagick is configured as follows. Please verify that this configuration
matches your expectations.
Host system type: x86_64-apple-darwin10.7.0
Build system type: x86_64-apple-darwin10.7.0
Option Value
-------------------------------------------------------------------------------
Shared libraries --enable-shared=yes yes
Static libraries --enable-static=yes yes
Module support --with-modules=no no
GNU ld --with-gnu-ld=no no
Quantum depth --with-quantum-depth=16 16
High Dynamic Range Imagery
--enable-hdri=no no
Delegate Configuration:
BZLIB --with-bzlib=yes yes
Autotrace --with-autotrace=no no
Dejavu fonts --with-dejavu-font-dir=default none
DJVU --with-djvu=yes no
DPS --with-dps=yes no
FFTW --with-fftw=yes no
FlashPIX --with-fpx=yes no
FontConfig --with-fontconfig=yes no
FreeType --with-freetype=yes yes
GhostPCL None pcl6 (unknown)
GhostXPS None gxps (unknown)
Ghostscript None gs (unknown)
Ghostscript fonts --with-gs-font-dir=default none
Ghostscript lib --with-gslib=no no
Graphviz --with-gvc=yes no
JBIG --with-jbig=yes no
JPEG v1 --with-jpeg=yes no (failed tests)
JPEG-2000 --with-jp2=yes no
LCMS v1 --with-lcms=yes no
LCMS v2 --with-lcms2=yes no
LQR --with-lqr=yes no
LZMA --with-lzma=yes no
Magick++ --with-magick-plus-plus=yes yes
OpenEXR --with-openexr=yes no
PERL --with-perl=no no
PNG --with-png=yes yes
RSVG --with-rsvg=yes no
TIFF --with-tiff=yes no
WEBP --with-webp=yes no
Windows fonts --with-windows-font-dir= none
WMF --with-wmf=yes no
X11 --with-x= yes
XML --with-xml=yes yes
ZLIB --with-zlib=yes yes
X11 Configuration:
X_CFLAGS =
X_PRE_LIBS = -lSM -lICE
X_LIBS = -L/usr/X11/lib -R/usr/X11/lib
X_EXTRA_LIBS =
Options used to compile and link:
PREFIX = /usr/local
EXEC-PREFIX = /usr/local
VERSION = 6.6.9
CC = /usr/bin/gcc -std=gnu99 -std=gnu99
CFLAGS = -D_THREAD_SAFE -D_THREAD_SAFE -pthread -fopenmp -g -O2 -Wall -D_THREAD_SAFE -pthread
CPPFLAGS = -I/usr/local/include/ImageMagick
PCFLAGS = -fopenmp
DEFS = -DHAVE_CONFIG_H
LDFLAGS = -L/usr/X11/lib -R/usr/X11/lib
MAGICK_LDFLAGS = -L/usr/local/lib -L/usr/X11/lib -R/usr/X11/lib
LIBS = -lMagickCore -lfreetype -lpng -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm -lgomp -lclparser -Wl,-framework,OpenCL -L/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries -lm -lpthread
CXX = g++
CXXFLAGS = -g -O2 -D_THREAD_SAFE -pthread
FEATURES = OpenMP
Some of the tests failed - I expect that was because I was not actually running an X11 server on the machine at the time. I'm not immediately going to investigate - you are running into problems at a much earlier stage.
MacOS X for PowerPC
As you can see, this is for Snow Leopard (10.6.7) on Intel x86/64. If you are running with Leopard (10.5.x) on PowerPC, you probably have an older XCode and libraries etc, but it would be surprising if the configuration process does not work if you have the XCode on the machine - and X11 installed.
Addressing your question about the flags in the invocation:
./configure --without-expat --with-xml --with-png=/usr/X11
In general, you cannot be certain what each flag does because the
maintainer of the package is completely free to have the flags do whatever
they want. There are certain conventions, but many are not well
understood by the package maintainers so you cannot fully rely on them.
Generally, the --with and --without are simply used to determine
what features to compile in. For example, if you do not have libexpat
installed, you can set --without-expat to complete the build which would otherwise fail.
One would suspect that the default for the package is to attempt
to build with certain features that require libexpat, and the
configury will fail if libexpat is not present, so you set
--without-expat to turn off those features.
The --with-png option with an argument is, IMO, a completely
untrustworthy kludge. I've never seen a package where it
actually works. Typically, all the configure script does
is take your /usr/X11 argument and add it (with "-L"
prepended) to LDFLAGS. The idea is that this will cause
the linker to use /usr/X11/libpng.so and not some other
version of libpng, but the simple fact is that if you
have libpng somewhere else on your system and that other
location is in your LDFLAGS, it will be used. In other
words, if you have /usr/lib/foo.so and /usr/lib/bar.so
and /usr/other/lib/foo.so and /usr/other/lib/bar.so,
there is simply no way to use /usr/lib/foo.so and /usr/lib/other/bar.so
short of deleting one of the libraries. Rather than specifying
a path as an argument to --with-png, you are probably better
off doing "--with-png LDFLAGS='-L/path -L/path2'", or just
ensure that your system is built so that the desired paths are
searched by the linker. (eg, specify the paths in /etc/ld.so.conf
or in /etc/ld.so.conf.d)