1. cannot build

gcc -DELINUX -m32 -pthread -c -w -fsigned-char -O2 -ffast-math  -fomit-frame-pointer -O2 -I../ -I../../include/  -DARCH=ix86 /home/irv/eu40/source/build/backobj/init-0.c -I/usr/share/euphoria -o/home/irv/eu40/source/build/backobj/init-0.o 
/home/irv/eu40/source/build/backobj/init-0.c: In function ‘init_literal0’: 
/home/irv/eu40/source/build/backobj/init-0.c:485: error: expected ‘;’ before ‘_20BOM_32be_4593’ 
/home/irv/eu40/source/build/backobj/init-0.c:487: error: expected ‘;’ before ‘_20BOM_32le_4595’ 
make[1]: *** [/home/irv/eu40/source/build/backobj/init-0.o] Error 1 
make[1]: Leaving directory `/home/irv/eu40/source' 
make: *** [backend] Error 2 

Note: the error seems straightforward - no ; at those 2 lines. However, adding them doesn't help - they go away next time you try to compile.

new topic     » topic index » view message » categorize

2. Re: cannot build

Can you revert from svn head (3117) to r3116 and see if it builds?

Can you determine the earliest working revision?

new topic     » goto parent     » topic index » view message » categorize

3. Re: cannot build

jimcbrown said...

Can you revert from svn head (3117) to r3116 and see if it builds?

Can you determine the earliest working revision?

3115 is the last that compiles.

new topic     » goto parent     » topic index » view message » categorize

4. Re: cannot build

irv said...
jimcbrown said...

Can you revert from svn head (3117) to r3116 and see if it builds?

Can you determine the earliest working revision?

3115 is the last that compiles.

That seems odd. The only thing that changed in 3116 was creole, which should not affect the build at all.

This makes me suspect it was Shawn's changes in 3117 that broke the Linux build.

new topic     » goto parent     » topic index » view message » categorize

5. Re: cannot build

Yes, It was me. I did it. I broke it. I added a bunch of constants called BOM and now I see there is somekind of BOM support in io.e. I also can no longer build. I can run 'eui -test unicode.e' without an error but I am sure it is the BOM constants causing the problem.

Shawn Pringle

new topic     » goto parent     » topic index » view message » categorize

6. Re: cannot build

irv said...
jimcbrown said...

Can you revert from svn head (3117) to r3116 and see if it builds?

Can you determine the earliest working revision?

3115 is the last that compiles.

I just tested this, and 3116 works for me. 3117 can't build.

If it helps, here's a sneak peek of beta 3 for linux: http://demonology.redirectme.net/euphoria-40b3.tar.gz

new topic     » goto parent     » topic index » view message » categorize

7. Re: cannot build

SDPringle said...

Yes, It was me. I did it. I broke it. I added a bunch of constants called BOM and now I see there is somekind of BOM support in io.e. I also can no longer build. I can run 'eui -test unicode.e' without an error but I am sure it is the BOM constants causing the problem.

Shawn Pringle

Shawn, I'm glad you've found the cause of the problem. It's good to know that we have somebody working on a fix for this..

new topic     » goto parent     » topic index » view message » categorize

8. Re: cannot build

jimcbrown said...

That seems odd. The only thing that changed in 3116 was creole, which should not affect the build at all.

This makes me suspect it was Shawn's changes in 3117 that broke the Linux build.

Sort of. He exposed a bug in the translator. Basically, the code for initializing a constant that couldn't be represented easily as a string wasn't emitting a semicolon. Apparently, no one had ever done this before. I think it has partly to do with the new ways of specifying strings in 4.0. Literals were properly initialized.

This is fixed in svn:3123.

Matt

new topic     » goto parent     » topic index » view message » categorize

9. Re: cannot build

mattlewis said...

This is fixed in svn:3123.

Matt

Maybe not. I just downloaded the latest svn, and still get the same error:

/home/irv/eu40/source/build/backobj/init-0.c: In function ‘init_literal0’: 
/home/irv/eu40/source/build/backobj/init-0.c:485: error: expected ‘;’ before ‘_20BOM_32be_4593’ 
/home/irv/eu40/source/build/backobj/init-0.c:487: error: expected ‘;’ before ‘_20BOM_32le_4595’ 
make[1]: *** [/home/irv/eu40/source/build/backobj/init-0.o] Error 1 
make[1]: Leaving directory `/home/irv/eu40/source' 
make: *** [backend] Error 2 
irv@irv-ultimate:~/eu40/source$ 

And, by the way, the latest from eubins (3123) has the float error as well. I'm thinking that might be a result of compiling on a different platform. What platform is used to compile the linux eubins?

new topic     » goto parent     » topic index » view message » categorize

10. Re: cannot build

[quote irv]

/home/irv/eu40/source/build/backobj/init-0.c: In function ‘init_literal0’: 
/home/irv/eu40/source/build/backobj/init-0.c:485: error: expected ‘;’ before ‘_20BOM_32be_4593’ 
/home/irv/eu40/source/build/backobj/init-0.c:487: error: expected ‘;’ before ‘_20BOM_32le_4595’ 
make[1]: *** [/home/irv/eu40/source/build/backobj/init-0.o] Error 1 
make[1]: Leaving directory `/home/irv/eu40/source' 
make: *** [backend] Error 2 
irv@irv-ultimate:~/eu40/source$ 

Hmm, do you need eub? If eui and euc compiled ok, though, I'm not sure why eub would have a problem...

irv said...

And, by the way, the latest from eubins (3123) has the float error as well. I'm thinking that might be a result of compiling on a different platform. What platform is used to compile the linux eubins?

Linux, 32bit (i686). I'm not what could be causing the floating point issue, but it is probably something to do with the build environment there.

new topic     » goto parent     » topic index » view message » categorize

11. Re: cannot build

I went back to r3115, and everything (including the floats) works correctly.

Question is, will my version work on the majority of Linux boxes, or are mine an anomaly, and the eubins version works on most? I have tested and gotten the same results on several different processors.

Further question: if the float problem is not caused by GTK, it should cause problems with any Eu Linux program which happens to pass floating point values. That would seem to warrant some investigation.

new topic     » goto parent     » topic index » view message » categorize

12. Re: cannot build

irv said...

I went back to r3115, and everything (including the floats) works correctly.

Question is, will my version work on the majority of Linux boxes, or are mine an anomaly, and the eubins version works on most? I have tested and gotten the same results on several different processors.

Further question: if the float problem is not caused by GTK, it should cause problems with any Eu Linux program which happens to pass floating point values. That would seem to warrant some investigation.

r3115 of eubins? Or that you built yourself?

Can you test linux beta 3 and see if it has the issue with floats? (This was built on a different system than the eubins.)

The understanding I have is that the issue with floats is unique to eubins, due to the setup there. (I had previously thought eubins were built on a 64bit linux box with 32bit emulation but I was mistaken.)

new topic     » goto parent     » topic index » view message » categorize

13. Re: cannot build

OK, I wrote too soon. I went back and deleted all my euphoria source, and downloaded r3123 again. This time it compiled, and the floats are ok.

4.0b3 does not have the float problem, either when downloaded from SF (euphoria-4.0b3.tar.gz) or built from source (euphoria-src-4.0b3.tar.gz)

new topic     » goto parent     » topic index » view message » categorize

14. Re: cannot build

irv said...

Question is, will my version work on the majority of Linux boxes, or are mine an anomaly, and the eubins version works on most? I have tested and gotten the same results on several different processors.

Further question: if the float problem is not caused by GTK, it should cause problems with any Eu Linux program which happens to pass floating point values. That would seem to warrant some investigation.

Jeremy and I have done some investigation of the difference between the eubins and stuff I built myself. I couldn't find anything obvious in the different build environments. Our gcc minor versions were one off (4.3 vs 4.4, see below).

It's definitely not a GTK issue. It's something to do with the way the euphoria binaries are built, as the test code we previously posted demonstrated.

This is my environment:

$ uname -a 
Linux oneill 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 
2009 i686 GNU/Linux 
 
$ gcc --version 
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 

And the eubins build environment:

$ uname -a 
Linux cowgar 2.6.18-6-686 #1 SMP Tue Jun 17 21:31:27 UTC 2008 i686 GNU/Linux 
 
$ gcc -v 
Using built-in specs. 
Target: i486-linux-gnu 
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu 
Thread model: posix 
gcc version 4.3.3 (Debian 4.3.3-5) 

Matt

new topic     » goto parent     » topic index » view message » categorize

15. Re: cannot build

Maybe the issue is that the gcc for eubins is using the mpfr library? Perhaps the mpfr library is changing the semantics of the way floats are handled?

mattlewis said...
irv said...

Question is, will my version work on the majority of Linux boxes, or are mine an anomaly, and the eubins version works on most? I have tested and gotten the same results on several different processors.

Further question: if the float problem is not caused by GTK, it should cause problems with any Eu Linux program which happens to pass floating point values. That would seem to warrant some investigation.

Jeremy and I have done some investigation of the difference between the eubins and stuff I built myself. I couldn't find anything obvious in the different build environments. Our gcc minor versions were one off (4.3 vs 4.4, see below).

It's definitely not a GTK issue. It's something to do with the way the euphoria binaries are built, as the test code we previously posted demonstrated.

This is my environment:

$ uname -a 
Linux oneill 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 
2009 i686 GNU/Linux 
 
$ gcc --version 
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 

And the eubins build environment:

$ uname -a 
Linux cowgar 2.6.18-6-686 #1 SMP Tue Jun 17 21:31:27 UTC 2008 i686 GNU/Linux 
 
$ gcc -v 
Using built-in specs. 
Target: i486-linux-gnu 
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu 
Thread model: posix 
gcc version 4.3.3 (Debian 4.3.3-5) 

Matt

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu