[asterisk-bugs] [JIRA] (ASTERISK-21967) CFLAG Improvement to prevent compiler error in Virtual Machine environments

PowerPBX (JIRA) noreply at issues.asterisk.org
Thu Jul 11 10:50:04 CDT 2013


     [ https://issues.asterisk.org/jira/browse/ASTERISK-21967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

PowerPBX updated ASTERISK-21967:
--------------------------------

    Description: 
At some point not too long ago a default CFLAG setting for i386 and x86_64 optimization must have been changed.  It appears to now be too aggressive in some situations for some virtualization environments.  Asterisk compiles without error but fails to run.

The error that is typically observed is:

/usr/sbin/safe_asterisk: line 147: 32428 Illegal instruction(core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY}
Asterisk ended with exit status 132
Asterisk exited on signal 4.
cat: /var/run/asterisk/asterisk.pid: No such file or directory
Automatically restarting Asterisk.


See this issue for more explanation.
ASTERISK-20128

I have identified what I believe to be a solution to this problem.
In Asterisk 11.4.0, Makfile.rules, line 87-88

ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
    _ASTCFLAGS+=-march=native 

I believe this should be changed to:

ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
    _ASTCFLAGS+=-mtune=native

This appears to correct the problem in my limited testing. This flag is available since gcc v4.2 according to the gcc documentation at the link below.  Prior to that version the setting should probably be mtune=generic.   For even more universal compatibility perhaps the default should just be mtune=generic.   That also corrected my problems and is even less likely to be a problem if I were to move my VPS to different hardware although is likely less optimal for newer CPU's.  Perhaps an additional check box could be added to menuselect for more aggressive compiling using -march=native.

http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options 

  was:
At some point not too long ago a default CFLAG setting for i386 and x86_64 optimization must have been changed.  It appears to now be too aggressive in some situations for some virtualization environments.  Asterisk compiles without error but fails to run.

The error that is typically observed is:



See this issue for more explanation.
ASTERISK-20128

I have identified what I believe to be a solution to this problem.
In Asterisk 11.4.0, Makfile.rules, line 87-88

ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
    _ASTCFLAGS+=-march=native 

I believe this should be changed to:

ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
    _ASTCFLAGS+=-mtune=native

This appears to correct the problem in my limited testing. This flag is available since gcc v4.2 according to the gcc documentation at the link below.  Prior to that version the setting should probably be mtune=generic.   For even more universal compatibility perhaps the default should just be mtune=generic.   That also corrected my problems and is even less likely to be a problem if I were to move my VPS to different hardware although is likely less optimal for newer CPU's.  Perhaps an additional check box could be added to menuselect for more aggressive compiling using -march=native.

http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options 

    
> CFLAG Improvement to prevent compiler error in Virtual Machine environments
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-21967
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21967
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 1.8.22.0, 11.4.0
>         Environment: CentOS 6 KVM Virtual Machine, Intel or AMD
>            Reporter: PowerPBX
>            Assignee: PowerPBX
>
> At some point not too long ago a default CFLAG setting for i386 and x86_64 optimization must have been changed.  It appears to now be too aggressive in some situations for some virtualization environments.  Asterisk compiles without error but fails to run.
> The error that is typically observed is:
> /usr/sbin/safe_asterisk: line 147: 32428 Illegal instruction(core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY}
> Asterisk ended with exit status 132
> Asterisk exited on signal 4.
> cat: /var/run/asterisk/asterisk.pid: No such file or directory
> Automatically restarting Asterisk.
> See this issue for more explanation.
> ASTERISK-20128
> I have identified what I believe to be a solution to this problem.
> In Asterisk 11.4.0, Makfile.rules, line 87-88
> ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
>     _ASTCFLAGS+=-march=native 
> I believe this should be changed to:
> ifeq ($(findstring BUILD_NATIVE,$(MENUSELECT_CFLAGS)),BUILD_NATIVE)
>     _ASTCFLAGS+=-mtune=native
> This appears to correct the problem in my limited testing. This flag is available since gcc v4.2 according to the gcc documentation at the link below.  Prior to that version the setting should probably be mtune=generic.   For even more universal compatibility perhaps the default should just be mtune=generic.   That also corrected my problems and is even less likely to be a problem if I were to move my VPS to different hardware although is likely less optimal for newer CPU's.  Perhaps an additional check box could be added to menuselect for more aggressive compiling using -march=native.
> http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list