[PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
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 g...@g.org To: dmotd inaudi...@simplesuperlativ.es CC: fl...@g.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 D -MT libflext_pd_la-flitem.lo -MD -MP -MF .deps/libflext_pd_la-flitem.Tpo -c fl item.cpp -DDLL_EXPORT -DPIC -o .libs/libflext_pd_la-flitem.o libtool: compile: g++ -DPACKAGE_NAME=\flext\ -DPACKAGE_TARNAME=\flext\ -DPA CKAGE_VERSION=\0.5.1\ -DPACKAGE_STRING=\flext 0.5.1\ -DPACKAGE_BUGREPORT=\ g...@g.org\ -DPACKAGE_URL=\\ -DPACKAGE=\flext\ -DVERSION=\0.5.1\ -DFLE XT_SYS=2 -DNT=1 -DWIN32=1 -D_WINDOWS=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DH AVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ST RINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H =1 -DLT_OBJDIR=\.libs/\ -I. -mno-cygwin -O2 -I/cygdrive/c/pd/src -DFLEXT_SHARE D -MT libflext_pd_la-flitem.lo -MD -MP -MF .deps/libflext_pd_la-flitem.Tpo -c fl item.cpp -o libflext_pd_la-flitem.o /dev/null 21 mv -f .deps/libflext_pd_la-flitem.Tpo .deps/libflext_pd_la-flitem.Plo /bin/sh ../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\flext\ -DPA CKAGE_TARNAME=\flext\ -DPACKAGE_VERSION=\0.5.1\ -DPACKAGE_STRING=\flext\ 0. 5.1\ -DPACKAGE_BUGREPORT=\g...@g.org\ -DPACKAGE_URL=\\ -DPACKAGE=\flext\ -DVERSION=\0.5.1\ -DFLEXT_SYS=2 -DNT=1 -DWIN32=1 -D_WINDOWS=1 -DSTDC_HEADERS =1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAV E_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I.-mno-cygwin -O2 -I/ cygdrive/c/pd/src -DFLEXT_SHARED -MT libflext_pd_la-flmeth.lo -MD -MP -MF .deps /libflext_pd_la-flmeth.Tpo -c -o libflext_pd_la-flmeth.lo `test -f 'flmeth.cpp' || echo './'`flmeth.cpp libtool: compile: g++ -DPACKAGE_NAME=\flext\ -DPACKAGE_TARNAME=\flext\ -DPA CKAGE_VERSION=\0.5.1\ -DPACKAGE_STRING=\flext 0.5.1\ -DPACKAGE_BUGREPORT=\ g...@g.org\ -DPACKAGE_URL=\\ -DPACKAGE=\flext\ -DVERSION=\0.5.1\ -DFLE XT_SYS=2 -DNT=1 -DWIN32=1 -D_WINDOWS=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DH AVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ST RINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H =1 -DLT_OBJDIR=\.libs/\ -I. -mno-cygwin -O2 -I/cygdrive/c/pd/src -DFLEXT_SHARE D -MT libflext_pd_la-flmeth.lo -MD -MP -MF .deps/libflext_pd_la-flmeth.Tpo -c fl meth.cpp -DDLL_EXPORT -DPIC -o .libs/libflext_pd_la-flmeth.o libtool: compile: g++ -DPACKAGE_NAME=\flext\ -DPACKAGE_TARNAME=\flext\ -DPA CKAGE_VERSION=\0.5.1\ -DPACKAGE_STRING=\flext 0.5.1\ -DPACKAGE_BUGREPORT=\ g...@g.org\ -DPACKAGE_URL=\\ -DPACKAGE=\flext\ -DVERSION=\0.5.1\ -DFLE XT_SYS=2 -DNT=1 -DWIN32=1 -D_WINDOWS=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DH AVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ST RINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H =1 -DLT_OBJDIR=\.libs/\ -I. -mno-cygwin -O2 -I/cygdrive/c/pd/src -DFLEXT_SHARE D -MT libflext_pd_la-flmeth.lo -MD -MP -MF .deps/libflext_pd_la-flmeth.Tpo -c fl meth.cpp -o libflext_pd_la-flmeth.o /dev/null 21 mv
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
'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 g...@g.org To: dmotd inaudi...@simplesuperlativ.es CC: fl...@g.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.txtflext-build-cygwin.txtflext-build- mingw.txt___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
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~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
On 04/05/2011 03:52 AM, martin.pe...@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. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
