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
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc).
.hc
On Apr 4, 2011, at 9:33 AM, 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 <flext-autotools-cygwin.txt><flext-build-cygwin.txt><flext-build- mingw.txt>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
kill your television
On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote:
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc).
.hc
yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out..
it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively).
-dmotd
Am 04.04.2011 um 17:46 schrieb dmotd:
On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote:
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc).
.hc
yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out..
it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively).
the problem is caused only by the global data defined in the pd.dll (garray_class, s_float, etc.) not by function protoypes
gr~~~
On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote:
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc).
.hc
yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out..
it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively).
the problem is caused only by the global data defined in the pd.dll (garray_class, s_float, etc.) not by function protoypes
gr~~~
I keep running into that. I think you have to #define MSW so this bit of m_pd.h gets included:
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */
Martin
On 04/05/2011 03:52 AM, martin.peach@sympatico.ca wrote:
On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote:
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc).
.hc
yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out..
it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively).
the problem is caused only by the global data defined in the pd.dll (garray_class, s_float, etc.) not by function protoypes
gr~~~
I keep running into that. I think you have to #define MSW so this bit of m_pd.h gets included:
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */
Martin
i saw that too, and i can confirm MSW is definitely defined. afaik the '__imp_' prefix in the problem references is also a sign that that __declspec(dllimport) has been declared.
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
the bottom line, mingw + autotools is some kinda headache! so where to now?
Hi, doesn't the pd build system use mingw and autotools? It must have the same problems, or a solution for it, no? gr~~~
On Apr 8, 2011, at 2:08 PM, Thomas Grill wrote:
the bottom line, mingw + autotools is some kinda headache! so where to now?
Hi, doesn't the pd build system use mingw and autotools? It must have the same problems, or a solution for it, no? gr~~~
mingw and autotools seems to work fine for things like zexy, OSCx, etc. Plus all the of the libs that Pd-extended uses are built on MinGW.
.hc
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
Hi, doesn't the pd build system use mingw and autotools? It must have the same problems, or a solution for it, no? gr~~~
mingw and autotools seems to work fine for things like zexy, OSCx, etc. Plus all the of the libs that Pd-extended uses are built on MinGW.
.hc
the original post specifically detailed issues with libtool, none of those externals use libtool for building shared libs, so i guess it hasn't been encountered. the only library i can see to use it is gfsm and a look at the mingw autobuild log shows that it is breaking (though not for the same reason).
if libtool isn't necessary on any platform, then i will look into removing it from the flext autotools set and recommend that people avoid it in the future.
so yes, they 'seem to work' because they have never encountered the same set of circumstances.
and the source of my original problem, milllers pd.dll breaking the gnu linker likely will effect building other libs under mingw.
perhaps 'mingw + libtool is some kind of headache' would be a more explicit byline - though libtool is still considered part of the 'autotools' set last time i looked.
-
dmotd -
Hans-Christoph Steiner -
martin.peach＠sympatico.ca -
Thomas Grill