Fixing Amitwitter

2 posts / 0 new
Last post
tekmage
tekmage's picture
Offline
Last seen: 2 years 2 weeks ago
Joined: 2011-10-09 03:19
Fixing Amitwitter

Hi All,

Run AmiTwitter for the first time and saw the basic auth error. Looking at the bug list I see a suggestion to use liboath for the authentication. I stuck trying to get an initial compile so I can start to mess with the code. Here is the error:

make
ppc-amigaos-gcc -c amitwitter.c -o amitwitter.o -s -O2 -I./include -I../include -I./include/os4 -I/SDK/codesets/include -I /sdk/local/common/include/libxml2 -I/SDK/MUI/C/include -mcrt=newlib -fomit-frame-pointer -funroll-loops -mcpu=powerpc -mstring -mmultiple -fstrict-aliasing -D__USE_INLINE__ -D__USE_BASETYPE__ -D__USE_OLD_TIMEVAL__ -Wall -Wno-pointer-sign -mregnames
amitwitter.c: In function 'charconv':
amitwitter.c:693: warning: 'AllocMem' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:45)
amitwitter.c: In function 'my_byte_array_new':
amitwitter.c:750: warning: 'AllocVec' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:47)
amitwitter.c: In function 'my_byte_array_append':
amitwitter.c:773: warning: 'AllocVec' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:47)
amitwitter.c: In function 'twitter_parse_statuses_node':
amitwitter.c:1322: warning: 'AllocVec' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:47)
amitwitter.c: In function 'twitter_parse_statuses_node_dirmsg':
amitwitter.c:1354: warning: 'AllocVec' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:47)
amitwitter.c: In function 'twitter_parse_statuses_node_dirmsgrcvd':
amitwitter.c:1386: warning: 'AllocVec' is deprecated (declared at /SDK/include/include_h/interfaces/exec.h:47)
ppc-amigaos-gcc -use-dynld -L/SOBJS amitwitter.o -o AmiTwitter_OS4 -lauto -lcurl-7.16 -lxml2 -ldl -lssl-0.9.8 -lpthread -lz -rpath/sobjs/
ld: warning: libz.so, needed by /SOBJS/libcurl-7.16.so, not found (try using -rpath or -rpath-link)

dir sobjs:
libao.so libbz2.so libbz2.so.1.0
libbz2.so.1.0.4 libc.so libcairo.so libcrypto.so
libcrypto.so.1.0.0 libcss.so.0 libcurl-7.16.so libcurl.so.7
libdl.so libexpat.so libFLAC++.so libFLAC.so
libfontconfig.so libfreetype.so libgcc.so libgcov.so
libiconv.so libicudata-3.4.so libicuuc-3.4.so libintl.so
libjpeg.so libjpeg.so.11 libjpeg.so.8 libmikmod.so
liboauth.so libogg.so libogg.so.8 libpixman-1.so
libpng.so libpng12.so libpthread.so libpython25.so
librtmp.so.0 libSDL-1.2.so libSDL-1.2.so-os4.1 libSDL_gfx.so
libSDL_mixer-1.2.so libsmpeg-0.4.so libsqlite3.so libssl-0.9.8.so
libssl.so libssl.so.1.0.0 libstdc++.so libsvgtiny.so.0
libtiff.so.3 libvorbis.so libvorbis.so.4 libvorbisenc.so
libvorbisenc.so.2 libvorbisfile.so libvorbisfile.so.6 libwapcaplet.so.0
libxml2-2.6.so libxml2.so libxml2.so.9 libxslt-1.1.so
libxslt.so libz.so libz.so.1
libz.so.1.2 libz.so.1.2.3

libz.so is there... Any thoughts?

Thanks,
Bill "tekmage" Borsari

kas1e
kas1e's picture
Offline
Last seen: 3 months 4 days ago
Joined: 2010-11-30 15:30
Are you sure that you want to

Are you sure that you want to build it with .so usage ? Imho better to build static version , so you for first will have no problems with .sobjs at all, and for second you will have fix your problems because of that (for making static version, you need to remove -use-dynld from linkin line, and replace it with -static instead). Using of .so are necessary only when its indeed necessary (like some heavy-heavy port, which is hard to rewrite).

But if you by some reassons still want to build version which will depends on .sobjs then you need to be sure that necessary .so also placed in the SDK itself (or you provide correct path). Thats what i have in my SDK:

  1. shell:> ls -la work:sdk/local/newlib/lib/libz.so
  2. work:sdk/local/newlib/lib/libz.so -> /System/SObjs/libz.so.1.2.5
Log in or register to post comments