[PD-dev] Problem Compiling Ratts on Cygwin

[Hans-Christoph Steiner]

Check out trunk/externals/Makefile, that's where the stuff is for  
building Pd-extended on MinGW.  By the linker errors, it looks like  
you are not linking to the pd.dll.

.hc

On Jun 30, 2008, at 10:56 AM, Bryan Jurish wrote:

> 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
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



------------------------------------------------------------------------ 
----

As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.         - Benjamin Franklin