I used to build a project on windows and now that I am trying to build it on macos (M1) I get errors on a dependency (nested in a dependency):
pixman-0.34.0/pixman/pixman-x86.c:103:4: error: unknown register name '%eax' in asm
: "%eax", "%ecx");
^
pixman-0.34.0/pixman/pixman-x86.c:136:4: error: invalid output constraint '=a' in asm
: "=a" (*a), "=r" (*b), "=c" (*c), "=d" (*d)
^
I also get warnings all around:
pixman-0.34.0/pixman/pixman-x86.c:83:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
#if _PIXMAN_X86_64 || defined (_MSC_VER) || defined(__native_client__)
^
pixman-0.34.0/pixman/pixman-x86.c:78:6: note: expanded from macro '_PIXMAN_X86_64'
(defined(__amd64__) || defined(__x86_64__) || defined(_M_AMD64))
^
The project is configured with CMake with very few parameters, most of the configuration is made in the CMake of the dependency (Orthanc Stone).
There is an emscripten build of almost the same sources and libs that is working fine so I guess I'm missing something in the CMake configuration to make it work on macos.
I suppose the target architecture is not compatible with the pixman lib (and probably others that the compilation has not reached yet). But I did not find how to fix it.
I installed gcc using homebrew
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.3.0/bin/../libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.3.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.3.0)
The project is configured with CMake with very few parameters, most of the configuration is made in the CMake of the dependency (Orthanc).
Is it this Orthanc? How exactly are they building pixman with CMake? Pixman has lots of special cases implemented in Assembler. At build time, autoconf detects the right one to enable. Since you are writing that you are using CMake, I bet someone side-stepped all that auto-detection and just hardcoded what to build. And hardcoded the x86 build.
If this guess is right, then that is a bug in that CMake file and there is nothing anyone but orthanc devs can do about that.
Which part of orthanc are you trying to build exactly and how? I fail to find its use of cairo...
Related
I need to run a dotnet5 app (or build dotnet5 from source) to be compatible with arm machines with very old glibc (as low as glibc-2.13, cannot be upgraded because these are semi-embedded systems).
The target machines come with libstdc++ based on gcc <5.1 and therefore don't support the necessary C++11 ABI.
First solution was to "just" get an arm-binary libstdc++.so.6.0.21 from somewhere and trying to run the app with it (via LD_LIBRARY_PATH). This almost worked, but this libstdc++ depended on glibc-2.16.
Next solution: build gcc >=5.1 (including libstdc++) from source in my debian-wheezy-armhf container, which is based on glibc-2.13.
This works quite well, though I have to force a few things because the gcc build process at some stages seems to believe it's cross-building (but not really?), getting errors like this: cannot find bits/predefs.h and hard- vs. soft-float errors. These were solved by doing the build like this (Makefile rule executed in build container):
C_INCLUDE_PATH=/usr/include:/usr/include/$$(gcc -print-multiarch); \
CPATH=/usr/include:/usr/include/$$(gcc -print-multiarch); \
LIBRARY_PATH=/usr/lib:/usr/lib/$$(gcc -print-multiarch); \
CFLAGS="-mfloat-abi=hard"; \
CXXFLAGS="-mfloat-abi=hard"; \
LDFLAGS="-mfloat-abi=hard"; \
export LIBRARY_PATH C_INCLUDE_PATH CPATH CFLAGS CXXFLAGS LDFLAGS; \
../gcc-5.5.0/configure --enable-languages=c,c++ --enable-shared=libgcc,libstdc++ `#--build=$$(gcc -print-multiarch)` --disable-multilib --disable-bootstrap --prefix=/build/install \
&& make -j24 && make install
... but the resulting libstdc++ doesn't contain version symbols:
> objdump -p .build/arm-glibc2.13/install/lib/libstdc++.so.6.0.21 | grep GLIBCXX
# nothing
/build/gcc-5.5.0-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/config.log shows:
configure:78121: WARNING: === You have requested GNU symbol versioning, but
configure:78123: WARNING: === you are not building a shared libgcc_s.
configure:78125: WARNING: === Symbol versioning will be disabled.
so that appears to be the reason. But why am I not building a shared libgcc_s? Even with --enable-shared=libgcc,libstdc++ (which is supposed to be the default anyway) it doesn't work...
Any ideas?
I'm trying to see if it's possible to use a gcc plugin in an ARM cross compiler (arm-none-eabi-gcc). I'm running into compiler errors however, and am questioning whether what I'm trying to do is possible.
The plugin I'm trying to set up is: https://github.com/vanhauser-thc/AFLplusplus/tree/master/gcc_plugin
I'm compiling the plugin on x86-64 linux using the -m32 flag, since the cross compiler is a 32-bit application. However when I try to use the plugin in the cross compiler using -fplugin , I get an undefined symbol compiler error:
cc1plus: error: cannot load plugin ../afl-gcc-pass.so
../afl-gcc-pass.so: undefined symbol: _Z13build_int_cstP9tree_nodel
I looked through the plugin's symbols using nm and discovered that the majority of symbols are undefined, including ones like exit and random. I'm new to most of this and am unsure of what that really means. Some searching online suggested that it may have had something to do with incorrect library paths, but setting LIBRARY_PATH and LD_LIBRARY_PATH and rebuilding did not seem to help.
The gcc version set-ups I have tried:
1: x86: 5.4.0 , arm: 5.4.1 on ubuntu 16.04
2: x86: 5.2.0 , arm: 5.2.1 on CentOS 6.8
Is it possible to use a gcc plugin in a different gcc than it was compiled with or am I wasting my time?
Yes, it is possible to build a gcc plugin with a given compiler and then use the plugin in another compiler (including a cross-compiler), but you have to make sure you include the right header files when building the plugin.
Specifically, you have to include the plugin development header files of the target compiler, instead of those of the host compiler. The directory where plugin development files for your target compiler are located can be obtained with the following command:
$(TARGET_CC) -print-file-name=plugin
where $(TARGET_CC) is your target compiler. So a concise way to specify the relevant include directory in the compiler flags when building the plugin would be something like -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include".
For the specific plugin you are trying to use (instrumentation for afl-fuzz), in order to build the plugin for your cross-compiler you could modify the Makefile in the gcc_plugin folder; more specifically, you could define a TARGET_CC variable containing the path to your cross-compiler, and then replace $(CC) with $(TARGET_CC) in the definition of PLUGIN_FLAGS, as in:
PLUGIN_FLAGS = -fPIC -fno-rtti -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include"
You will also have to comment out the commands executed in the test_build Makefile target, because those commands would try to use the plugin with the native compiler and so would fail.
Then, you will be able to use the plugin with your cross-compiler, as in:
arm-none-eabi-gcc -fplugin=../afl-gcc-pass.so --specs=nosys.specs my_source_file.c
So after searching the web for a while, Ive decided to try here as it seems to be a good forum for discussion. Im trying to create a simple gcc plugin. The program code is attached in the end of this mail, but in plain english it registers the plugin and makes sure that the pragma_init function is called when pragmas are registered. It is here that I use c_register_pragma to intercept some of the pragmas.
I compile it using the example in http://gcc.gnu.org/onlinedocs/gccint/Plugins-building.html#Plugins-building. The compilation and linking works fine. However, when I load the plug-in I get:
gcc -c -fplugin=plugin.so test.c -o test.o
cc1: error: cannot load plugin plugin.so
plugin.so: undefined symbol: warning
What am I doing wrong? In addition, when including some header files (that will be required later), I get a lot of errors. For example, including "tree.h" yields (amongst 50 other errors):
/machmode.h:262:1: error: unknown type name 'class'
class bit_field_mode_iterator
^
/machmode.h:263:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
{
^
/plugin/include/tree.h:27:0,
from conftest.c:63:
/vec.h:220:8: error: field 'register_overhead' declared as a function
Anyone have a clue on what I am doing wrong?
Thank you
There are two problems here :
The error : "cannot load plugin plugin.so" means that you should add to your LD_LIBRARY_PATH the directory where you store your new shared library plugin.
The hundreds of errors you got with all the files in the include are resolved in my computer if you compile with g++ instead of gcc (not sure to understand why thought)
Which version of GCC are you using, both to compile your plugin, and to use the plugin? Run simply
gcc -v
without any other program argument to find out!
Did you install the appropriate package for GCC plugin development (on Debian or Ubuntu, it might be gcc-4.7-plugin-dev, but adapt the 4.7 version to your particular version of GCC)?
Did you install all the dependencies needed to build your GCC (on Debian or Ubuntu, apt-get build-dep gcc-4.7 gcc-4.7-plugin-dev)?
Recent versions of GCC (notably many GCC 4.7 shipped by distributions, and all GCC 4.8) are compiled by a C++ compiler, not a C compiler.
You may check how was your GCC built (in C or in C++) by running
nm -D -C $(gcc -print-file-name=cc1)
If that command shows typed C++ manged names, e.g. execute_ipa_pass_list(opt_pass*) instead of just execute_ipa_pass_list your GCC has been compiled with a C++ compiler (probably g++)
So you may need to use g++ (not gcc) to compile your GCC plugin.
As I commented, did you consider using MELT (a domain specific language to extend GCC) to extend or customize your gcc compiler?
I suggest downloading the very latest http://gcc-melt.org/melt-plugin-snapshot.tar.bz2 since I will release the next MELT in a few weeks for GCC 4.7 and 4.8
And don't expect to change the parsing behavior of your GCC with a plugin. That is not really possible (GCC provides only plugin hooks to add your builtins and pragmas, not to extend the parsed syntax).
I want to use newlib instead of glibc in order to compile small static binaries. (I do not intend to cross-compile as the binaries are to be used by the same computer.) I believe that I need to compile a separate gcc for this ?
I compiled gcc:
./configure --prefix=/home/myuser/Desktop/gcc-4.4.5 --libexecdir=/home/myuser/Desktop/gcc-4.4.5 --libdir=/home/myuser/Desktop/gcc-4.4.5 --with-gxx-include-dir=/home/myuser/Desktop/gcc-4.4.5 --enable-languages=c --enable-libmudflap --disable-multilib --disable-libssp --disable-nls --with-newlib --with-gnu-as --with-gnu-ld --with-system-zlib
make
It compiled without errors but now when I try to compile a simple Hello World! program it wants to use headers from /usr instead of the path I specified above. These are some of the errors:
In file included from /home/myprogram/Desktop/myprogram.c:1:
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from /home/myprogram/Desktop/myprogram.c:1:
/usr/include/libio.h:53:21: error: stdarg.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from /home/myprogram/Desktop/myprogram.c:1:
/usr/include/libio.h:332: error: expected specifier-qualifier-list before 'size_t'
/usr/include/libio.h:364: error: expected declaration specifiers or '...' before 'size_t'
/usr/include/libio.h:373: error: expected declaration specifiers or '...' before 'size_t'
What am I doing wrong ? Is compiling a new gcc necessary or can I use my existing gcc and use newlib instead of glibc ???
You shouldn't need to rebuild gcc for this; you just need to point your existing gcc at the right things (using -I, -L etc.) and tell it not pull in the usual system stuff (using -nostdlib).
The section entitled "Shared newlib" in the newlib README file has runes for building and linking against either shared or static newlib when compiled natively.
I would strongly recommend using crosstool-ng to build your GCC toolchain. If you choose x86 followed by "bare metal" as the operating system, you can safely use newlib as a libc.
Note that newlib does not work with an operating system - that is standard things, like IO, won't work out of the box.
You have to tell the compiler where it can find the include files:
gcc -IyourDirectoryHere -IanotherDirectoryHere
-I
(that is a minus followed by a capital i as in Italy)
More details: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Directory-Options.html
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package