I would want to run sed 's/#line/\/\/#line/' on some particular docs in order to automate this solution to http://stackoverflow.com/questions/16512580/.
I would want that command to be ran by GNU Make automatically only when invoked from Xcode.
Can't just simply use uname -s detection of Darwin because a Homebrew only toolchain is to be maintained in parallel to the Xcode project configuration docs. It has to specifically detect Xcode somehow.
My Xcode right now is reported as Version 9.0 (9A235).
Got ideas?
It seems that you want to get rid of the #line generated by Bison. Then, pass it --no-lines (aka -l) or put %no-lines in the grammar file.
Strictly concerning the question of how to detect XCode in make, it seems that the answer would be to add a flag to the command-line (e.g., make XCODE=1) or to the environment. I don't think there is an automatic XCode-specific flag set to distinguish it from a Mac that is using otherwise the same tools.
For the specific case of getting rid of #line generated by Bison, it seems that this answer may be better. Or if neither of these is doable, I would seek to detect the undesired situation (e.g., with grep or awk) first rather than unconditionally running sed.
Related
I'm running MacOS Big Sur and trying to install valgrind for an assignment.
brew install valgrind doesn't currently work and installing from the tar.bz2 distribution doesn't either.
Running ./configure (according to the readme instructions) returns this at the end:
checking for a supported OS... ok (darwin20.1.0)
checking for the kernel version... unsupported (20.1.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)
Judging from that, looks like valgrind hasn't worked for the last couple of MacOS releases.
Is there an alternative for current MacOS releases or is this a good time for me to make a partition on my hard drive for Linux? Or am I missing something with installation?
As mentioned in the comments, Louis Brunner's github repo is your best bet at the moment. This should give you at least a minimally functional build.
Other than the usual version number changes, one of the big, breaking, changes in Big Sur is the fact that the system libraries are cached (and hidden) by dyld. So right now Valgrind is not able to read libsystem_malloc.dylib in order to determine the address of functions like malloc so that they can be redirected.
If anyone wants to take a stab at it, then my guess is that you will need to follow these instructions, and change initimg-darwin.c so that dyld_cache_value is "avoid".
For anyone else looking for an answer, you could use valgrind-macos, a fork of Valgrind on macOS, as recommended by PhillipMills. XCode also provides tools for leak checking.
However, if you don’t use XCode and don’t like the first option, you could try Address/Leak Sanitizer. The difference is that you’ll have to compile and link with one of the sanitizers, but that only requires an extra flag, i.e., -fsanitize=address. Note that Apple Clang doesn’t support leak checking, so you’ll have to grab llvm off Brew. Also, you need to prepend ASAN_OPTIONS=detect_leaks=1 before your executable.
I am trying to compile a C code on Oracle Linux 7.2 which is hosted as VM on windows 10.
Name of file run: configure
Name of log file: confg.log
Error where I am stuck
gcc: error: unrecognized command line option '-V'
As per my understanding of the code structure so far, there is a file named configure which is having compilation related commands and this file generates Makefile.am which further generates Makefile.in and at last Makefile.
Please help me in solving the error and also let me know if my understanding about the configure and makefiles is incorrect
configure scripts explore the environment in which a program is to be built. They then accordingly adjust tools called, options used and libraries linked, among other things. Some of the information is obtained by trying to execute programs with certain options; failure of a program to run is the intended way of obtaining the information that the given program is not available or does not take those options. Therefore it is not necessarily an error if one of the things doesn't work and produces an error; it may be one of the legitimate outcomes, and the (error, here) exit code of the compiler will be used to modify the Makefile accordingly — for example by omitting -V ;-).
Does the configure script actually stop there, or are you just observing the error in the log file? If you search for gcc -V on the web you'll find examples of configure scripts failing actually later (for unrelated reasons) which have the same "-V error" line in it. Could that be the case? I would assume that errors which actually cause configure to stop and not produce a Makefile should be visible on the command line, not only in the log file.
As an aside it is worthwhile to run ./configure --help and look through the options. Some may improve the build process or the result; for example you can usually tell configure that you are using gcc, gnu ld and so on, or that you don't need certain features (like X25 ;-) ).
You should look into the makefile of your project, identify where the misspelled -V option is and replace it with -v (lowercase). As pointed out by others in the comments -V is not a compiling flag, but gives back the compiler's version.
I am trying to build an alternative compilation suite on my debian-testing machine (sorry, real question is actually at bottom).
Technically it is a "cross-compilation" because I need to use this toolchain on another machine, but hardware is compatible (x86_64-unknown-linux-gnu) so I don't need to bother about build/host/target differencies.
On the other hand I do need to worry about prefix/sysroot because I cannot install in any standard location (to be more precise: I could install anywhere, since I have root access there, but I shouldn't); This leaves me with my $HOME, some completely non-standard place (e.g.: /usr/local/my/toolchain) or some semi-standard (e.g.: /opt) place. In any case I will need to do something to enable compilation to find includes and libs in such places and runtime linker to find needed .so.
My requirements are:
I have a running Linux that shouln't be messed with.
This system does not have a "C" compiler.
Said linux is BusyBox-based, so I will need a substantial amount of utilities to do any serious compiling there, including make, sed, awk, ..., beside the compiler proper.
I would be happy to stuff my augmented toolchain in /opt, but that is not a requirement; any place is ok as long as it's accessible by more than a single user, I would like ot avoid installing in $HOME.
I am aware of "optware", I installed it and it does work... up to a point. Unfortunately:
It's really old software
it's only 32bit (my system is Linux syno0 3.2.40 #5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU/Linux).
Some programs won't compile because provided libs have 32/64 mismatch.
Real motivation to do all this exercise is I need to install some perl modules needed for one application that will have to run there and to install them from cpan I need a native compiler (and other stuff, of course).
Similar arguments about a Ruby-on-rails application I should port there.
If at all possible I should try to use the "native" libs in /lib:/lib64:/usr/lib:/usr/lib64:/usr/lib32 ("static" .a libs are not available).
I had a limited success preparing a custom tarball from an available toolchain for my processor, relocating it to /opt, stuffing needed apps in its sysroot and compiling with: CPPFLAGS="-I/opt/include" and LDFLAGS="-L/opt/lib -Wl,-rpath -Wl,/opt/lib".
This enables me to build almost everything "LFS-style", but it's rather error-prone and 64-bit-only.
I seem to understand it should possible to automatize all this by a careful mix of --prefix, --with-sysroot, --with-native-system-header-dir, --enable-multilib and their friends.
I tried to understand exactly how they should be used and failed, for a reason or another. I didn't find any exhaustive documentation and information in GCC instalation docs are confusing me.
Can someone, please, give me a recipe to build this toolchain?
Any pointer to in-depth documentation welcome, but I suspect some tutoring will be necessary.
I assume recompilation of Binutils and GCC is mandatory, Glib is probably not needed; anything else can be recompiled "native" on target.
TiA
ZioByte
After installing your toolchain in nonstandard places you need to set environment(maybe system-wide) correctly for GCC using LIBRARY_PATH and C_INCLUDE_PATHor CPLUS_INCLUDE_PATH.
Environment Variables Affecting GCC
I see three ways to automate setting path variables for your relocatable toolchain:
on every relocation adding your GCC path to your PATH environment variable. And create alias in your busybox profile (usually /etc/profile)
alias example:
alias gcc='TOOLCHAIN_PREFIX=$(which gcc | rev | cut -d"/" -f3-10 |rev); \
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ gcc'
creating for your toolchain launcher-script that will calculate pathes, but you'll should launch it with direct path, setting it when you launch build process, or of course you can add its location to PATH environment varaible.
script example
#!/bin/sh
TOOLCHAIN_PREFIX=$(echo $0 | rev | cut -d"/" -f3-10 |rev);
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ \
$TOOLCHAIN_PREFIX/bin/gcc-4.*
The most reliable and ergonomic way — create install/uninstall script that will unpack and set environment correctly, to relocate toolchain you will uninstall from it from one prefix and install to another. If you have dpkg on your debian-testing system, .deb package is best choice.
I can see no way to set environment fully automatically. But we can reduce it to setting just one path — path of toolchain.
HINT* For better stability you should isolate your toolchain and also install in your prefix Linux Kernel headers and Glib
The following html link contains all the relevant bash command line records of the installation process. Thank you for help!
That was a bad question
I didn't use XCode through I know Xcode will make it easier! I use an Air, memory of 4GB currently.
If this won't work easily I probably will quit learning C or run and compile C on Windows. :(
And XCode stuff, whatever.
You command-line output indicates rather clearly that you aren't telling gcc what to compile, so it's throwing its hands up in exasperation:
$ gcc
i686-apple-darwin10-gcc-4.2.1: no input files
You'll need to specify the file you're compiling. Better yet, use an IDE, like Xcode.
<Shrug> What do you want us to say?
Obviousy Macports is trying to build/install gcc but it can't without a compiler. Yes gcc can be built without a preexisting compiler, but good luck and why? Especially when XCode is a free download, click click let it start and a little while later it's done. At that point as pointed out elsewhere, gcc, g++ will work, but it's not actually gcc but clang in disguise.
If you want, you can use macports or brew or whatever later if you really want to, but again why? For programs that only work using gcc extensions? Doubt it. You just want a c/c++ compiler. If you ever want to do programs for the Mac or IPhone, you need XCode anyway, gcc won't do.
I am playing around with a PXA270 Xscale development board (similar to the Gumstix), and was provided a cross compiler, but it is GCC 3.3.3. I would like to learn how to build my own cross compiler, so I can customize the setup, but have had trouble getting crosstools and crosstools-ng to successfully build a toolchain. My main needs are using GCC 4.2.X and the ability to use soft float. I am running Ubuntu 9. Does anyone have any recommendations or advice on building a toolchain for such a system?
Thanks in advance,
Ben
www.gnuarm.com has instructions for building your own ARM cross compiler as well as binaries available for download. They don't have GCC 4.2.x there, but I've built it using steps pretty similar to those instructions without too many problems.
Why do you want software floating point? It's going to be really slow; most applications only really need to use a fixed point implementation (read: integers).
Short answer, very difficult. Longer answer, keep trying, you may stumble upon it but likely not. Xscale with hard float is more likely and just dont use any floating point. I know I tried many combinations and failed. There is a reason why the combination you are looking for normally uses the older gcc, the last one to work. You might look at codesourcery to see what they have, using there tools or learning what they are up to is likely your best bet.
I used Dan Kegel's crosstool for creating my arm cross toolchain. It took a few tries, but I was eventually able to get it right.
I recommend reviewing the matrix of build results for various architectures to help determine a suitable combination of gcc, glibc, binutils, and linux kernel headers.
The following is the script that I used to create my arm cross toolchain. I realize that my requirements are a bit different that yours, but you may be able to modify it to suit your needs.
#!/bin/sh
set -ex
# Extract crosstool
tar zxf crosstool-0.43.tar.gz
ln -sf crosstool-0.43 crosstool
# Create .dat file for toolchain
cat << EOF > $HOME/arm-cross.dat
BINUTILS_DIR=binutils-2.15
GCC_DIR=gcc-3.4.5
GCC_EXTRA_CONFIG=--with-float=soft
GCC_LANGUAGES=c,c++
GLIBC_ADDON_OPTIONS==linuxthreads,
GLIBC_DIR=glibc-2.3.6
GLIBC_EXTRA_CONFIG=--without-fp
GDB_DIR=gdb-6.5
KERNELCONFIG="\$HOME/crosstool/arm.config"
LINUX_DIR=linux-2.6.12.6
LINUX_SANITIZED_HEADER_DIR=
SHARED_MODE=--enable-shared
TARGET=arm-softfloat-linux-gnu
TARGET_CFLAGS=-O
BUILD_DIR="\$HOME/crosstool/build/\$TARGET/\$GCC_DIR-\$GLIBC_DIR"
PREFIX="/usr/crossgnu/\$GCC_DIR-\$GLIBC_DIR/\$TARGET"
SRC_DIR="\$HOME/crosstool/build/\$TARGET/\$GCC_DIR-\$GLIBC_DIR"
TARBALLS_DIR="\$HOME/downloads"
TOP_DIR="\$HOME/crosstool"
EOF
# Create toolchain directory
sudo mkdir -p /usr/crossgnu
sudo chown $USER /usr/crossgnu
# Build toolchain
pushd crosstool
eval `cat $HOME/arm-cross.dat` sh all.sh --gdb --notest
popd
Note: I had the crosstool-0.43.tar.gz tarball in the same directory I ran the script from.
If you can't manage to build a crosscompiler using crosstool*, you're unlikely be able to do so without them. It is not straightforward!
However, you can most easily get recent cross-compilers onto Ubuntu by editing /etc/apt/sources.list to include
deb http://www.emdebian.org/debian/ lenny main
then saying
apt-get update
apt-get install g{cc,++}-4.3-arm-linux-gnueabi
I too used crosstool, and was able to build an arm-xscale-linux-gcc under Cygwin. The instructions are here: http://sourceforge.net/apps/mediawiki/imote2-linux/index.php?title=ToolsGccArm