similar to: [LLVMdev] llvm-gcc builds on 32 bit linux broken

I think this error is due to these changes: Doing diffs in .: --- ./gsyslimits.h.~1~ 2006-11-26 12:31:50.000000000 -0800 +++ ./gsyslimits.h 2007-04-02 12:37:38.000000000 -0700 @@ -4,5 +4,3 @@ instead of this text. */ #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse */ -#include_next <limits.h> -#undef _GCC_NEXT_LIMITS_H --- ./limitx.h.~1~ 2006-11-26

On Thu, Aug 7, 2008 at 5:46 PM, David Shipman <dshipman at gmail.com> wrote: > I've just tried building r54494 on 64bit linux and had the same (no > include path) > error. Any idea what's happening here? > No. :-( Could you try Mike's suggestion? (Replicated here) Try adding: #define _GCC_LIMITS_H_ to limitx.h like so: #ifdef _GCC_NEXT_LIMITS_H +#define

Mike's suggestion seems to fix the problem - happy to use it, although my impression is that it shouldn't be necessary? -David Shipman On Fri, Aug 8, 2008 at 12:59 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Thu, Aug 7, 2008 at 5:46 PM, David Shipman <dshipman at gmail.com> wrote: >> I've just tried building r54494 on 64bit linux and had the same (no

> to limitx.h like so: > > #ifdef _GCC_NEXT_LIMITS_H > +#define _GCC_LIMITS_H_ > #include_next <limits.h> > #undef _GCC_NEXT_LIMITS_H This fixes this problem for me on Ubuntu Hardy on x86-64. John

Hi Matthijs, >> I did put in a hack, but it was horrible. It might be a good idea to >> test out Mike's suggestion to see if it's a better way of doing it. > I just tried building llvm-gcc without your hack, and it still works (even > without the fix Mike suggested). > > So, it seems that r54245 can be reverted again? > > I didn't test bootstrap, however,

I've just tried building r54494 on 64bit linux and had the same (no include path) error. Any idea what's happening here? Thanks, -David Shipman On Fri, Aug 8, 2008 at 6:12 AM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Matthijs, > >>> I did put in a hack, but it was horrible. It might be a good idea to >>> test out Mike's suggestion to see if

llvm-gcc 2.4 doesn't seem to compile; what is wrong? This is my first attempt to compile llvm-gcc. The llvm core compiled without problems. $ uname -a Linux ygramoel 2.6.26.5-45.fc9.x86_64 #1 SMP Sat Sep 20 03:23:12 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v ... gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) $ svn co

On Jul 30, 2008, at 11:35 PM, Bill Wendling wrote: > I think this error is due to these changes: Try adding: #define _GCC_LIMITS_H_ to limitx.h like so: #ifdef _GCC_NEXT_LIMITS_H +#define _GCC_LIMITS_H_ #include_next <limits.h> #undef _GCC_NEXT_LIMITS_H and then testing. A good test would do a -dM -E and seeing if everything is still defined and checking the testcase mentioned in

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

You're right, thanks. However, now I ran into the next problem. This seems to be related to the fact that I have a 64-bit machine? $ ../../src/llvm-gcc/configure --prefix=/home/johan/llvm --program-prefix=llvm- --enable-llvm=/home/johan/llvm/obj/llvm --enable-languages=c,c++ ... $ gmake ... /home/johan/llvm/obj/llvm-gcc/./gcc/xgcc -B/home/johan/llvm/obj/llvm-gcc/./gcc/

http://bugzilla.mindrot.org/show_bug.cgi?id=1235 Summary: [PATCH] scp does unnecessary getpwuid(), breaking chroot Product: Portable OpenSSH Version: -current Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: bitbucket at mindrot.org

陳韋任 wrote: > > Does your maching have directories like /lib64 and /usr/lib64? > Yes, it has /lib64 and /usr/lib64. > > > what is the size of a void pointer? > $ ./a.out > sizeof (void*) : 8 > > > Does this change if you add -m64 to the gcc command line? > No. Ok, as far as I cam tell, everything on your system is correct. I don't have any further ideas

Dear all I am trying nlme together with Pinheiro/Bates book. I constructed grouped data object with suitable plotting layout (according to some common factor, panels from bottom to top are in increasing order). When I do nlme(... some stuff...) I get fitted object which I can plot with plot(augPred(fit.nlme6, level=0:1)) but it results in completely different ordering. Is there any way

Hi all, I managed to navigate around all those issues with environment variables and such. llvm itself now builds and checks just fine, but I can't get llvm-gcc to compile. Trying to 'make' from .../gcc gives me: ./xgcc -B./ -B/home/jo/i686-pc-linux-gnu/bin/ -isystem /home/jo/i686-pc-linux-gnu/include -isystem /home/jo/i686-pc-linux-gnu/sys-include -L/home/jo/llvm-gcc-wrk/gcc/../ld

I am trying to do some research that involves instrumenting LLVM IR, that I need to test for performance and scalability on a bunch of systems. I've started trying by trying to get sparc-sun-solaris2.10 (niagara) working. It appears that neither llvm nor llvm-gcc will build natively on the system, so I think that I need to build an llvm-gcc cross compiler. The documentation for building

Hi Johan, > You're right, thanks. However, now I ran into the next problem. This > seems to be related to the fact that I have a 64-bit machine? I also have a 64 bit machine but I don't see this, and I don't know what the reason could be. Hopefully someone else has a solution. Ciao, Duncan. > $ ../../src/llvm-gcc/configure --prefix=/home/johan/llvm >

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the

Thank you for clarifying this, Johan. Very much appreciated! On Wed, 29 Apr 2015 22:28:00 +0200 Johan Kooijman wrote: > Carl, > > By default my.cnf has to obey the OS limits, so in this case the > order is: systemd > /etc/security/limits* > /etc/my*. > > On Wed, Apr 29, 2015 at 3:22 PM, Carl E. Hartung > <carlh04426 at gmail.com> wrote: > > > Hi

I have problem compiling the gcc frontend. Almost everything seems to compile but at the very end when crt startup files are compiled, the assembler complains about bad registers. Any idea what I am doing wrong? Thanks, Robert HOST: os: ubuntu 2.6.18 kernel x86_64 GNU/Linux compiler: gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) SOURCE: svn trunk gcc4.2 CONFIGURE:

On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 12:23 -0400 schrieb Daniel Berlin: >> To clarify, >> >> configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu >> --target=i686-pc-linux-gnu >> >> I do this all the time on my 4 core amd64 box and it works fine. > > There must be some other difference, as