i decided to build pure-data from scratch to see how a mingw derived dll would change things. i had to clean up the autotools scripts to get anything to build and added some new methods to build the dll and link to pd.exe. so pd now builds with autotools on mingw with minimal kludge.
the new mingw based pd.dll seems to have cleaned up the undefined references with the flext lib. so there is obviously an incompatibility between millers pd.dll (msvc?) and the mingw g++ linker. does this occur with gem too?
now for some hairy issues with libtool.. libtool has it's own namespace search globbing facility for finding libraries, and naturally doesn't want to find a library without a 'lib' prefix. this is contrary to gnu ld, which will search for both libfoo and foo when -lfoo is specified. to change this behaviour you have to specify the libname_spec variable from: --- libname_spec="lib$name" --- to: --- libname_spec="$name" --- without this change libtool can't find pd.dll and building of shared externals will break: --- *** Warning: linker path does not have real file for library -lpd. *** I have the capability to make that library automatically link in whe *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpd but no candidates were found. (...for file magic test) --- but after the change the opposite is true and libs with a 'lib' prefix will be ignored. i have no idea how this can't be more commonplace, but i've struggled to find anything much about this on the net, aside from a bit of autoconf kludge in an apache module to workaround: --- https://issues.apache.org/jira/browse/COUCHDB-440?page=com.atlassian.jira.pl... --- referencing: --- https://svn.apache.org/repos/asf/couchdb/trunk/configure.ac --- i guess that libtool is not particularly popular on windows for these reasons! another workaround may be distributing our own patched libtool.m4.
i'll submit a patch for pd autotools to the bugtracker when i've cleaned up my code and confirmed it doesn't break anything in osx/linux..
the good news is that i now have a flext lib for pd built in mingw and tested this against my autotools build scripts for vasp. vasp runs in millers pd distribution and the mingw build i compiled against.
the bottom line, mingw + autotools is some kinda headache! so where to now?
cheers, dmotd
On 04/04/2011 11:33 PM, dmotd wrote:
fwd'd from flext list..
background: i've been working on a new autotools template for flext based libs and started testing on windows platform with cygwin + mingw, immediate issues with building flext lib itself.
have any pd-devs experienced this 'undefined reference' issue with the linker?
i'm testing against millers pd-0.43-0.msw.zip on win2k and winxp virtualbox images. build logs attached.
cheers, dmotd
-------- Original Message -------- Subject: Re: [flext] autotools builders - flext and gnu/windows Date: Mon, 4 Apr 2011 14:27:52 +0200 From: Thomas Grill gr@grrrr.org To: dmotd inaudible@simplesuperlativ.es CC: flext@grrrr.org
hi dmotd, many thanks for your efforts,
mingw (gcc 4.5.2): with both your buildsys (cmd prompt) and autoconf (msys shell), mingw will build all the static libs, but fails at the linker stage when building the dynamic library, with a bunch of undefined references (see attachment).
i have attempted to encourage the build further by passing linker flags (-Wl,--as-needed and -Wl,--no-undefined *plus numerous others/ combinations*) but nothing seems to make it budge. i'm not sure if the compiler is being pedantic or i'm just not understanding something.
I can remember that problem - it is connected to the way how global variables (like garray_class, s_float etc.) in Pd are defined for the linker. I must have found a solution once....
cygwin (gcc 3.4.4) cygwin breaks with your buildsys due to what appears to be an issue with the environment (see attachment). with autoconf it acts much like mingw - it can successfully build static libs but fails to make the shared dll, a few more undefined references than with mingw (see attachment).
The flext-build output seems to indicate a c++ namespace problem which should not be too hard to fix. The autoconf output seems different, probably a mixture of problems.
i'm not sure if i can spare any time for that soon but it's good to know the weak spots.
all the best, Thomas
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev