Issue Details (XML | Word | Printable)

Key: PCC-67
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Gregory McGarry
Reporter: Susi Lehtola
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
pcc

Defining the default include path with --with-incdir eats away /usr/include

Created: 05/Aug/09 04:25 PM   Updated: 23/Aug/09 10:35 AM
Component/s: C preprocessor
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. Text File build.log (41 kB)

Environment: Fedora 11


 Description  « Hide
I'm working on an RPM package of pcc for Fedora. Due to obvious reasons the pcc library include files must be placed in a separate directory, namely
 /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/

Not defining the include directory with --with-incdir results in errors like
 /usr/include/stdio.h:34: error: cannot find 'stddef.h'
Defining --with-incdir=/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ in the compilation of pcc results in /usr/include not being in the include path.

What is the proper way to define the pcc include directory without losing /usr/include from the path?

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Gregory McGarry added a comment - 07/Aug/09 10:21 AM
I have run pcc on a fedora9 system out-of-the-box.

Can you run pcc with -v option to demonstrate the failure?

Can you list the files in your pcc include directories?

Susi Lehtola added a comment - 07/Aug/09 11:07 AM
I've built the library with a plain
%configure

where %configure is a macro that evaluates to

  CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic}" ; export CFLAGS ;
  CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic}" ; export CXXFLAGS ;
  FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib/gfortran/modules}" ; export FFLAGS ;
  ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu \
--target=x86_64-redhat-linux-gnu \
--program-prefix= \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/usr/com \
--mandir=/usr/share/man \
--infodir=/usr/share/info

The pcc library include files are installed into
/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include

and the libraries into
/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib


**

If I compile pcc with
 %configure --with-assembler=%{_bindir}/as --with-linker=%{_bindir}/ld \
  --with-libdir=%{_libdir}/pcc/%{_target_cpu}-redhat-linux-gnu/%{version}/lib \
  --with-incdir=%{_libdir}/pcc/%{_target_cpu}-redhat-linux-gnu/%{version}/include

then
$ pcc -v -o hello helloworld.c
pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Thu Aug 6 12:59:02 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-cpp -v -D__PCC__=0 -D__PCC_MINOR__=9 -D__PCC_MINORMINOR__=9 -D__linux__ -D__ELF__ -D__STDC_ISO_10646__=200009L -D__WCHAR_TYPE__=unsigned int -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_MAX__=4294967295U -D__WINT_TYPE__=unsigned int -D__SIZE_TYPE__=unsigned long -D__PTRDIFF_TYPE__=int -D__SIZEOF_WINT_T__=4 -D__i386__ -S /usr/include/pcc/ -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ helloworld.c /tmp/ctm.lzwqmI
cpp: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Thu Aug 6 12:59:02 EEST 2009
helloworld.c:1: error: cannot find 'stdio.h'

**

If I compile pcc with
 %configure --with-assembler=%{_bindir}/as --with-linker=%{_bindir}/ld \
  --with-libdir=%{_libdir}/pcc/%{_target_cpu}-redhat-linux-gnu/%{version}/lib

then
pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-cpp -v -D__PCC__=0 -D__PCC_MINOR__=9 -D__PCC_MINORMINOR__=9 -D__linux__ -D__ELF__ -D__STDC_ISO_10646__=200009L -D__WCHAR_TYPE__=unsigned int -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_MAX__=4294967295U -D__WINT_TYPE__=unsigned int -D__SIZE_TYPE__=unsigned long -D__PTRDIFF_TYPE__=int -D__SIZEOF_WINT_T__=4 -D__i386__ -S /usr/include/pcc/ -S /usr/i586-redhat-linux-gnu/include -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ helloworld.c /tmp/ctm.z0LqmZ
cpp: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
helloworld.c:1: error: cannot find 'stdio.h'

However, if I add -I/usr/include the program compiles fine.

$ pcc -I/usr/include -v -o helloworld helloworld.c
pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-cpp -v -D__PCC__=0 -D__PCC_MINOR__=9 -D__PCC_MINORMINOR__=9 -D__linux__ -D__ELF__ -D__STDC_ISO_10646__=200009L -D__WCHAR_TYPE__=unsigned int -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_MAX__=4294967295U -D__WINT_TYPE__=unsigned int -D__SIZE_TYPE__=unsigned long -D__PTRDIFF_TYPE__=int -D__SIZEOF_WINT_T__=4 -D__i386__ -I/usr/include -S /usr/include/pcc/ -S /usr/i586-redhat-linux-gnu/include -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ helloworld.c /tmp/ctm.CLAxww
cpp: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-ccom -v /tmp/ctm.CLAxww /tmp/ctm.tcTW4j
ccom: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/bin/as -v -o /tmp/ctm.7E9tZI /tmp/ctm.tcTW4j
GNU assembler version 2.19.51.0.2 (i586-redhat-linux) using BFD version version 2.19.51.0.2-17.fc11 20090204
/usr/bin/ld -v -X -d -e _start -dynamic-linker /lib/ld-linux.so.2 -o helloworld /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crt1.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crti.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtbegin.o /tmp/ctm.7E9tZI -L/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/ -lc -lpcc /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtn.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtend.o
GNU ld version 2.19.51.0.2-17.fc11 20090204

Susi Lehtola added a comment - 07/Aug/09 11:10 AM
Static build don't seem to work:

$ pcc -static -I/usr/include -v -o helloworld helloworld.c
pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-cpp -v -D__PCC__=0 -D__PCC_MINOR__=9 -D__PCC_MINORMINOR__=9 -D__linux__ -D__ELF__ -D__STDC_ISO_10646__=200009L -D__WCHAR_TYPE__=unsigned int -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_MAX__=4294967295U -D__WINT_TYPE__=unsigned int -D__SIZE_TYPE__=unsigned long -D__PTRDIFF_TYPE__=int -D__SIZEOF_WINT_T__=4 -D__i386__ -I/usr/include -S /usr/include/pcc/ -S /usr/i586-redhat-linux-gnu/include -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ helloworld.c /tmp/ctm.7ZEML4
cpp: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/libexec/i586-redhat-linux-gnu-ccom -v /tmp/ctm.7ZEML4 /tmp/ctm.fPhZXe
ccom: pcc 0.9.9 for i586-redhat-linux-gnu, mockbuild@politzer.theorphys.helsinki.fi Fri Aug 7 11:55:55 EEST 2009
/usr/bin/as -v -o /tmp/ctm.3Kg8AU /tmp/ctm.fPhZXe
GNU assembler version 2.19.51.0.2 (i586-redhat-linux) using BFD version version 2.19.51.0.2-17.fc11 20090204
/usr/bin/ld -v -X -d -e _start -Bstatic -o helloworld /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crt1.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crti.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtbegin.o /tmp/ctm.3Kg8AU -L/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/ -lc -lpcc /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtn.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtend.o
GNU ld version 2.19.51.0.2-17.fc11 20090204
/usr/lib/libc.a(iofclose.o): In function `fclose':
(.text+0x1a7): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(iofclose.o):(.eh_frame+0x167): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(iofflush.o): In function `fflush':
(.text+0xd6): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(iofflush.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(iofputs.o): In function `fputs':
(.text+0x10d): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(iofputs.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(iofwrite.o): In function `fwrite':
(.text+0x13c): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(iofwrite.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(wfileops.o): In function `_IO_wfile_underflow':
(.text+0xd5b): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(wfileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(wfileops.o):(.eh_frame+0x157): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(fileops.o): In function `_IO_file_underflow':
(.text+0x11f1): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(fileops.o): In function `_IO_file_fopen':
(.text+0x2635): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(fileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(fileops.o):(.eh_frame+0x357): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(syslog.o): In function `openlog':
(.text+0x434): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(syslog.o): In function `closelog':
(.text+0x4c9): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(syslog.o): In function `__vsyslog_chk':
(.text+0x9e8): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(syslog.o): In function `__vsyslog_chk':
(.text+0x9fa): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(syslog.o):(.eh_frame+0x166): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(syslog.o):(.eh_frame+0x1db): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(backtrace.o): In function `backtrace':
(.text+0x40): undefined reference to `_Unwind_Backtrace'
/usr/lib/libc.a(backtrace.o): In function `backtrace_helper':
(.text+0xfb): undefined reference to `_Unwind_GetIP'
/usr/lib/libc.a(backtrace.o): In function `backtrace_helper':
(.text+0x120): undefined reference to `_Unwind_GetGR'
/usr/lib/libc.a(backtrace.o): In function `backtrace_helper':
(.text+0x12b): undefined reference to `_Unwind_GetCFA'
/usr/lib/libc.a(vfprintf_chk.o): In function `__vfprintf_chk':
(.text+0xfc): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(vfprintf_chk.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(ioftell.o): In function `ftell':
(.text+0x194): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(ioftell.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(iogetdelim.o): In function `getdelim':
(.text+0x262): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(iogetdelim.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(ioseekoff.o): In function `_IO_seekoff':
(.text+0x1e5): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(ioseekoff.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(ioseekoff.o):(.eh_frame+0x11f): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(fseek.o): In function `fseek':
(.text+0xde): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(fseek.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'
/usr/lib/libc.a(ftello.o): In function `ftello':
(.text+0x194): undefined reference to `_Unwind_Resume'
/usr/lib/libc.a(ftello.o):(.eh_frame+0xdf): undefined reference to `__gcc_personality_v0'

Gregory McGarry added a comment - 07/Aug/09 04:09 PM
I think you are saying that you cannot build yourself a cross-compiler. If you don't have the system headers installed into the correct place, then it won't work.

If you are using a system where the i386 and amd64 headers are shared, then you should be able to specify --with-incdir=/usr/include. But I haven't tested this situation.

And it is known that glibc and static binaries don't work.

Susi Lehtola added a comment - 07/Aug/09 04:22 PM
Sorry, the system is pure 32-bit i586. pcc-libs does not even compile on x86_64. I must have taken the %configure from an x86_64.

/usr/include contains all headers. I'm just wondering why pcc is including first /usr/include/pcc/, then the directory specified with --with-incdir (or /usr/i586-redhat-linux-gnu/include by default) and then the directory /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/. /usr/include isn't in the include path, as can be seen from

/usr/libexec/i586-redhat-linux-gnu-cpp -v -D__PCC__=0 -D__PCC_MINOR__=9 -D__PCC_MINORMINOR__=9 -D__linux__ -D__ELF__ -D__STDC_ISO_10646__=200009L -D__WCHAR_TYPE__=unsigned int -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_MAX__=4294967295U -D__WINT_TYPE__=unsigned int -D__SIZE_TYPE__=unsigned long -D__PTRDIFF_TYPE__=int -D__SIZEOF_WINT_T__=4 -D__i386__ -S /usr/include/pcc/ -S /usr/i586-redhat-linux-gnu/include -S /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/include/ helloworld.c /tmp/ctm.z0LqmZ

Gregory McGarry added a comment - 07/Aug/09 11:07 PM
For some reason, configure thinks you are building a cross compiler, so it assumes the include files are in /usr/i586-redhat-linux-gnu/include, rather than /usr/include. But I thought that --with-incdir was supposed to override that.

/usr/include/pcc is added to the include path so that it is possible to add header files which override the system headers. This is needed for some systems where the system headers are broken.

Can you send the actual configure line you are using? The one you posted earlier isn't the correct one.

Susi Lehtola added a comment - 08/Aug/09 07:45 AM
RPM build log from mock including configure command.

Gregory McGarry added a comment - 08/Aug/09 12:12 PM
Right, and you are building a cross-compiler:

--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i586-redhat-linux-gnu

Your host system is different from your target system. This is the reason that pcc is using a different system include directory.

If you don't want this behaviour, you must have the same host and target. But I would have thought the --with-incdir=/usr/include would fix this for you.

Susi Lehtola added a comment - 08/Aug/09 12:21 PM
Yes, that's rather interesting since the whole system is configured and built with those flags.

OK, I'll try --with-incdir=/usr/include

Susi Lehtola added a comment - 08/Aug/09 12:36 PM
OK, now it works. It seems I misunderstood the use of --with-incdir: I need the
  --with-libdir=%{_libdir}/pcc/%{_target_cpu}-redhat-linux-gnu/%{version}/lib
argument for pcc to find its libraries, so I thought I also had to specify the (pcc) include dir, but it seems to find it automatically.

Gregory McGarry added a comment - 08/Aug/09 12:41 PM
Hmmm. Compiling compilers is a little different, since most applications don't need the --target argument.

Good luck! Thanks for playing with pcc!

Gregory McGarry added a comment - 08/Aug/09 12:46 PM
Also, as I recall, glibc on many linux systems assumes that everything is compiled with gcc. This is the reason that static linking doesn't work.

We'll have to add more gcc-specific goop to libpcc to get static linking to work. Either that, or a new libc for linux. I actually have my own libc which supports static linking on OSX.

Gregory McGarry added a comment - 08/Aug/09 12:56 PM - edited
You shouldn't need the --with-libdir either. If you don't want the cross-compiler, it should probably be --with-libdir=/usr/lib.

Certainly, you should _not_ need to point it to the libpcc lib dir.


Gregory McGarry added a comment - 08/Aug/09 01:05 PM
I also noticed that you are compiling libpcc with -fstack-protector. Since libpcc contains the routines to support the stack protector, I'm guessing that -fstack-protector should be disabled for ssp.c. Do you know how to do this? Should I add a -fno-stack-protector to override it?

Susi Lehtola added a comment - 08/Aug/09 01:19 PM
If I don't define --with-libdir then pcc looks for the library in the wrong place:

/usr/bin/ld -v -X -d -e _start -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/i586-redhat-linux-gnu/lib/crt1.o /usr/i586-redhat-linux-gnu/lib/crti.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtbegin.o /tmp/ctm.zi9f5d -L/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/ -lc -lpcc /usr/i586-redhat-linux-gnu/lib/crtn.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtend.o
GNU ld version 2.19.51.0.2-17.fc11 20090204
/usr/bin/ld: /usr/i586-redhat-linux-gnu/lib/crt1.o: No such file: No such file or directory

so it seems you are missing /lib/pcc in some of the library paths.

**

Yes, please add -fno-stack-protector after CFLAGS. Everything in Fedora must be compiled with the standard flags.

By the way, pcc-libs/csu/linux doesn't use the CFLAGS given by configure if one does not override the make flags with
 make CFLAGS="-I%{_arch} -I. %{optflags}"

Also, pcc-libs/csu/linux/crtbegin.c has some assembly code and thus it cannot be compiled with -g. The makefile should take this into account.

Gregory McGarry added a comment - 08/Aug/09 01:44 PM
I see the problem.

Most glibc system should not be using the pcc-supplied crt0.o. glibc has some funky stuff happening which requires its own crt0.o

Although you may have been able to compile a few simple programs with pcc-supplied crt0.o, it won't work for complex programs (such as those with pthreads).

You should really be using --with-libdir=/usr/lib, which contains the glibc-supplied /usr/lib/crt0.o.

You may still have problem, because pcc thinks it's a cross-compiler. I think you should really fix the rpm so that the host system and the target are the same.

Susi Lehtola added a comment - 08/Aug/09 02:15 PM
Okay, so I don't need the pcc library at all, only the include files in the pcc-lib tarball?

Gregory McGarry added a comment - 08/Aug/09 11:08 PM - edited
You need libpcc, since it replaces libgcc supplied by gcc. You don't need crt0.o to replace crt0.o supplied by glibc.

Susi Lehtola added a comment - 09/Aug/09 08:40 AM
OK, now I switched to --libdir=/usr/lib and I get

/usr/bin/ld -v -X -d -e _start -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtbegin.o /tmp/ctm.n0aKPr -L/usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/ -lc -lpcc /usr/lib/crtn.o /usr/lib/pcc/i586-redhat-linux-gnu/0.9.9/lib/crtend.o
GNU ld version 2.19.51.0.2-17.fc11 20090204

so this should be fine?

Gregory McGarry added a comment - 09/Aug/09 10:17 AM
Yes, that looks good.

Susi Lehtola added a comment - 13/Aug/09 09:54 AM
A few other questions:

now I have removed the --target from configure, so I end up with
/usr/bin/pcc
/usr/libexec/cpp
/usr/libexec/ccom

I'd like to add a pcc-prefix to cpp and ccom to make sure they don't clash with other compilers. Is this possible?

**

The Fortran frontend is not working, I presume?

**

The x86_64 port of pcc does not work until pcc-libs gets x86_64 support as well?

Gregory McGarry added a comment - 13/Aug/09 12:19 PM
It doesn't look like configure.ac will let you prefix the binaries unless it is a cross-compiler.

The other questions should be asked on the mailing list.

Gregory McGarry added a comment - 14/Aug/09 04:30 AM
I just committed csu files for 64-bit linux. I was able to compile helloword.c without problems.