OpenEuphoria: Ticket #659: gcc 4.6, n...

Euphoria Ticket #659: gcc 4.6, not building

Reported by Huulivoide Apr 28, 2011
17 comments

euphoria 4.0.2 won't build if gcc version 4.6 is used.

here is build log [matt: edited to just show the segfault error]:

 
/home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/euc -build-dir "/home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/eudist-build" \ 
        -i /home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/include \ 
        -o "/home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/eudist" \ 
        -lib "/home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/eu.a" \ 
        -makefile -eudir /home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2 \ 
         /home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/eudist.ex 
make[1]: *** [/home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/eudist-build/main-.c] Segmentation fault

Details

Type:	Bug Report	Severity:	Major	Category:	Build System
Assigned To:	mattlewis	Status:	Fixed	Reported Release:	4.0.2
Fixed in SVN #:		View VCS:	none	Milestone:	4.0.3

1. Comment by ne1uno Apr 29, 2011

did you try rerunning the build? recent gcc seg faulting for no reason is not that unusual. doesn't look like a gcc4.6 specific problem. that is, unless it fails at the same point every time.

more strange is why all the .hg not found messages. looks like something is trying to get a version too many times. should be able to decide once per build if .hg will be found.

2. Comment by mattlewis Apr 29, 2011

This was built from the source distribution, so it's no surprise that there was no hg repo found. The segfault actually appears to be coming from the translator.

It's hard to say what the problem is, but I suspect it's some system configuration issue that we didn't take into account. I don't recognize which language the system is set up for, but it's definitely not english. I'm skeptical, but it could be related to that.

3. Comment by Huulivoide May 02, 2011

It fails on the same point, every time. There is also a another report about this, at the same point too. Also it compiles fine with gcc 4.5 series of compilers. I will try to build this onemore time and this time set all LC variables to english XD. Natively this is box runs on finnish :D. I know that locale can break build even thought it sounds so strange. It would be nice to get this working, as Arch Linux has swiched to 4.6 series so it isint possible to compile and use euphoria on Arch anymore, without downgrading gcc.

4. Comment by Jerome May 23, 2011

I'm also on Arch Linux and can not compile euphoria from source since upgrading to gcc 4.6.0-5. I tried the 4.0 branch and the default branch. My build does finish without errors, but the compiled binaries give a 'Segmentation Fault' when run. I've tried rerunning the build but the binaries always Seg Fault. I didn't copy the output because there weren't any errors but can post something if needed. Thanks!

5. Comment by mattlewis May 23, 2011

I suppose the first step is to build a debug version. Try something like:

$ make clean 
$ make interpreter EDEBUG=1 
$ gdb $BUILDDIR/eui 
(gdb) run something.ex

And we can see where it's dying.

6. Comment by Huulivoide May 28, 2011

Starting program: /home/jesse/aur/euphoria/src/euphoria-LINUX-4.0.2/source/build/eui ascii.ex [Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault. 0x00000001 in ?? ()

7. Comment by SDPringle Jun 06, 2011

Can you try to build the 3.1 sources with the same compiler?

8. Comment by Huulivoide Jun 08, 2011

The old series 3 euphoria builds fine, after some makefile patching for 64bit build :D

9. Comment by ne1uno Jun 10, 2011

tried to build 4.0.2 w/minGW 4.6.0 on windows from http://nuwen.net/mingw.html

cc1.exe: error: unrecognized command line option '-mno-cygwin'

will have to grab the docs later, it's possible some of the other default options in the makefile will have to change for 4.6 too.

-fomit-frame-pointer -O3 could be trouble?

10. Comment by mattlewis Jun 10, 2011

@Huulivoide: 4.0.x shouldn't be built as 64-bit. If that's what you did, I'm not surprised it crashed (though 32-bit builds on a 64-bit machine are fine). What about 4.1 (see the default branch in the repo)? I run a 64-bit build of that all the time. The current tip passes all tests. I even run it with a 64-bit build of wxEuphoria. smile

@ne1uno: Why would -fomit-frame-pointer -O3 be trouble? I see stuff on the web about -mno-cygwin going away eventually. Looks like they finally did it. I suspect that older versions can probably get away with not using that flag anyways, though maybe some people need it. I suppose we could remove it by default, and add that as a configuration option.

11. Comment by SDPringle Jun 10, 2011

The -m32 option is being passed to gcc. It seems to me that it shouldn't matter whether it runs on a 64-bit or 32-bit machine as long as it isn't the old IA64 machines that was incompatible with IA32.

12. Comment by mattlewis Jun 10, 2011

-m32 and -m64 are critical to distinguish between building for x86 and x86_64. x86 binaries can run on x86_64 machines, but obviously not vice versa. The -m32 flag is redundant on an x86 machine, and the -m64 flag is on an x86_64 machine.

13. Comment by ne1uno Jun 11, 2011

removing -mno-cygwin from Makefile.gcc & buildsys.e, using minGW 4.6.0 on windows,

minGW gcc built 4.0.2 translator on windows had a link bug (since fixed) so it did fail when building tools. but for a different reason. but eui ran ok. instead of trying to backpatch the translator fix, I just updated to 4.0 and then make completes w/o error though with plenty of warnings.

interpreter binder & translator seem to work ok on a few quick tests. running full suite now. no segfaults so far.

I bring up -fomit-pointer & O3 as a source of potential problems, only because I have seen it mentioned in numerous forums with recent gcc, though probably only the minGW builds. and. I realized later, it wouldn't be used in a debug build anyway.

14. Comment by mattlewis Jun 11, 2011

I installed arch in a VM to try stuff out myself. The problem appears to be in be_callc.c:call_c. I think some of the optimization flags for that are causing problems.

15. Comment by mattlewis Jun 11, 2011

See: hg:euphoria/rev/f807f1f9e9b5

changeset: 4945:f807f1f9e9b5 branch: 4.0 tag: tip parent: 4933:c65d07fede56 user: Matt Lewis date: Sat Jun 11 22:26:04 2011 +0000 files: source/Makefile.gnu description:

OpenEuphoria