Getting LD warnings on Mac OS X
Hello there! I am trying to compile GCC using Apple’s latest tools. The reason is that I am building an own, redistributable, toolchain. Everything goes quite well (except a ton of warnings about redeclarations and c99 standart), untill it tries to link cc1. A rough rip-off of the warnings is: ld: warning: ignoring file ../libcpp/libcpp.a, file was built for archive which is not the architecture being linked (x86_64): ../libcpp/libcpp.a ld: warning: ignoring file libbackend.a, file was built for archive which is not the architecture being linked (x86_64): libbackend.a ld: warning: ignoring file ../libdecnumber/libdecnumber.a, file was built for archive which is not the architecture being linked (x86_64): ../libdecnumber/libdecnumber.a ld: warning: ignoring file ../libbacktrace/.libs/libbacktrace.a, file was built for archive which is not the architecture being linked (x86_64): ../libbacktrace/.libs/libbacktrace.a ld: warning: ignoring file ../zlib/libz.a, file was built for archive which is not the architecture being linked (x86_64): ../zlib/libz.a Im attaching what I get on STDOUT and STDERR when re-running make after this happens. Specs: Mac OS X 10.9 Developer tools: Latest Version of GCC to compile: 4.8.2 Configuration flags: ../gcc-4.8.2/configure \ --quiet \ --build=x86_64-apple-darwin13.0.0 \ --host=x86_64-apple-darwin13.0.0 \ --target=x86_64-apple-darwin13.0.0 \ --x-includes=/opt/X11/include \ --x-libraries=/opt/X11/lib \ --with-mpfr=/opt/GNUstep \ --with-gmp=/opt/GNUstep \ --with-mpc=/opt/GNUstep \ --enable-objc-gc \ --prefix=/opt/GNUstep/ \ --disable-werror \ --enable-languages=c,objc,c++,obj-c++ Kind regards, Ingwie make.stderr Description: Binary data make.stdin Description: Binary data
4.8.2 fails at strip
Hey hey!
I have just tried to build a new GCC, and this time put the binutils folder
inside as well, because I simply needed newones as well. But when it is at
making the dynamic libraries, it suddenly does this:
for mlib in $MLIBS ; do \
/Users/Ingwie/Downloads/gcc-4.8.2-build/./binutils/strip-new -o
libgcc_ext.10.4.dylib_T${mlib} \
-R ../../../gcc-4.8.2/./libgcc/config/i386/libgcc-darwin.10.4.ver
-c -urx \
../${mlib}/libgcc/${mlib}/libgcc_s.dylib || exit 1 ; \
done
/Users/Ingwie/Downloads/gcc-4.8.2-build/./binutils/strip-new: invalid option --
c
Usage: /Users/Ingwie/Downloads/gcc-4.8.2-build/./binutils/strip-new
in-file(s)
Removes symbols and sections from files
The options are:
-I --input-target= Assume input file is in format
-O --output-target= Create an output file in format
-F --target=Set both input and output format to
-p --preserve-dates Copy modified/access timestamps to the output
-D --enable-deterministic-archives
Produce deterministic output when stripping
archives
-U --disable-deterministic-archives
Disable -D behavior (default)
-R --remove-section= Remove section from the output
-s --strip-all Remove all symbol and relocation information
-g -S -d --strip-debug Remove all debugging symbols & sections
--strip-dwo Remove all DWO sections
--strip-unneeded Remove all symbols not needed by relocations
--only-keep-debug Strip everything but the debug information
-N --strip-symbol= Do not copy symbol
-K --keep-symbol= Do not strip symbol
--keep-file-symbols Do not strip file symbol(s)
-w --wildcardPermit wildcard in symbol comparison
-x --discard-all Remove all non-global symbols
-X --discard-locals Remove any compiler-generated symbols
-v --verbose List all object files modified
-V --version Display this program's version number
-h --helpDisplay this output
--infoList object formats & architectures supported
-o Place stripped output into
/Users/Ingwie/Downloads/gcc-4.8.2-build/./binutils/strip-new: supported
targets: mach-o-x86-64 mach-o-i386 mach-o-le mach-o-be mach-o-fat pef pef-xlib
sym srec symbolsrec verilog tekhex binary ihex
make[3]: *** [libgcc_ext.10.4.dylib] Error 1
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
So the -c flag is not supported by the binutils I choose.
How can I get around this?
Kind regards, Ingwie
Re: Rename C files to .c in GCC source
> Am 30.01.2015 um 21:30 schrieb Jonny Grant : > > > > On 30/01/15 17:09, pins...@gmail.com wrote: >> >> >> >> >>> On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote: >>> >>> Hello >>> >>> When I checked out from the trunk I saw that various files had .C >>> capital extension. Its not a big issue.. but I wondered if they should >>> be .c like regular source files? >> >> No because they are c++ code so capital C is correct. > > Ok, I see. Only ever encountered files called .cpp. > > Regards, Jonny „Valid“ extensions happen to be .cpp, .cxx, .c++, .cc or .C. Although, .C can, in rare occasions, also speak about a pre-processed .c file. But finding this case is like searching a needle in a haystack. :)
Re: Rename C files to .c in GCC source
> Am 30.01.2015 um 22:39 schrieb DJ Delorie :
>
>
> pins...@gmail.com writes:
>> No because they are c++ code so capital C is correct.
>
> However, we should avoid relying on case-sensitive file systems
> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
> name character on Windows, so we can't use .c++).
Apple’s HFS is, on a default OS X install, case insensitive. But .c++ is valid.
.cxx sounds pretty straight forward to me, since people also use the $CXX
variable.
Re: Rename C files to .c in GCC source
> Am 31.01.2015 um 02:57 schrieb Jonathan Wakely : > > On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote: >> Apple’s HFS is, on a default OS X install, case insensitive. > > Which doesn't matter, see my previous reply. That is true; though its good to keep an eye out for it. >> But .c++ is valid. .cxx sounds pretty straight forward to me, since people >> also use the $CXX variable. > > We already use .C and .cc in GCC sources, so even if we needed to > change it, it would probably be better to use .cc for consistency > rather than add a third extension. Oh, I did not know this detail since I haven’t peered into the GCC source in a felt forever. Would make sense to use .cc then if it has already been used elsewhere in the source.
Re: Rename C files to .c in GCC source
> Am 31.01.2015 um 21:21 schrieb DJ Delorie : > > >> Aren't current Windows file systems case-preserving? Then they >> shouldn't have no problems with .C files. > > They are case preserving, but not case sensitive. A wildcard search > for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C. That also applies to OS X: $ head -n 1 build.it /** $ head -n 1 BUILD.IT /** $ head -n 1 BuIlD.iT /**
Re: Rename C files to .c in GCC source
> Am 01.02.2015 um 17:09 schrieb Eli Zaretskii : > >> Date: Sat, 31 Jan 2015 01:55:29 + >> From: Jonathan Wakely >> Cc: Andrew Pinski , "gcc@gcc.gnu.org" , >> Jonny Grant >> >> These files are only compiled by GCC's own build system, with GCC's >> own makefiles, so we know we invoke the C++ compiler and so the >> language isn't inferred from the file extension, and so we aren't >> relying on case-sensitive file systems. > > That is true for building GCC. But what about editors and other > development tools? They _will_ be affected. Indeed. Atom keeps thinking .C is an actual „ANSI C“ thing. If I were to make a suggestion to the GCC dev’s, then I probably could also swiftly word it as: $ find gcc-src -name "*.C“ | while read f; do mv $f $(echo $f | sed 's/\.C/\.cxx/g’); done In other words; .cxx, .cpp or .cc seems like a solution that works across platforms. Since .cc is already used at some places, I would recommend that this is to be the extension to choose. One does not neccessarily need to make a dev apply hacks all over just to start development.
Re: Rename C files to .c in GCC source
> Am 04.02.2015 um 00:20 schrieb Andreas Schwab : > > Jonny Grant writes: > >> How many minutes labor is this task? > > What does it fix? How many hacks/workarounds can be avoided?
