[PD-dev] Problem Compiling Ratts on Cygwin

[Bryan Jurish]

moin Daniel, moin list

... cc'ing this message to pd-dev, as discussed ...

for those of you listers who may have missed the beginning of this
discussion (e.g. pretty much all of you), we're trying to get [ratts]
built on a windoof box, without much success.  not being a windoof user
myself, i'd appreciate any tips anyone could offer regarding external
compilation on such machines; in particular CFLAGS, LDFLAGS, LIBS, etc
etc... some relevant snippets of the discussion to date follow...

On 2008-06-29 01:00:15, "daniel c. howe" <dhowe at mrl.nyu.edu> appears to
have written:
> Bryan Jurish wrote:
>> moin Daniel,
>>
>> it just occurred to me that pd builds on cygwin are notoriously
>> difficult: did you actually get pd to build and run?  Quoting from
>> http://puredata.info/docs/developer/WindowsXPI386 :
>>> Pd doesn't build in Cygwin. You have to use MSYS.
> nope, wasnt able to get it to build via cygwin... so just running a
> binary so far

hmm, where did you get the binary?  are you sure it wasn't built e.g.
with MSYS (or worse yet with MSVC) and not with cygwin at all?

for msys builds i could potentially try out some of these hacks myself
on the pd build farm machine: are you maybe running a pd-extended build?

>> at any rate, assuming you got pd built on cygwin, it would help to know
>> how the "standard" externals got built (a make log from pd/src and
>> especially pd/extra would be helpful here): this should give us a good
>> idea of the flags used.

... again, for msys builds, we could probably lift the relevant flags
from the pd-extended build system.

> same error after running autogen:
> ==================================
> ratts.c:1: warning: -fPIC ignored for target (all code is position
> independent)

ok, we can leave out -fPIC, but it shouldn't hurt to leave it in...

> gcc -O2 -fno-strict-aliasing -fPIC -Wall -Winline     -o ratts.dll
> -export_dynam
> ic -shared parwave.o klatt_frame.o elements.o squeue.o dsqueue.o
> rholmes.o phfea
> t.o pd_holmes.o alhash.o phtoelm.o pd_phtoelm.o darray.o phoneutils.o
> trie.o tex
> t.o english.o saynum.o ratts_keyval.o suspect.o ASCII.o klatt~.o
> holmes.o holmes
> -feat.o holmes-mask.o phones2holmes.o guessphones.o number2text.o
> rattshash.o ra
> ttstok.o toupper.o spellout.o ratts.o
> klatt_frame.o:klatt_frame.c:(.text+0x19): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x2a): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x3b): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x4c): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x5d): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x6e): more undefined references to
> `_gensym'
>  follow
> klatt_frame.o:klatt_frame.c:(.text+0x304): undefined reference to `_error'

same ol' linker error, likely due to missing linker flags (e.g.
"-export_dynamic -shared" for linux externals)

>>>>  ... whatever cygwin builds call pd externals (what's
>>>> the extension of e.g. $PD_ROOT/extra/expr.* ?).  
>>> ====================================
>>> dhowe at wonderdog /cygdrive/c/pd
>>> $ ls extra/expr*
>>> extra/expr-help.pd  extra/expr.dll  extra/expr~.dll
>>>
>>> extra/expr~:
>>> LICENSE.txt  makefile  vexp.lib         vexp_fun.obj        
>>> vexp_if.pd_linux_o
>>> README.txt   vexp.c    vexp.obj         vexp_fun.pd_linux_o
>>> expr.dll     vexp.exp  vexp.pd_linux_o  vexp_if.c
>>> fts_to_pd.h  vexp.h    vexp_fun.c       vexp_if.obj
>>
>> odd... looks like you've got both .dll and .lib. afaik, .lib is a static
>> library and .dll a dynamic one.  pd externals are (at least on linux and
>> osx) dynamic libraries: i'm guessing .dll is the way to go...

anyone on the list know why both .lib and .dll get built on windoof?
also, what the heck are the .pd_linux_o files we're seeing here?

>>>> afaik, pd (vanilla) doesn't build or require any libraries (except maybe
>>>> "-lm").  i don't use pd-extended, so i can't tell you there... if there
>>>> are any global pd libraries, you'll probably need to link them in.  
>>> these are the libs I find in pd:
>>> ===============================
>>> dhowe at wonderdog /cygdrive/c/pd
>>> $ find . -name *.lib -print
>>> ./bin/asiolib.lib
>>> ./bin/pd.lib
>>> ./bin/pdtcl.lib
>>> ./bin/pthreadVC.lib
>>> ./bin/tcl84.lib
>>> ./bin/tclstub84.lib
>>> ./bin/tk84.lib
>>> ./bin/tkstub84.lib
>>> ./extra/bonk~/bonk~.lib
>>> ./extra/choice/choice.lib
>>> ./extra/expr~/vexp.lib
>>> ./extra/fiddle~/fiddle~.lib
>>> ./extra/loop~/loop~.lib
>>> ./extra/lrshift~/lrshift~.lib
>>> ./extra/pique/pique.lib
>>> ./extra/sigmund~/sigmund~.lib
>>> ./lib/asio/asiolib.lib
>>> ./src/pthreadVC.lib
>> 	
>> ... so you might need to link in any or all of the libs in bin/ ...
>> getting the order right could be tricky though.  in general, gcc likes
>> "highest-level" libraries left-most in the list. my guess would be
>> something like "-lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84 -ltclstub84
>> -lasiolib -lpthreadVC" ... but I might be wrong.
>>
> I seem to get that same error no matter what order I use... though if I
> add a non-existent library,
> it chokes on that... also if I add pd.lib as the last argument, I get a
> different msg, but adding the
> others doesn't help:

addendum: it's probably best to add "-l" flags (aka $LIBS) at the *end*
of the linker command line: "gcc $LDFLAGS -o $OUTFILE $OBJS $LIBS".
also, i see no reason why we ought to need to link in both the .lib and
the .dll : linking in the .dll ought to be enough, if I'm not mistaken.

> $gcc  -L/cygdrive/c/pd/bin -lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84
> -ltclstub84 -la
> siolib -lpthreadVC -Wall -Winline -o ratts.dll  parwave.o klatt_frame.o
> elements
> .o squeue.o dsqueue.o rholmes.o phfeat.o pd_holmes.o alhash.o phtoelm.o
> pd_phtoe
> lm.o darray.o phoneutils.o trie.o text.o english.o saynum.o
> ratts_keyval.o suspe
> ct.o ASCII.o klatt~.o holmes.o  holmes-feat.o holmes-mask.o
> phones2holmes.o gues
> sphones.o number2text.o rattshash.o rattstok.o toupper.o spellout.o
> ratts.o /cyg
> drive/c/pd/bin/pd.lib /cygdrive/c/pd/bin/pdtcl.lib
> /cygdrive/c/pd/bin/tk84.lib
> /cygdrive/c/pd/bin/tkstub84.lib /cygdrive/c/pd/bin/tcl84.lib
> /cygdrive/c/pd/bin/
> asiolib.lib  /cygdrive/c/pd/bin/pthreadVC.lib
> 
> klatt~.o:klatt~.c:(.text+0x357): undefined reference to `_s_signal'
> klatt~.o:klatt~.c:(.text+0x35f): undefined reference to `_s_bang'
> klatt~.o:klatt~.c:(.text+0x713): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x5c): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x70): undefined reference to `_s_bang'
> holmes.o:holmes.c:(.text+0x283): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x3df): undefined reference to `_s_list'
> holmes-feat.o:holmes-feat.c:(.text+0x3b): undefined reference to `_s_list'
> holmes-feat.o:holmes-feat.c:(.text+0xd9): undefined reference to `_s_list'
> holmes-mask.o:holmes-mask.c:(.text+0x7a): undefined reference to `_s_list'
> holmes-mask.o:holmes-mask.c:(.text+0x3c2): more undefined references to
> `_s_list
> ' follow
> ...

ok, so it looks like we're getting at least the functions resolved by
the linker (no more complaints about gensym()), but the constant symbols
still aren't getting resolved... ideas, anyone?

marmosets,
	Bryan

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology