| |
| |
| |
|
Comments:
<0> greetings
<0> anyone on?
<1> hi guys, dont suppose anyone here would be able to enlighten me on why a program compile with -g -pg -fprofile-arcs -ftest-coverage wouldn't generate output files on exit - exit(1) is called from a DL module, and gdb says 'program exited normally' - it was working fine on a different box last night ;/
<2> does GCC define a macro to specify what endian the system is?
<2> so i can do something like:
<2> typedef union { struct { uint8_t low; uint8_t high; }; uint16_t word } uint16_hl_t;
<2> anyone? :(
<3> any gcc mach-O guru's in the house?
<4> ok, so, I want to set up a compiler for the xc16x target to compile some embeded firmware. do I just need to get the source tarball, configure with --target=xc16x, and set the --prefix to somewhere (in opt) that wont overwrite my normal system install of gcc?
<5> is there a way to have gcc/ld not link in functions that are not called...I want to avoid having dead code
<5> ls
<6> hi I'm doing -m32 but when I use CFLAGS="-O3 -m32" it fails and I can see its trying to make the out put 64bit
<6> but if I use CC="gcc -O2 -m32" its working O.o
<6> I do see the -O2 -m32 during the compile but I don't see gcc but I do with CC=
<7> how can you see that its trying to make the out put 64bit?
<6> ../sysdeps/unix/i386/sysdep.S:51: Error: @NTPOFF reloc is not supported with 64-bit output format
<6> :D
<6> -fmerge-all-constants -m32 -march=i486 -mtune=i686 - can see it added the -m32 etc
<6> but still wants to output to 64bit
<6> if I use CC="gcc -O2.3 etc -m32 ...." it works
<6> onfused on why one does and not the other . O.o
<6> so used to CFLAGS in the slackware buyuild scripts now with glibc its failing for the 32bit compile
<6> is it because at cross compile I used CC (used the clfs book to help do the cross compile) but keeping it slackware/slamd style
<6> just trying to package up glibc :D
<6> edit the build script for the multilib package
<6> funny too with CFLAGS I need to use the --with-headers=/usr/include but not with CC
<6> CFLAGS="-O2 -m32 -march=i486 -mtune=i686" CXXFLAGS="-O2 -m32 -march=i486 -mtune=i686" ../glibc-2.4/configure --prefix=/usr --disable-profile --enable-add-ons --enable-kernel=2.6.0 --with-headers=/usr/include i486-slackware-linux
<8> oneforall: if the configure isn't very old, putting CFLAGS and CXXFLAGS as arguments instead of environment variables is possible (and makes things more readable and cleaner in my POV)
<6> http://rafb.net/p/IPnWyF19.html am I right here and gcc is still in cross compile mode or what ever its called since I see this Target: x86_64-slackware-linux but if I do gcc -v on this slack boc 32bit I don't see that
<6> glibc 2.4
<6> so maybe glibc being newer needs the CC now ?
<6> noshadow sorry if I sound like I'm rambling on :D
<6> ah I should grep the configure and see what it has for CFLAGS
<9> hi all!
<9> if compile a .c file with a "strucy mystr const arr[1]", arr is put in a readonly segment (.rodata)
<9> if I compile with -fPIC flags it is put in .rodata only if struct mystr does not contain a pointer
<9> otherwise it is put in a .data.rel.ro segment
<8> cavedon: sounds sensible
<9> and this segment is not made RO at runtime
<9> so I can write to it without getting segfault
<9> what is the reason it is not made RO?
<8> cavedon: I don't know. But fwik relocations are done my the process itself, so the process has to write it, so it cannot simply be mmaped ro.
<8> though that is really not a gcc question, but a question about your dynamic loader.
<9> noshadow: mhm, if the relacation is made by the process itself I see it needs to write ....
<9> thanks noshadow
<6> weird wonder why at make install DESTDIR/paht it deleted the specs file and never moved it over first
<6> can't see in the log it even trying to mv it first
<6> made a 2>&1 |tee log file
<6> or is gcc 4.1.1 just doing built in specs now
<6> Using built-in specs.
<10> oneforall: yes, built-in specs, gcc -dumpspecs
<6> so no need for the specs file over iin /usr/lib64/gcc/x86_64-slackware-linux/4.1.1/specs ?
<6> I notice the compile just deletes it now from the build dir and doesn't move it to the install dir
<6> and is it ok that it says Target: x86_64-slackware-linux
<11> hello all, i'm trying to cross-compile for alpha, i found crosstool and ran its script to build compiler tools for alpha, but i wrote my first test program and it does not run under the alpha machine after sftp the binary, i get these 'file' outputs
<11> on the target: COFF format alpha dynamically linked, demand paged executable or object module not stripped - version 3.13-14
<11> that's the output of file for binaries i find on the machine
<11> my test program has this output for file:
<11> ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), for GNU/Linux 2.4.18, statically linked, for GNU/Linux 2.4.18, not stripped
<11> can anyone point me to documentation or hints?
<10> squeaks: probably configure with --target=alpha-coff ot somethinh similar
<11> how can i tell what version of library files are on my target machine?
Return to
#gcc
or
Go to some related
logs:
#math
#debian
#linux
#web
wincodecs
dos2unix tar
#awk
debian 404 128.101.240.212
kirstyblue page
skeggo
|
|