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" <[EMAIL PROTECTED]> > 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.* ?). >>>> ==================================== >>>> [EMAIL PROTECTED] /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: >>>> =============================== >>>> [EMAIL PROTECTED] /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." > [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic > Entomology > > > _______________________________________________ > Pd-dev mailing list > [email protected] > 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 _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
