[asterisk-dev] Can't compile Ast 10

[Mark Michelson]

On 06/14/2012 10:22 AM, Pavel Troller wrote:
>> On 06/14/2012 10:05 AM, Pavel Troller wrote:
>>> Hi!
>>>     I've decided to give Asterisk 10 a try (normally I'm on 1.8), but I cannot
>>> compile it successfully.
>>>     The problem is:
>>> root at arcus:/usr/src/voip/asterisk/asterisk-10# make
>>>      [LD] abstract_jb.o acl.o alaw.o aoc.o app.o ast_expr2.o ast_expr2f.o asterisk.o astfd.o astmm.o astobj2.o audiohook.o autochan.o autoservice.o bridging.o callerid.o ccss.o cdr.o cel.o channel.o chanvars.o cli.o config.o data.o datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o enum.o event.o features.o file.o fixedjitterbuf.o format.o format_cap.o format_pref.o frame.o framehook.o fskmodem.o global_datastores.o hashtab.o heap.o http.o image.o indications.o io.o jitterbuf.o loader.o lock.o logger.o manager.o md5.o message.o netsock.o netsock2.o pbx.o plc.o poll.o privacy.o rtp_engine.o say.o sched.o security_events.o sha1.o slinfactory.o srv.o ssl.o stdtime/localtime.o strcompat.o strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o term.o test.o threadstorage.o timing.o translate.o udptl.o ulaw.o utils.o version.o xml.o xmldoc.o editline/libedit.a  ->   asterisk
>>> features.o: In function `park_call_full':
>>> /usr/src/voip/asterisk/asterisk-10/main/features.c:1570: undefined reference to `ast_adsi_available'
>>> features.o: In function `adsi_announce_park':
>>> /usr/src/voip/asterisk/asterisk-10/main/features.c:1037: undefined reference to `ast_adsi_load_session'
>>> /usr/src/voip/asterisk/asterisk-10/main/features.c:1040: undefined reference to `ast_adsi_print'
>>> features.o: In function `park_call_full':
>>> /usr/src/voip/asterisk/asterisk-10/main/features.c:1572: undefined reference to `ast_adsi_unload_session'
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [asterisk] Error 1
>>> make: *** [main] Error 2
>>>
>>>     Things like undefined references are obviously easy to fix, because it
>>> usually requires just some Makefile fine tuning, but in this case, I failed.
>>> The reason is that the symbols are required by the core (static) binary
>>> module features.o, but they are declared in a dynamic module res_adsi.so
>>> (which is enabled and has been successfully built prior the final link).
>>> Because these modules are not used as real dynamic libraries (i.e. loaded
>>> by the dynamic linker during the app startup), but loaded under the control
>>> of the Asterisk core, I believe that inserting res_adsi.so (or res_adsi.o)
>>> to the list of object modules to be linked is not a clean way to fix the
>>> problem.
>>>     It's the today SVN branch.
>>>     Any hints ? What I'm doing wrong ?
>>>
>>> With regards, Pavel
>> The compilation failure is due to revision 368885 of the 10 branch. It
>> turns out that the fix worked for gcc 4.5 but that gcc 4.6 has the linking
>> problems. I'm working on a fix now.
>>
>> Mark Michelson
>>
> Hi Mark,
>    thank you for a really quick response!
>    OK, I'll give it a rest and I'll try it after I see an SVN update bringing
> something interesting :-).
>    With regards,
>      Pavel
I have temporarily reverted the offensive change since the issue it was 
trying to fix is much minor than a linking error. The "real" fix for the 
original issue will likely require some more time and thought. If you 
update to revision 368928 of Asterisk 10, it should build properly for you.

Mark Michelson