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@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@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@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@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
Pd-dev mailing list Pd-dev@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