[asterisk-dev] Asterisk-1.4.2 /usr/bin/ld: skipping incompatible /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../liberror.so when searching for -lerror

Sathishkumar P sathishkumar.palanisamy at wnipl.com
Wed Feb 27 06:43:31 CST 2008


Dear Friends,
    I am new to asterisk... I am trying to install asterisk-1.4.2 in my 
linux Redhat EL4. I am getting the following error. Plz help me to solve 
the problem....

make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
[LD] abstract_jb.o acl.o aescrypt.o aeskey.o aestab.o alaw.o app.o 
ast_expr2.o ast_expr2f.o asterisk.o astmm.o autoservice.o callerid.o 
cdr.o channel.o chanvars.o cli.o config.o cryptostub.o db.o 
devicestate.o dial.o dns.o dnsmgr.o dsp.o enum.o file.o fixedjitterbuf.o 
frame.o fskmodem.o http.o image.o indications.o io.o jitterbuf.o 
loader.o logger.o manager.o md5.o netsock.o pbx.o plc.o privacy.o rtp.o 
say.o sched.o sha1.o slinfactory.o srv.o stdtime/localtime.o strcompat.o 
tdd.o term.o threadstorage.o translate.o udptl.o ulaw.o utils.o 
editline/libedit.a db1-ast/libdb1.a -> asterisk
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../liberror.so when searching 
for -lerror
/usr/bin/ld: skipping incompatible /lib/liberror.so when searching for 
-lerror
/usr/bin/ld: skipping incompatible /usr/lib/liberror.so when searching 
for -lerror
/usr/bin/ld: cannot find -lerror
collect2: ld returned 1 exit status
make[1]: *** [asterisk] Error 1
make: *** [main] Error 2






Regards
Sathishkumar.P

Tzafrir Cohen wrote:
> Hi
>
> On Wed, Feb 27, 2008 at 12:54:29AM -0000, SVN commits to the Digium repositories wrote:
>   
>> Author: russell
>> Date: Tue Feb 26 18:54:29 2008
>> New Revision: 104332
>>
>> URL: http://svn.digium.com/view/asterisk?view=rev&rev=104332
>> Log:
>> Zaptel 1.4 now exposes FXO battery state as an alarm.  However, Asterisk 1.4
>> does not know what to do with these alarms.  Only Asterisk 1.6 cares about it.
>> So, if we get an unknown alarm in chan_zap, don't generate confusing log messages
>> about it.
>>     
>
> Useful hack, indeed. But,
>
>   
>> Modified:
>>     branches/1.4/channels/chan_zap.c
>>
>> Modified: branches/1.4/channels/chan_zap.c
>> URL: http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_zap.c?view=diff&rev=104332&r1=104331&r2=104332
>> ==============================================================================
>> --- branches/1.4/channels/chan_zap.c (original)
>> +++ branches/1.4/channels/chan_zap.c Tue Feb 26 18:54:29 2008
>> @@ -461,6 +461,7 @@
>>  	unsigned int ignoredtmf:1;
>>  	unsigned int immediate:1;			/*!< Answer before getting digits? */
>>  	unsigned int inalarm:1;
>> +	unsigned int unknown_alarm:1;
>>  	unsigned int mate:1;				/*!< flag to say its in MATE mode */
>>  	unsigned int outgoing:1;
>>  	unsigned int overlapdial:1;
>> @@ -3832,11 +3833,22 @@
>>  #endif
>>  			p->inalarm = 1;
>>  			res = get_alarms(p);
>> -			ast_log(LOG_WARNING, "Detected alarm on channel %d: %s\n", p->channel, alarm2str(res));
>> -			manager_event(EVENT_FLAG_SYSTEM, "Alarm",
>> -								"Alarm: %s\r\n"
>> -								"Channel: %d\r\n",
>> -								alarm2str(res), p->channel);
>> +			do {
>>     
>
> We already have the alarm as a value (res).
>
>   
>> +				const char *alarm_str = alarm2str(res);
>> +
>> +				/* hack alert!  Zaptel 1.4 now exposes FXO battery as an alarm, but asterisk 1.4
>> +				 * doesn't know what to do with it.  Don't confuse users with log messages. */
>> +				if (!strcasecmp(alarm_str, "No Alarm") || !strcasecmp(alarm_str, "Unknown Alarm")) {
>>     
>
> Yet we convert it to a string, and compare the generated string.
>
> We can compare the int directly.
>
>   
>> +					p->unknown_alarm = 1;
>> +					break;
>> +				}
>> +					
>> +				ast_log(LOG_WARNING, "Detected alarm on channel %d: %s\n", p->channel, alarm_str);
>> +				manager_event(EVENT_FLAG_SYSTEM, "Alarm",
>> +					"Alarm: %s\r\n"
>> +					"Channel: %d\r\n",
>> +					alarm_str, p->channel);
>> +			} while (0);
>>  #ifdef HAVE_LIBPRI
>>  			if (!p->pri || !p->pri->pri || pri_get_timer(p->pri->pri, PRI_TIMER_T309) < 0) {
>>  				/* fall through intentionally */
>> @@ -4167,9 +4179,13 @@
>>  			if (p->bearer)
>>  				p->bearer->inalarm = 0;
>>  #endif				
>> -			ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", p->channel);
>> -			manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
>> -								"Channel: %d\r\n", p->channel);
>> +			if (!p->unknown_alarm) {
>> +				ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", p->channel);
>> +				manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
>> +					"Channel: %d\r\n", p->channel);
>> +			} else {
>> +				p->unknown_alarm = 0;
>> +			}
>>  			break;
>>  		case ZT_EVENT_WINKFLASH:
>>  			if (p->inalarm) break;
>> @@ -6675,18 +6691,33 @@
>>  		break;
>>  	case ZT_EVENT_NOALARM:
>>  		i->inalarm = 0;
>> -		ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", i->channel);
>> -		manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
>> -			"Channel: %d\r\n", i->channel);
>> +		if (!i->unknown_alarm) {
>> +			ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", i->channel);
>> +			manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
>> +				"Channel: %d\r\n", i->channel);
>> +		} else {
>> +			i->unknown_alarm = 0;
>> +		}
>>     
>
> Do you assume that if an alarm is set in a certain way it will be
> cleared in the same way?
>
> I can't think of a realistic scenario that breaks this. One that I hope
> that will become realistic is the following:
>
> 1. Normal operation
> 2. Disconnection line from FXO port -> RED alarm on that port.
> 3. Disconnecting device altogether -> NOTOPEN alarm on the whole span.
> 4. Reconnecting the line to that FXO port.
> 5. Reconnecting the device, NOTOPEN alarm clean. (this is the "hope" part :-)
>
> Is the port still in RED alarm?
>
>   
>>  		break;
>>  	case ZT_EVENT_ALARM:
>>  		i->inalarm = 1;
>>  		res = get_alarms(i);
>> -		ast_log(LOG_WARNING, "Detected alarm on channel %d: %s\n", i->channel, alarm2str(res));
>> -		manager_event(EVENT_FLAG_SYSTEM, "Alarm",
>> -			"Alarm: %s\r\n"
>> -			"Channel: %d\r\n",
>> -			alarm2str(res), i->channel);
>> +		do {
>> +			const char *alarm_str = alarm2str(res);
>> +
>> +			/* hack alert!  Zaptel 1.4 now exposes FXO battery as an alarm, but asterisk 1.4
>> +			 * doesn't know what to do with it.  Don't confuse users with log messages. */
>> +			if (!strcasecmp(alarm_str, "No Alarm") || !strcasecmp(alarm_str, "Unknown Alarm")) {
>> +				i->unknown_alarm = 1;
>> +				break;
>> +			}
>> +
>> +			ast_log(LOG_WARNING, "Detected alarm on channel %d: %s\n", i->channel, alarm_str);
>> +			manager_event(EVENT_FLAG_SYSTEM, "Alarm",
>> +				"Alarm: %s\r\n"
>> +				"Channel: %d\r\n",
>> +				alarm_str, i->channel);
>> +		} while (0);
>>  		/* fall thru intentionally */
>>  	case ZT_EVENT_ONHOOK:
>>  		if (i->radio)
>>     
>
>   



More information about the asterisk-dev mailing list