I want to link libstdc++ statically on Mac OS X 10.8.4 so that the binary can be used in other systems.
I found some discussion for linux. I'm wondering what would the instructions for Mac OS X.
http://www.trilithium.com/johan/2005/06/static-libstdc/
I have the following GCC.
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I don't know if the gcc 4.2.1 that you have supports this method, but here's what worked for me in a similar situation on OS X 10.9:
upgrade to the latest Xcode command line tools (I have 5.0.1.0.1.1382131676)
install Homebrew
brew tap versions
brew install gcc48
then configure/build your software with:
CC=gcc-4.8 CXX=g++-4.8 LDFLAGS="-static-libgcc -static-libstdc++"
The static flags were available for me in this gcc 4.8 build by Homebrew, and the resulting executables looked like:
$ otool -L seqdb-compress
seqdb-compress:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
with no libgcc or libstdc++ dynamic libs. I haven't yet tested these executables out on a different OS X system but will update this post if they don't work for any reason.
Related
I installed the Code::Blocks on a Windows 10 PC using the downloaded binary codeblocks-20.03-setup.exe. I adjusted the settings to point to my Msys2 MinGW compiler C:\msys64\mingw64 and debugger C:\msys64\usr\bin\gdb.exe. I then created a project with the default console app in c using Code::Blocks. It can compile and run using Code::Blocks.
When I debug it it fails. Code::Blocks gives an error:
Cannot open file: /c/GitLab/debugging-c-code/Exercise Files/Ch02/02_01/02_02_ide/main.c
At /c/GitLab/debugging-c-code/Exercise Files/Ch02/02_01/02_02_ide/main.c:6
The main.c file is open in Code::Blocks. I assume the /c/ vs c:\ part is the problem. I have no idea how to resolve the problem for Code::Blocks.
My Setup:
[..]which gcc
gcc is an external : C:\msys64\usr\bin\gcc.exe
[...]gcc --version
gcc (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]which gdb
gdb is an external : C:\msys64\usr\bin\gdb.exe
[...]gdb --version
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
I solved the problem ... after reading the comment from HolyBlackCat. Cygwin will mangle paths because it assumes it is inside the Cygwin environment.
Updated my MSYS installation and installed GDB as part of a complete toolchain:
pacman -S mingw-w64-x86_64-toolchain
Now GDB, GCC and Codeblocks are happy with each other and sharing debug information in a way that everybody understands. Now both GDB and GCC reside in C:\msys64\mingw64.
I originally only installed only GCC and then the other parts as I needed them.
Make sure you don't have any special characters (spaces, non ASCII characters) in the paths where CodeBlocks, MinGW-w64 or your source projects are located.
More info on how you can configure CodeBlocks with MinGW-w64 can be found here: https://winlibs.com/#usage-codeblocks
I am using libmicrohttpd 0.9.53 in my project and decided to update it to the latest version (0.9.71). I am cross-compiling for ARM and this is the output of arm-linux-gcc --version:
arm-linux-gcc (4.4.4_09.06.2010) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and the output of /lib/arm-linux-gnueabi/libc.so.6:
GNU C Library (Debian GLIBC 2.19-18+deb8u3) stable release version 2.19, by Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.8.4.
Compiled on a Linux 3.16.7 system on 2016-02-12.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
The compilation is successful, however, I get these errors when linking with the shared library:
arm-linux-gcc -Llib/libmicrohttpd/lib -Wl,-rpath,./lib -o "proj" build/src/proj.o -lpthread -lm -lmicrohttpd
lib/libmicrohttpd/lib/libmicrohttpd.so: undefined reference to `pthread_setname_np#GLIBC_2.12'
lib/libmicrohttpd/lib/libmicrohttpd.so: undefined reference to `clock_gettime#GLIBC_2.17'
collect2: ld returned 1 exit status
make: *** [makefile:191: proj] Error 1
On the target machine, I ran /lib/arm-linux-gnueabi/libc.so.6 | grep clock_gettime:
782: 000e48e4 116 FUNC GLOBAL DEFAULT 12 __clock_gettime##GLIBC_PRIVATE
1625: 000e48e4 116 FUNC WEAK DEFAULT 12 clock_gettime##GLIBC_2.17
And readelf -Ws /lib/arm-linux-gnueabi/libc.so.6 | grep pthread_setname gives no result.
Apparently, the two symbols mentioned in the error have been added between the old and new releases and it seems like my current version of libc does not define them.
Am I completely off track here? Do I have to somehow update libc? Could you please suggest anything that could point me to the right direction?
It looks like your toolchain defaults -Wl,--as-needed. In this case, link order matters even for shared objects.
Try replacing -lpthread -lm -lmicrohttpd with this:
-lm -lmicrohttpd -lpthread
The clock_gettime#GLIBC_2.17 problem requires a rebuild with the version of glibc in your cross-build environment. It seems it was compiled on the target system (which has glibc 2.19, per your question), but it could have been built against any version that has clock_gettime in libc.so.6, starting with glibc 2.17. Your cross-compilation environment has a glibc version prior to that change (so glibc 2.16 or earlier), so it does not recognize the clock_gettime#GLIBC_2.17 symbol version.
I am trying to build a bare metal arm project. I tried the GNU toolchains arm-elf and arm-none-eabi. Executables generated by both toolchains, when converted to intel hex format, runs fine.
I am using the software Proteus for simulation. Proteus supports debugging executables in both elf and coff format.
In my case Proteus accepts the executable generated by arm-elf but its showing error when loading the executable generated by arm-none-eabi. The error message shown by Proteus is:
I just ran the file command in linux with the two executables as argument, one by one.
The results are shown below.
arm-none-eabi output
image: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
arm-elf output
image: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
Is there any option to generate Proteus compatible elf file using arm-none-eabi toolchain?
Edit:
Details of my tollchains' versions.
C:\SysGCC\arm-elf\bin>arm-elf-gcc.exe --version
arm-elf-gcc.exe (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\SysGCC\arm-elf\bin>arm-elf-as.exe --version
GNU assembler (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-elf'.
sreeyesh#ITP-PTLX118:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:4.9.3+svn227297-1) 4.9.3 20150529 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
sreeyesh#ITP-PTLX118:~$ arm-none-eabi-as --version
GNU assembler (2.25-10ubuntu1+5build1) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
Thanks in advance.
I finally found out the solution for the issue. I noticed that, in Proteus, there is an option to configure the toolchain and build the source code from Proteus itself.
I just did the following things in Proteus
Selected GNU ARM toolchain from the list of supported compilers
Configured the toolchain path to point to my arm-none-eabi toolchain.
Created a new project with an empty main function.
Built the project.
The build was successful and more interestingly I could debug the generated executable.
Proteus logs the build commands. When I analyzed the logs, I noticed that some extra options were being used by Proteus when invoking arm-none-eabi-gcc. I experimented with those extra options and finally found out that the option -gdwarf-2 plays the key role.
I updated my makefile with this option and it worked fine.
This option simply enables DWARF version 2 format, That's all that I understood from the web search. But why the arm-elf toolchain worked without this option is still a question in my mind. Maybe, this option is enabled in arm-elf by default.
Anyway I am satisfied with this finding as I can proceed with my work now.
Thanks to all those who spared their precious time to help me out. Hope this finding will help people experimenting with Proteus simulation using the GNU ARM toolchain.
I'm trying to debug libc on Ubuntu 14.04 but unable to do so using gdb as the library and the source are not matching correctly.
gdb is unable to place the break point correctly. As in, I'm able to step into a function and see the source code but the break point marker would be at some random place inside the function instead of being at the beginning.
When I proceed statement by statement using next on gdb, the marker would keep jumping up and down (Reason being the source file and debug library are not matching correctly.
My glibc version according to ldd is
ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.6) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
I've downloaded libc sources using the command:
sudo apt-get source libc6
The above would create the following files:
eglibc-2.19
eglibc_2.19-0ubuntu6.6.debian.tar.xz
eglibc_2.19-0ubuntu6.6.dsc
eglibc_2.19.orig.tar.xz
In gdb I'm doing
dir <path-to-libc-source>/nptl (nptl because I'm stepping into pthread_create)
I've tried using both eglibc-2.19 source as well as eglibc_2.19.orig.tar.xz.
I've also tried setting LD_LIBRARY_PATH: export LD_LIBRARY_PATH=/usr/lib/debug
But the above also doesn't help.
Can somebody who has successfully been able to debug libc code share his/her techniques as to how to do it correctly?
Assuming the source code version and the library version are the same....
The root cause of the 'jumping' is due to the compiler optimization often changes the order of the executable code from the order in the source file.
This happens when the code is compiled with any of the optimization parameters.
I'm new to Homebrew (I usually use Macports, but I'm trying out Homebrew on a 2nd computer), and I wish to install the openmpi (or mpich2) package. Steps are as follows (carried out on Mac OS X Yosemite with Xcode 6 installed):
brew install gcc
brew install openmpi
However, I suspect the linking may have been done incorrectly, due to the following reasons:
The symbolic link for /usr/local/bin/gcc is missing:
$ which gcc
/usr/bin/gcc
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
$ which gcc-4.9
/usr/local/bin/gcc-4.9
$ gcc-4.9 --version
gcc-4.9 (Homebrew gcc 4.9.2) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mpicc may have been linked to the Apple gcc:
$ which mpicc
/usr/local/bin/mpicc
$ mpicc --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
My questions are as follows:
How do I get the /usr/local/bin/gcc symbolic link? Or is Homebrew deliberately avoiding this for certain reasons? e.g. if Homebrew is compiling all its packages using Apple gcc, which is assumed to be in the path, would changing the path to gcc-4.9 mean that Homebrew now compiles its packages with gcc-4.9 instead?
Is the Homebrew-installed Open MPI linked to the Apple gcc (and not the Homebrew gcc)? If yes, is it possible (or advisable) to change the linking?
Alternatively, how necessary is it to fix the linkages? Could I run into certain problems if I choose not to fix it? For example, I'm considering using ln -s to forcibly create the /usr/local/bin/gcc symbolic link. But is this a good idea (*)?
(*) I understand there are likely to be issues when linking object files created by different compilers. So with (1), (2) and (3), I'm hoping to find a solution that avoids combinations whereby I'm creating object files with different compilers (some with gcc-4.9 and some with the Apple gcc).
You need to do the following:
1) Add environment variables for homebrew (you can also add these lines to your ~\.bashrc):
$ export HOMEBREW_CC=gcc-4.9
$ export HOMEBREW_CXX=g++-4.9
2) Rebuild and reinstall openmpi and its dependencies from source
$ brew reinstall openmpi --build-from-source
3) In the end you will get a message like:
==> Reinstalling open-mpi
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.
==> Downloading http://www.open-mpi.org/software/ompi/v1.8/downloads/openmpi-1.8.
Already downloaded: /Library/Caches/Homebrew/open-mpi-1.8.4.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/open-mpi/1.8.4 --disable-silent-rules
==> make all
==> make check
==> make install
Warning: open-mpi dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.
🍺 /usr/local/Cellar/open-mpi/1.8.4: 785 files, 23M, built in 41.2 minutes
$ mpicc --showme
gcc-4.9 -I/usr/local/Cellar/open-mpi/1.8.4/include -L/usr/local/opt/libevent/lib -L/usr/local/Cellar/open-mpi/1.8.4/lib -lmpi
On my MacBook I had some conflicts with XCode 6.2, which were solved following this instructions
If you want to install mpich
$ unlink openmpi
$ brew unlink gcc
$ brew install homebrew/versions/gcc5
$ brew install mpich --build-from-source
$ mpicc -v
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc5/5.4.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.4.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0 --prefix=/usr/local/Cellar/gcc5/5.4.0 --libdir=/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl014 --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc5 5.4.0' --with-bugurl=https://github.com/Homebrew/homebrew-versions/issues --enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 5.4.0 (Homebrew gcc5 5.4.0)
It would probably be cleaner if you simply modify the configuration file for the Open MPI compiler wrapper and make it invoke gcc-4.9 instead of simply gcc. As I have no idea where exactly Homebrew puts Open MPI and therefore cannot give you the correct path directly, you should search for it:
$ find /usr/local -name mpicc-wrapper-data.txt
Once you have found mpicc-wrapper-data.txt, find the line that starts with compiler= and modify it to read:
compiler=gcc-4.9
You should also modify all other files that match the shell glob mpi*-wrapper-data.txt and modify the compiler=... line accordingly. Use g++-4.9 in mpic++, mpicxx, and mpiCC. Use gfortran-4.9 (if installed) in mpif77 and mpif90 (for Open MPI versions < 1.8) or for mpifort (for versions >= 1.8).
Mixing object code produced by different compilers on the same platform should be fine as long as all of them adhere to the same ABI, which is more or less the case with Clang and GCC. In the end, all programs are linked against the system libraries that come with OS X and those are compiled with Clang only.