From: Sultan S. <jav...@gm...> - 2011-12-18 04:42:49
|
Hello, I'm trying to build a small jni dll with mingw gcc and am having trouble during the linking step of the build. The linker command is thus: /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 build/gl2ps.o build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll Here is a list of undefined symbols from the individual object files: $ nm -C -u build/gl2ps.o U _imp___iob U cos U ctime U destroyEPSOutput U fflush U fprintf U fputc U free U fwrite U getEPS U getFontDefinitionsMemSize U glBegin@4 U glBitmap@28 U glEnd@0 U glFeedbackBuffer@12 U glGetBooleanv@8 U glGetFloatv@8 U glGetIntegerv@8 U glIsEnabled@4 U glPassThrough@4 U glRenderMode@4 U glVertex3f@12 U gmtime U log10 U malloc U popFontDefinitions U pow U qsort U realloc U sin U sprintf U sqrt U strcpy U strncpy U time U vfprintf $ nm -C -u build/gl2psjni.o U fopen U free U gl2psBeginPage U gl2psBeginViewport U gl2psBlendFunc U gl2psDisable U gl2psDrawPixels U gl2psEnable U gl2psEndPage U gl2psEndViewport U gl2psGetFileExtension U gl2psGetFormat U gl2psGetFormatDescription U gl2psGetOptions U gl2psLineWidth U gl2psMathML U gl2psMathMLFooter U gl2psMathMLHeader U gl2psPointSize U gl2psSetOptions U gl2psSpecial U gl2psText U gl2psTextOpt U malloc U printf U puts $ nm -C -u build/mathml2ps.o U _Unwind_Resume U std::string::find_last_not_of(char const*, unsigned int) const U std::string::data() const U std::string::find(char const*, unsigned int) const U std::string::find(std::string const&, unsigned int) const U std::string::size() const U std::string::c_str() const U std::string::length() const U std::string::substr(unsigned int, unsigned int) const U std::string::compare(char const*) const U std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::str() const U std::allocator<char>::allocator() U std::allocator<char>::~allocator() U std::string::erase(unsigned int, unsigned int) U std::string::append(std::string const&) U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() U std::string::operator=(std::string const&) U std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) U std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream() U std::ios_base::Init::Init() U std::ios_base::Init::~Init() U std::__throw_bad_alloc() U std::__throw_length_error(char const*) U operator delete(void*) U operator new(unsigned int) U __cxa_begin_catch U __cxa_end_catch U __cxa_rethrow U __gxx_personality_v0 U _assert U _imp___ZN10MathViewNS10fileExistsEPKc U _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE U _imp___ZN12FontDataBase6createEv U _imp___ZN13Configuration16getBinaryVersionEv U _imp___ZN13Configuration21getConfigurationPathsEv U _imp___ZN13ConfigurationC1Ev U _imp___ZN14AbstractLoggerC2Ev U _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb U _imp___ZN16libxml2_MathView10loadBufferEPKc U _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs U _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs U _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE U _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE U _imp___ZN17FormattingContextD1Ev U _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE U _imp___ZN24MathMLOperatorDictionaryC1Ev U _imp___ZN25PS_StreamRenderingContext11documentEndEv U _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc U _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE U _imp___ZN25PS_StreamRenderingContextD1Ev U _imp___ZN4View16resetRootElementEv U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE U _imp___ZN4View18setDefaultFontSizeEj U _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE U _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE U _imp___ZN4View27getDefaultConfigurationPathEv U _imp___ZN4View32getDefaultOperatorDictionaryPathEv U _imp___ZNK13Configuration13getStringListERKSs U _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi U _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz U _imp___ZNK4View14getBoundingBoxEv U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ U _imp___ZTV6Logger U atexit U free U malloc U strcat U strcpy U strdup U strncpy U strtof U strtok What is very confusing is all the undefined references from the stdc++ library and standard C functions (malloc, strcat etc). I must be missing something, because there are also undefined references even between these objects. For instance, gl2psjni.o has undefined references that *should* be there from gl2ps.o (gl2psBeginPage, gl2psBeginViewport etc). Any insights would be greatly appreciated, and many thanks in advance for taking the time to read this. -Sultan. |
From: xunxun <xun...@gm...> - 2011-12-18 04:51:15
|
Using mingw32-g++ please On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> wrote: > Hello, > > I'm trying to build a small jni dll with mingw gcc and am having trouble > during the linking step of the build. > > The linker command is thus: > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 build/gl2ps.o > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll > > Here is a list of undefined symbols from the individual object files: > $ nm -C -u build/gl2ps.o > U _imp___iob > U cos > U ctime > U destroyEPSOutput > U fflush > U fprintf > U fputc > U free > U fwrite > U getEPS > U getFontDefinitionsMemSize > U glBegin@4 > U glBitmap@28 > U glEnd@0 > U glFeedbackBuffer@12 > U glGetBooleanv@8 > U glGetFloatv@8 > U glGetIntegerv@8 > U glIsEnabled@4 > U glPassThrough@4 > U glRenderMode@4 > U glVertex3f@12 > U gmtime > U log10 > U malloc > U popFontDefinitions > U pow > U qsort > U realloc > U sin > U sprintf > U sqrt > U strcpy > U strncpy > U time > U vfprintf > $ nm -C -u build/gl2psjni.o > U fopen > U free > U gl2psBeginPage > U gl2psBeginViewport > U gl2psBlendFunc > U gl2psDisable > U gl2psDrawPixels > U gl2psEnable > U gl2psEndPage > U gl2psEndViewport > U gl2psGetFileExtension > U gl2psGetFormat > U gl2psGetFormatDescription > U gl2psGetOptions > U gl2psLineWidth > U gl2psMathML > U gl2psMathMLFooter > U gl2psMathMLHeader > U gl2psPointSize > U gl2psSetOptions > U gl2psSpecial > U gl2psText > U gl2psTextOpt > U malloc > U printf > U puts > $ nm -C -u build/mathml2ps.o > U _Unwind_Resume > U std::string::find_last_not_of(char const*, unsigned int) const > U std::string::data() const > U std::string::find(char const*, unsigned int) const > U std::string::find(std::string const&, unsigned int) const > U std::string::size() const > U std::string::c_str() const > U std::string::length() const > U std::string::substr(unsigned int, unsigned int) const > U std::string::compare(char const*) const > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::str() const > U std::allocator<char>::allocator() > U std::allocator<char>::~allocator() > U std::string::erase(unsigned int, unsigned int) > U std::string::append(std::string const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string(char const*, std::allocator<char> > const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string(std::string const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::~basic_string() > U std::string::operator=(std::string const&) > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::~basic_ostringstream() > U std::ios_base::Init::Init() > U std::ios_base::Init::~Init() > U std::__throw_bad_alloc() > U std::__throw_length_error(char const*) > U operator delete(void*) > U operator new(unsigned int) > U __cxa_begin_catch > U __cxa_end_catch > U __cxa_rethrow > U __gxx_personality_v0 > U _assert > U _imp___ZN10MathViewNS10fileExistsEPKc > U > _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE > U _imp___ZN12FontDataBase6createEv > U _imp___ZN13Configuration16getBinaryVersionEv > U _imp___ZN13Configuration21getConfigurationPathsEv > U _imp___ZN13ConfigurationC1Ev > U _imp___ZN14AbstractLoggerC2Ev > U > _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb > U _imp___ZN16libxml2_MathView10loadBufferEPKc > U > _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs > U > _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs > U _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE > U _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE > U _imp___ZN17FormattingContextD1Ev > U > _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE > U _imp___ZN24MathMLOperatorDictionaryC1Ev > U _imp___ZN25PS_StreamRenderingContext11documentEndEv > U > _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc > U > _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE > U _imp___ZN25PS_StreamRenderingContextD1Ev > U _imp___ZN4View16resetRootElementEv > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE > U _imp___ZN4View18setDefaultFontSizeEj > U > _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE > U > _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE > U _imp___ZN4View27getDefaultConfigurationPathEv > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv > U _imp___ZNK13Configuration13getStringListERKSs > U > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi > U > _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz > U _imp___ZNK4View14getBoundingBoxEv > U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ > U _imp___ZTV6Logger > U atexit > U free > U malloc > U strcat > U strcpy > U strdup > U strncpy > U strtof > U strtok > > What is very confusing is all the undefined references from the stdc++ > library and standard C functions (malloc, strcat etc). > > I must be missing something, because there are also undefined references > even between these objects. For instance, gl2psjni.o has undefined > references that *should* be there from gl2ps.o (gl2psBeginPage, > gl2psBeginViewport etc). > > Any insights would be greatly appreciated, and many thanks in advance for > taking the time to read this. > > -Sultan. > -- Best Regards, xunxun |
From: Sultan S. <jav...@gm...> - 2011-12-18 05:18:48
|
Yes, I contemplated that. The thing is that I'd really rather not rewrite one of the jni source files in C++. It's currently using the C implementation of the JNI api. It feels like I'm missing something obvious and important that will fix this problem for me. I'm hoping someone is able to point it out. -Sultan. On Sat, Dec 17, 2011 at 11:51 PM, xunxun <xun...@gm...> wrote: > Using mingw32-g++ please > > On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> > wrote: > > Hello, > > > > I'm trying to build a small jni dll with mingw gcc and am having trouble > > during the linking step of the build. > > > > The linker command is thus: > > > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 > build/gl2ps.o > > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll > > > > Here is a list of undefined symbols from the individual object files: > > $ nm -C -u build/gl2ps.o > > U _imp___iob > > U cos > > U ctime > > U destroyEPSOutput > > U fflush > > U fprintf > > U fputc > > U free > > U fwrite > > U getEPS > > U getFontDefinitionsMemSize > > U glBegin@4 > > U glBitmap@28 > > U glEnd@0 > > U glFeedbackBuffer@12 > > U glGetBooleanv@8 > > U glGetFloatv@8 > > U glGetIntegerv@8 > > U glIsEnabled@4 > > U glPassThrough@4 > > U glRenderMode@4 > > U glVertex3f@12 > > U gmtime > > U log10 > > U malloc > > U popFontDefinitions > > U pow > > U qsort > > U realloc > > U sin > > U sprintf > > U sqrt > > U strcpy > > U strncpy > > U time > > U vfprintf > > $ nm -C -u build/gl2psjni.o > > U fopen > > U free > > U gl2psBeginPage > > U gl2psBeginViewport > > U gl2psBlendFunc > > U gl2psDisable > > U gl2psDrawPixels > > U gl2psEnable > > U gl2psEndPage > > U gl2psEndViewport > > U gl2psGetFileExtension > > U gl2psGetFormat > > U gl2psGetFormatDescription > > U gl2psGetOptions > > U gl2psLineWidth > > U gl2psMathML > > U gl2psMathMLFooter > > U gl2psMathMLHeader > > U gl2psPointSize > > U gl2psSetOptions > > U gl2psSpecial > > U gl2psText > > U gl2psTextOpt > > U malloc > > U printf > > U puts > > $ nm -C -u build/mathml2ps.o > > U _Unwind_Resume > > U std::string::find_last_not_of(char const*, unsigned int) const > > U std::string::data() const > > U std::string::find(char const*, unsigned int) const > > U std::string::find(std::string const&, unsigned int) const > > U std::string::size() const > > U std::string::c_str() const > > U std::string::length() const > > U std::string::substr(unsigned int, unsigned int) const > > U std::string::compare(char const*) const > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::str() const > > U std::allocator<char>::allocator() > > U std::allocator<char>::~allocator() > > U std::string::erase(unsigned int, unsigned int) > > U std::string::append(std::string const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::basic_string(char const*, std::allocator<char> > > const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::basic_string(std::string const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::~basic_string() > > U std::string::operator=(std::string const&) > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::~basic_ostringstream() > > U std::ios_base::Init::Init() > > U std::ios_base::Init::~Init() > > U std::__throw_bad_alloc() > > U std::__throw_length_error(char const*) > > U operator delete(void*) > > U operator new(unsigned int) > > U __cxa_begin_catch > > U __cxa_end_catch > > U __cxa_rethrow > > U __gxx_personality_v0 > > U _assert > > U _imp___ZN10MathViewNS10fileExistsEPKc > > U > > > _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE > > U _imp___ZN12FontDataBase6createEv > > U _imp___ZN13Configuration16getBinaryVersionEv > > U _imp___ZN13Configuration21getConfigurationPathsEv > > U _imp___ZN13ConfigurationC1Ev > > U _imp___ZN14AbstractLoggerC2Ev > > U > > > _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb > > U _imp___ZN16libxml2_MathView10loadBufferEPKc > > U > > > _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs > > U > > > _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs > > U > _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE > > U > _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE > > U _imp___ZN17FormattingContextD1Ev > > U > > > _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE > > U _imp___ZN24MathMLOperatorDictionaryC1Ev > > U _imp___ZN25PS_StreamRenderingContext11documentEndEv > > U > > > _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc > > U > > > _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE > > U _imp___ZN25PS_StreamRenderingContextD1Ev > > U _imp___ZN4View16resetRootElementEv > > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE > > U _imp___ZN4View18setDefaultFontSizeEj > > U > > > _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE > > U > > > _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE > > U _imp___ZN4View27getDefaultConfigurationPathEv > > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv > > U _imp___ZNK13Configuration13getStringListERKSs > > U > > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi > > U > > _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ > > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId > > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz > > U _imp___ZNK4View14getBoundingBoxEv > > U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ > > U _imp___ZTV6Logger > > U atexit > > U free > > U malloc > > U strcat > > U strcpy > > U strdup > > U strncpy > > U strtof > > U strtok > > > > What is very confusing is all the undefined references from the stdc++ > > library and standard C functions (malloc, strcat etc). > > > > I must be missing something, because there are also undefined references > > even between these objects. For instance, gl2psjni.o has undefined > > references that *should* be there from gl2ps.o (gl2psBeginPage, > > gl2psBeginViewport etc). > > > > Any insights would be greatly appreciated, and many thanks in advance for > > taking the time to read this. > > > > -Sultan. > > > > > > > -- > Best Regards, > xunxun > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe -- -sultan |
From: Emanuel F. <E.F...@op...> - 2011-12-18 06:46:24
|
Hi, I'm not sure this could be of any help, but I have a pretty extensive palette of JNI DLLs and thy are ALL written in C++ and compiled with mingw32-g++ (and even its 64bit version, i.e. x86_64-w64-mingw32-g++)! The headers generated by Java are fully compatible with C++ (no idea why you would stick to C). Good luck, Emanuel De : Sultan Saini [mailto:jav...@gm...] Envoyé : Sunday, 18 December, 2011 06:19 À : MinGW Users List Objet : Re: [Mingw-users] Undefined references when linking with mingw32-gcc Yes, I contemplated that. The thing is that I'd really rather not rewrite one of the jni source files in C++. It's currently using the C implementation of the JNI api. It feels like I'm missing something obvious and important that will fix this problem for me. I'm hoping someone is able to point it out. -Sultan. On Sat, Dec 17, 2011 at 11:51 PM, xunxun <xun...@gm...> wrote: Using mingw32-g++ please On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> wrote: > Hello, > > I'm trying to build a small jni dll with mingw gcc and am having trouble > during the linking step of the build. > > The linker command is thus: > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 build/gl2ps.o > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll > > Here is a list of undefined symbols from the individual object files: > $ nm -C -u build/gl2ps.o > U _imp___iob > U cos > U ctime > U destroyEPSOutput > U fflush > U fprintf > U fputc > U free > U fwrite > U getEPS > U getFontDefinitionsMemSize > U glBegin@4 > U glBitmap@28 > U glEnd@0 > U glFeedbackBuffer@12 > U glGetBooleanv@8 > U glGetFloatv@8 > U glGetIntegerv@8 > U glIsEnabled@4 > U glPassThrough@4 > U glRenderMode@4 > U glVertex3f@12 > U gmtime > U log10 > U malloc > U popFontDefinitions > U pow > U qsort > U realloc > U sin > U sprintf > U sqrt > U strcpy > U strncpy > U time > U vfprintf > $ nm -C -u build/gl2psjni.o > U fopen > U free > U gl2psBeginPage > U gl2psBeginViewport > U gl2psBlendFunc > U gl2psDisable > U gl2psDrawPixels > U gl2psEnable > U gl2psEndPage > U gl2psEndViewport > U gl2psGetFileExtension > U gl2psGetFormat > U gl2psGetFormatDescription > U gl2psGetOptions > U gl2psLineWidth > U gl2psMathML > U gl2psMathMLFooter > U gl2psMathMLHeader > U gl2psPointSize > U gl2psSetOptions > U gl2psSpecial > U gl2psText > U gl2psTextOpt > U malloc > U printf > U puts > $ nm -C -u build/mathml2ps.o > U _Unwind_Resume > U std::string::find_last_not_of(char const*, unsigned int) const > U std::string::data() const > U std::string::find(char const*, unsigned int) const > U std::string::find(std::string const&, unsigned int) const > U std::string::size() const > U std::string::c_str() const > U std::string::length() const > U std::string::substr(unsigned int, unsigned int) const > U std::string::compare(char const*) const > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::str() const > U std::allocator<char>::allocator() > U std::allocator<char>::~allocator() > U std::string::erase(unsigned int, unsigned int) > U std::string::append(std::string const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string(char const*, std::allocator<char> > const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string(std::string const&) > U std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::~basic_string() > U std::string::operator=(std::string const&) > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) > U std::basic_ostringstream<char, std::char_traits<char>, > std::allocator<char> >::~basic_ostringstream() > U std::ios_base::Init::Init() > U std::ios_base::Init::~Init() > U std::__throw_bad_alloc() > U std::__throw_length_error(char const*) > U operator delete(void*) > U operator new(unsigned int) > U __cxa_begin_catch > U __cxa_end_catch > U __cxa_rethrow > U __gxx_personality_v0 > U _assert > U _imp___ZN10MathViewNS10fileExistsEPKc > U > _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13Configurat ionE > U _imp___ZN12FontDataBase6createEv > U _imp___ZN13Configuration16getBinaryVersionEv > U _imp___ZN13Configuration21getConfigurationPathsEv > U _imp___ZN13ConfigurationC1Ev > U _imp___ZN14AbstractLoggerC2Ev > U > _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13Confi gurationEb > U _imp___ZN16libxml2_MathView10loadBufferEPKc > U > _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerE RKS0_I13ConfigurationERKSs > U > _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLo ggerERKS0_I24MathMLOperatorDictionaryERKSs > U _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE > U _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE > U _imp___ZN17FormattingContextD1Ev > U > _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDev iceE > U _imp___ZN24MathMLOperatorDictionaryC1Ev > U _imp___ZN25PS_StreamRenderingContext11documentEndEv > U > _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11B oundingBoxPKc > U > _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I1 2FontDataBaseE > U _imp___ZN25PS_StreamRenderingContextD1Ev > U _imp___ZN4View16resetRootElementEv > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE > U _imp___ZN4View18setDefaultFontSizeEj > U > _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionary E > U > _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceConte xtE > U _imp___ZN4View27getDefaultConfigurationPathEv > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv > U _imp___ZNK13Configuration13getStringListERKSs > U > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi > U > _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz > U _imp___ZNK4View14getBoundingBoxEv > U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ > U _imp___ZTV6Logger > U atexit > U free > U malloc > U strcat > U strcpy > U strdup > U strncpy > U strtof > U strtok > > What is very confusing is all the undefined references from the stdc++ > library and standard C functions (malloc, strcat etc). > > I must be missing something, because there are also undefined references > even between these objects. For instance, gl2psjni.o has undefined > references that *should* be there from gl2ps.o (gl2psBeginPage, > gl2psBeginViewport etc). > > Any insights would be greatly appreciated, and many thanks in advance for > taking the time to read this. > > -Sultan. > -- Best Regards, xunxun ---------------------------------------------------------------------------- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:min...@li...?subject=unsubscribe -- -sultan |
From: Sultan S. <jav...@gm...> - 2011-12-18 06:57:19
|
@LRN, yes, I do have extern "C" wrappers in my headers. Thank you *very much* for your suggestion to switch around the arguments in the call to the linker - that seems to have cleaned up most of the problems (you have no idea how relieved I am at the moment - thank you). What remains appears to be straightforward missing __declspec macros (they must have been getting lost in the noise). @Emanuel, the only reason I didn't want to do the port is time constraints. However, even as I write this, I had pretty decided that that would have been my next step. Thanks for the speedy responses. You have made me a very happy camper today :-) -S. On Sun, Dec 18, 2011 at 1:19 AM, Emanuel Falkenauer < E.F...@op...> wrote: > Hi,**** > > ** ** > > I'm not sure this could be of any help, but I have a pretty extensive > palette of JNI DLLs… and thy are ALL written in C++ and compiled with > mingw32-g++ (and even its 64bit version, i.e. x86_64-w64-mingw32-g++)! The > headers generated by Java are fully compatible with C++ (no idea why you > would stick to C).**** > > ** ** > > Good luck,**** > > ** ** > > Emanuel**** > > ** ** > > *De :* Sultan Saini [mailto:jav...@gm...] > *Envoyé :* Sunday, 18 December, 2011 06:19 > *À :* MinGW Users List > *Objet :* Re: [Mingw-users] Undefined references when linking with > mingw32-gcc**** > > ** ** > > Yes, I contemplated that. The thing is that I'd really rather not rewrite > one of the jni source files in C++. It's currently using the C > implementation of the JNI api. It feels like I'm missing something obvious > and important that will fix this problem for me. I'm hoping someone is able > to point it out.**** > > ** ** > > -Sultan.**** > > On Sat, Dec 17, 2011 at 11:51 PM, xunxun <xun...@gm...> wrote:**** > > Using mingw32-g++ please**** > > > On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> > wrote: > > Hello, > > > > I'm trying to build a small jni dll with mingw gcc and am having trouble > > during the linking step of the build. > > > > The linker command is thus: > > > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 > build/gl2ps.o > > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll > > > > Here is a list of undefined symbols from the individual object files: > > $ nm -C -u build/gl2ps.o > > U _imp___iob > > U cos > > U ctime > > U destroyEPSOutput > > U fflush > > U fprintf > > U fputc > > U free > > U fwrite > > U getEPS > > U getFontDefinitionsMemSize > > U glBegin@4 > > U glBitmap@28 > > U glEnd@0 > > U glFeedbackBuffer@12 > > U glGetBooleanv@8 > > U glGetFloatv@8 > > U glGetIntegerv@8 > > U glIsEnabled@4 > > U glPassThrough@4 > > U glRenderMode@4 > > U glVertex3f@12 > > U gmtime > > U log10 > > U malloc > > U popFontDefinitions > > U pow > > U qsort > > U realloc > > U sin > > U sprintf > > U sqrt > > U strcpy > > U strncpy > > U time > > U vfprintf > > $ nm -C -u build/gl2psjni.o > > U fopen > > U free > > U gl2psBeginPage > > U gl2psBeginViewport > > U gl2psBlendFunc > > U gl2psDisable > > U gl2psDrawPixels > > U gl2psEnable > > U gl2psEndPage > > U gl2psEndViewport > > U gl2psGetFileExtension > > U gl2psGetFormat > > U gl2psGetFormatDescription > > U gl2psGetOptions > > U gl2psLineWidth > > U gl2psMathML > > U gl2psMathMLFooter > > U gl2psMathMLHeader > > U gl2psPointSize > > U gl2psSetOptions > > U gl2psSpecial > > U gl2psText > > U gl2psTextOpt > > U malloc > > U printf > > U puts > > $ nm -C -u build/mathml2ps.o > > U _Unwind_Resume > > U std::string::find_last_not_of(char const*, unsigned int) const > > U std::string::data() const > > U std::string::find(char const*, unsigned int) const > > U std::string::find(std::string const&, unsigned int) const > > U std::string::size() const > > U std::string::c_str() const > > U std::string::length() const > > U std::string::substr(unsigned int, unsigned int) const > > U std::string::compare(char const*) const > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::str() const > > U std::allocator<char>::allocator() > > U std::allocator<char>::~allocator() > > U std::string::erase(unsigned int, unsigned int) > > U std::string::append(std::string const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::basic_string(char const*, std::allocator<char> > > const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::basic_string(std::string const&) > > U std::basic_string<char, std::char_traits<char>, > > std::allocator<char> >::~basic_string() > > U std::string::operator=(std::string const&) > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) > > U std::basic_ostringstream<char, std::char_traits<char>, > > std::allocator<char> >::~basic_ostringstream() > > U std::ios_base::Init::Init() > > U std::ios_base::Init::~Init() > > U std::__throw_bad_alloc() > > U std::__throw_length_error(char const*) > > U operator delete(void*) > > U operator new(unsigned int) > > U __cxa_begin_catch > > U __cxa_end_catch > > U __cxa_rethrow > > U __gxx_personality_v0 > > U _assert > > U _imp___ZN10MathViewNS10fileExistsEPKc > > U > > > _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE > > U _imp___ZN12FontDataBase6createEv > > U _imp___ZN13Configuration16getBinaryVersionEv > > U _imp___ZN13Configuration21getConfigurationPathsEv > > U _imp___ZN13ConfigurationC1Ev > > U _imp___ZN14AbstractLoggerC2Ev > > U > > > _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb > > U _imp___ZN16libxml2_MathView10loadBufferEPKc > > U > > > _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs > > U > > > _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs > > U > _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE > > U > _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE > > U _imp___ZN17FormattingContextD1Ev > > U > > > _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE > > U _imp___ZN24MathMLOperatorDictionaryC1Ev > > U _imp___ZN25PS_StreamRenderingContext11documentEndEv > > U > > > _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc > > U > > > _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE > > U _imp___ZN25PS_StreamRenderingContextD1Ev > > U _imp___ZN4View16resetRootElementEv > > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE > > U _imp___ZN4View18setDefaultFontSizeEj > > U > > > _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE > > U > > > _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE > > U _imp___ZN4View27getDefaultConfigurationPathEv > > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv > > U _imp___ZNK13Configuration13getStringListERKSs > > U > > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi > > U > > _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ > > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId > > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz > > U _imp___ZNK4View14getBoundingBoxEv > > U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ > > U _imp___ZTV6Logger > > U atexit > > U free > > U malloc > > U strcat > > U strcpy > > U strdup > > U strncpy > > U strtof > > U strtok > > > > What is very confusing is all the undefined references from the stdc++ > > library and standard C functions (malloc, strcat etc). > > > > I must be missing something, because there are also undefined references > > even between these objects. For instance, gl2psjni.o has undefined > > references that *should* be there from gl2ps.o (gl2psBeginPage, > > gl2psBeginViewport etc). > > > > Any insights would be greatly appreciated, and many thanks in advance for > > taking the time to read this. > > > > -Sultan. > > > > > > **** > > -- > Best Regards, > xunxun > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > **** > > > > **** > > ** ** > > -- > -sultan**** > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- -sultan |
From: Sultan S. <jav...@gm...> - 2011-12-18 07:06:12
|
By the way, is this a known issue with MinGW gcc? Seems odd that the order of arguments to the compiler should cause a problem like this. (Forgive my naivete if this is a silly question - I'm a java developer, so I don't get to play in C/C++ that often.) -S. On Sun, Dec 18, 2011 at 1:57 AM, Sultan Saini <jav...@gm...> wrote: > @LRN, yes, I do have extern "C" wrappers in my headers. Thank you *very > much* for your suggestion to switch around the arguments in the call to the > linker - that seems to have cleaned up most of the problems (you have no > idea how relieved I am at the moment - thank you). What remains appears to > be straightforward missing __declspec macros (they must have been getting > lost in the noise). > > @Emanuel, the only reason I didn't want to do the port is time > constraints. However, even as I write this, I had pretty decided that that > would have been my next step. > > Thanks for the speedy responses. You have made me a very happy camper > today :-) > > -S. > > > On Sun, Dec 18, 2011 at 1:19 AM, Emanuel Falkenauer < > E.F...@op...> wrote: > >> Hi,**** >> >> ** ** >> >> I'm not sure this could be of any help, but I have a pretty extensive >> palette of JNI DLLs… and thy are ALL written in C++ and compiled with >> mingw32-g++ (and even its 64bit version, i.e. x86_64-w64-mingw32-g++)! The >> headers generated by Java are fully compatible with C++ (no idea why you >> would stick to C).**** >> >> ** ** >> >> Good luck,**** >> >> ** ** >> >> Emanuel**** >> >> ** ** >> >> *De :* Sultan Saini [mailto:jav...@gm...] >> *Envoyé :* Sunday, 18 December, 2011 06:19 >> *À :* MinGW Users List >> *Objet :* Re: [Mingw-users] Undefined references when linking with >> mingw32-gcc**** >> >> ** ** >> >> Yes, I contemplated that. The thing is that I'd really rather not rewrite >> one of the jni source files in C++. It's currently using the C >> implementation of the JNI api. It feels like I'm missing something obvious >> and important that will fix this problem for me. I'm hoping someone is able >> to point it out.**** >> >> ** ** >> >> -Sultan.**** >> >> On Sat, Dec 17, 2011 at 11:51 PM, xunxun <xun...@gm...> wrote:*** >> * >> >> Using mingw32-g++ please**** >> >> >> On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> >> wrote: >> > Hello, >> > >> > I'm trying to build a small jni dll with mingw gcc and am having trouble >> > during the linking step of the build. >> > >> > The linker command is thus: >> > >> > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows >> > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm >> > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 >> build/gl2ps.o >> > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll >> > >> > Here is a list of undefined symbols from the individual object files: >> > $ nm -C -u build/gl2ps.o >> > U _imp___iob >> > U cos >> > U ctime >> > U destroyEPSOutput >> > U fflush >> > U fprintf >> > U fputc >> > U free >> > U fwrite >> > U getEPS >> > U getFontDefinitionsMemSize >> > U glBegin@4 >> > U glBitmap@28 >> > U glEnd@0 >> > U glFeedbackBuffer@12 >> > U glGetBooleanv@8 >> > U glGetFloatv@8 >> > U glGetIntegerv@8 >> > U glIsEnabled@4 >> > U glPassThrough@4 >> > U glRenderMode@4 >> > U glVertex3f@12 >> > U gmtime >> > U log10 >> > U malloc >> > U popFontDefinitions >> > U pow >> > U qsort >> > U realloc >> > U sin >> > U sprintf >> > U sqrt >> > U strcpy >> > U strncpy >> > U time >> > U vfprintf >> > $ nm -C -u build/gl2psjni.o >> > U fopen >> > U free >> > U gl2psBeginPage >> > U gl2psBeginViewport >> > U gl2psBlendFunc >> > U gl2psDisable >> > U gl2psDrawPixels >> > U gl2psEnable >> > U gl2psEndPage >> > U gl2psEndViewport >> > U gl2psGetFileExtension >> > U gl2psGetFormat >> > U gl2psGetFormatDescription >> > U gl2psGetOptions >> > U gl2psLineWidth >> > U gl2psMathML >> > U gl2psMathMLFooter >> > U gl2psMathMLHeader >> > U gl2psPointSize >> > U gl2psSetOptions >> > U gl2psSpecial >> > U gl2psText >> > U gl2psTextOpt >> > U malloc >> > U printf >> > U puts >> > $ nm -C -u build/mathml2ps.o >> > U _Unwind_Resume >> > U std::string::find_last_not_of(char const*, unsigned int) >> const >> > U std::string::data() const >> > U std::string::find(char const*, unsigned int) const >> > U std::string::find(std::string const&, unsigned int) const >> > U std::string::size() const >> > U std::string::c_str() const >> > U std::string::length() const >> > U std::string::substr(unsigned int, unsigned int) const >> > U std::string::compare(char const*) const >> > U std::basic_ostringstream<char, std::char_traits<char>, >> > std::allocator<char> >::str() const >> > U std::allocator<char>::allocator() >> > U std::allocator<char>::~allocator() >> > U std::string::erase(unsigned int, unsigned int) >> > U std::string::append(std::string const&) >> > U std::basic_string<char, std::char_traits<char>, >> > std::allocator<char> >::basic_string(char const*, std::allocator<char> >> > const&) >> > U std::basic_string<char, std::char_traits<char>, >> > std::allocator<char> >::basic_string(std::string const&) >> > U std::basic_string<char, std::char_traits<char>, >> > std::allocator<char> >::~basic_string() >> > U std::string::operator=(std::string const&) >> > U std::basic_ostringstream<char, std::char_traits<char>, >> > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) >> > U std::basic_ostringstream<char, std::char_traits<char>, >> > std::allocator<char> >::~basic_ostringstream() >> > U std::ios_base::Init::Init() >> > U std::ios_base::Init::~Init() >> > U std::__throw_bad_alloc() >> > U std::__throw_length_error(char const*) >> > U operator delete(void*) >> > U operator new(unsigned int) >> > U __cxa_begin_catch >> > U __cxa_end_catch >> > U __cxa_rethrow >> > U __gxx_personality_v0 >> > U _assert >> > U _imp___ZN10MathViewNS10fileExistsEPKc >> > U >> > >> _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE >> > U _imp___ZN12FontDataBase6createEv >> > U _imp___ZN13Configuration16getBinaryVersionEv >> > U _imp___ZN13Configuration21getConfigurationPathsEv >> > U _imp___ZN13ConfigurationC1Ev >> > U _imp___ZN14AbstractLoggerC2Ev >> > U >> > >> _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb >> > U _imp___ZN16libxml2_MathView10loadBufferEPKc >> > U >> > >> _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs >> > U >> > >> _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs >> > U >> _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE >> > U >> _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE >> > U _imp___ZN17FormattingContextD1Ev >> > U >> > >> _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE >> > U _imp___ZN24MathMLOperatorDictionaryC1Ev >> > U _imp___ZN25PS_StreamRenderingContext11documentEndEv >> > U >> > >> _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc >> > U >> > >> _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE >> > U _imp___ZN25PS_StreamRenderingContextD1Ev >> > U _imp___ZN4View16resetRootElementEv >> > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE >> > U _imp___ZN4View18setDefaultFontSizeEj >> > U >> > >> _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE >> > U >> > >> _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE >> > U _imp___ZN4View27getDefaultConfigurationPathEv >> > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv >> > U _imp___ZNK13Configuration13getStringListERKSs >> > U >> > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi >> > U >> > _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ >> > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId >> > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz >> > U _imp___ZNK4View14getBoundingBoxEv >> > U _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ >> > U _imp___ZTV6Logger >> > U atexit >> > U free >> > U malloc >> > U strcat >> > U strcpy >> > U strdup >> > U strncpy >> > U strtof >> > U strtok >> > >> > What is very confusing is all the undefined references from the stdc++ >> > library and standard C functions (malloc, strcat etc). >> > >> > I must be missing something, because there are also undefined references >> > even between these objects. For instance, gl2psjni.o has undefined >> > references that *should* be there from gl2ps.o (gl2psBeginPage, >> > gl2psBeginViewport etc). >> > >> > Any insights would be greatly appreciated, and many thanks in advance >> for >> > taking the time to read this. >> > >> > -Sultan. >> > >> >> >> >> **** >> >> -- >> Best Regards, >> xunxun >> >> >> ------------------------------------------------------------------------------ >> Learn Windows Azure Live! Tuesday, Dec 13, 2011 >> Microsoft is holding a special Learn Windows Azure training event for >> developers. It will provide a great way to learn Windows Azure and what it >> provides. You can attend the event by watching it streamed LIVE online. >> Learn more at http://p.sf.net/sfu/ms-windowsazure >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list >> etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also: mailto:min...@li... >> ?subject=unsubscribe**** >> >> >> >> **** >> >> ** ** >> >> -- >> -sultan**** >> >> >> ------------------------------------------------------------------------------ >> Learn Windows Azure Live! Tuesday, Dec 13, 2011 >> Microsoft is holding a special Learn Windows Azure training event for >> developers. It will provide a great way to learn Windows Azure and what it >> provides. You can attend the event by watching it streamed LIVE online. >> Learn more at http://p.sf.net/sfu/ms-windowsazure >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list >> etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also: mailto:min...@li... >> ?subject=unsubscribe >> > > > > -- > -sultan > -- -sultan |
From: Sultan S. <jav...@gm...> - 2011-12-18 07:19:04
|
Plainly, I'm too tired to be allowed anywhere near a compiler. I forgot I'd disabled two of the objects from the build, so in fact what I saw were only the missing references from one. Well, it's back to the drawing board, but later. I need sleep. -S. On Sun, Dec 18, 2011 at 2:06 AM, Sultan Saini <jav...@gm...> wrote: > By the way, is this a known issue with MinGW gcc? Seems odd that the order > of arguments to the compiler should cause a problem like this. (Forgive my > naivete if this is a silly question - I'm a java developer, so I don't get > to play in C/C++ that often.) > > -S. > > > On Sun, Dec 18, 2011 at 1:57 AM, Sultan Saini <jav...@gm...>wrote: > >> @LRN, yes, I do have extern "C" wrappers in my headers. Thank you *very >> much* for your suggestion to switch around the arguments in the call to the >> linker - that seems to have cleaned up most of the problems (you have no >> idea how relieved I am at the moment - thank you). What remains appears to >> be straightforward missing __declspec macros (they must have been getting >> lost in the noise). >> >> @Emanuel, the only reason I didn't want to do the port is time >> constraints. However, even as I write this, I had pretty decided that that >> would have been my next step. >> >> Thanks for the speedy responses. You have made me a very happy camper >> today :-) >> >> -S. >> >> >> On Sun, Dec 18, 2011 at 1:19 AM, Emanuel Falkenauer < >> E.F...@op...> wrote: >> >>> Hi,**** >>> >>> ** ** >>> >>> I'm not sure this could be of any help, but I have a pretty extensive >>> palette of JNI DLLs… and thy are ALL written in C++ and compiled with >>> mingw32-g++ (and even its 64bit version, i.e. x86_64-w64-mingw32-g++)! The >>> headers generated by Java are fully compatible with C++ (no idea why you >>> would stick to C).**** >>> >>> ** ** >>> >>> Good luck,**** >>> >>> ** ** >>> >>> Emanuel**** >>> >>> ** ** >>> >>> *De :* Sultan Saini [mailto:jav...@gm...] >>> *Envoyé :* Sunday, 18 December, 2011 06:19 >>> *À :* MinGW Users List >>> *Objet :* Re: [Mingw-users] Undefined references when linking with >>> mingw32-gcc**** >>> >>> ** ** >>> >>> Yes, I contemplated that. The thing is that I'd really rather not >>> rewrite one of the jni source files in C++. It's currently using the C >>> implementation of the JNI api. It feels like I'm missing something obvious >>> and important that will fix this problem for me. I'm hoping someone is able >>> to point it out.**** >>> >>> ** ** >>> >>> -Sultan.**** >>> >>> On Sat, Dec 17, 2011 at 11:51 PM, xunxun <xun...@gm...> wrote:** >>> ** >>> >>> Using mingw32-g++ please**** >>> >>> >>> On Sun, Dec 18, 2011 at 12:42 PM, Sultan Saini <jav...@gm...> >>> wrote: >>> > Hello, >>> > >>> > I'm trying to build a small jni dll with mingw gcc and am having >>> trouble >>> > during the linking step of the build. >>> > >>> > The linker command is thus: >>> > >>> > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows >>> > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm >>> > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 >>> build/gl2ps.o >>> > build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll >>> > >>> > Here is a list of undefined symbols from the individual object files: >>> > $ nm -C -u build/gl2ps.o >>> > U _imp___iob >>> > U cos >>> > U ctime >>> > U destroyEPSOutput >>> > U fflush >>> > U fprintf >>> > U fputc >>> > U free >>> > U fwrite >>> > U getEPS >>> > U getFontDefinitionsMemSize >>> > U glBegin@4 >>> > U glBitmap@28 >>> > U glEnd@0 >>> > U glFeedbackBuffer@12 >>> > U glGetBooleanv@8 >>> > U glGetFloatv@8 >>> > U glGetIntegerv@8 >>> > U glIsEnabled@4 >>> > U glPassThrough@4 >>> > U glRenderMode@4 >>> > U glVertex3f@12 >>> > U gmtime >>> > U log10 >>> > U malloc >>> > U popFontDefinitions >>> > U pow >>> > U qsort >>> > U realloc >>> > U sin >>> > U sprintf >>> > U sqrt >>> > U strcpy >>> > U strncpy >>> > U time >>> > U vfprintf >>> > $ nm -C -u build/gl2psjni.o >>> > U fopen >>> > U free >>> > U gl2psBeginPage >>> > U gl2psBeginViewport >>> > U gl2psBlendFunc >>> > U gl2psDisable >>> > U gl2psDrawPixels >>> > U gl2psEnable >>> > U gl2psEndPage >>> > U gl2psEndViewport >>> > U gl2psGetFileExtension >>> > U gl2psGetFormat >>> > U gl2psGetFormatDescription >>> > U gl2psGetOptions >>> > U gl2psLineWidth >>> > U gl2psMathML >>> > U gl2psMathMLFooter >>> > U gl2psMathMLHeader >>> > U gl2psPointSize >>> > U gl2psSetOptions >>> > U gl2psSpecial >>> > U gl2psText >>> > U gl2psTextOpt >>> > U malloc >>> > U printf >>> > U puts >>> > $ nm -C -u build/mathml2ps.o >>> > U _Unwind_Resume >>> > U std::string::find_last_not_of(char const*, unsigned int) >>> const >>> > U std::string::data() const >>> > U std::string::find(char const*, unsigned int) const >>> > U std::string::find(std::string const&, unsigned int) const >>> > U std::string::size() const >>> > U std::string::c_str() const >>> > U std::string::length() const >>> > U std::string::substr(unsigned int, unsigned int) const >>> > U std::string::compare(char const*) const >>> > U std::basic_ostringstream<char, std::char_traits<char>, >>> > std::allocator<char> >::str() const >>> > U std::allocator<char>::allocator() >>> > U std::allocator<char>::~allocator() >>> > U std::string::erase(unsigned int, unsigned int) >>> > U std::string::append(std::string const&) >>> > U std::basic_string<char, std::char_traits<char>, >>> > std::allocator<char> >::basic_string(char const*, std::allocator<char> >>> > const&) >>> > U std::basic_string<char, std::char_traits<char>, >>> > std::allocator<char> >::basic_string(std::string const&) >>> > U std::basic_string<char, std::char_traits<char>, >>> > std::allocator<char> >::~basic_string() >>> > U std::string::operator=(std::string const&) >>> > U std::basic_ostringstream<char, std::char_traits<char>, >>> > std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode) >>> > U std::basic_ostringstream<char, std::char_traits<char>, >>> > std::allocator<char> >::~basic_ostringstream() >>> > U std::ios_base::Init::Init() >>> > U std::ios_base::Init::~Init() >>> > U std::__throw_bad_alloc() >>> > U std::__throw_length_error(char const*) >>> > U operator delete(void*) >>> > U operator new(unsigned int) >>> > U __cxa_begin_catch >>> > U __cxa_end_catch >>> > U __cxa_rethrow >>> > U __gxx_personality_v0 >>> > U _assert >>> > U _imp___ZN10MathViewNS10fileExistsEPKc >>> > U >>> > >>> _imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE >>> > U _imp___ZN12FontDataBase6createEv >>> > U _imp___ZN13Configuration16getBinaryVersionEv >>> > U _imp___ZN13Configuration21getConfigurationPathsEv >>> > U _imp___ZN13ConfigurationC1Ev >>> > U _imp___ZN14AbstractLoggerC2Ev >>> > U >>> > >>> _imp___ZN15T1_FontDataBase6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationEb >>> > U _imp___ZN16libxml2_MathView10loadBufferEPKc >>> > U >>> > >>> _imp___ZN16libxml2_MathView17loadConfigurationERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationERKSs >>> > U >>> > >>> _imp___ZN16libxml2_MathView22loadOperatorDictionaryERK8SmartPtrI14AbstractLoggerERKS0_I24MathMLOperatorDictionaryERKSs >>> > U >>> _imp___ZN16libxml2_MathView6createERK8SmartPtrI14AbstractLoggerE >>> > U >>> _imp___ZN17FormattingContextC1ERK8SmartPtrI17MathGraphicDeviceE >>> > U _imp___ZN17FormattingContextD1Ev >>> > U >>> > >>> _imp___ZN22MathMLNamespaceContextC1ERK8SmartPtrI4ViewERKS0_I17MathGraphicDeviceE >>> > U _imp___ZN24MathMLOperatorDictionaryC1Ev >>> > U _imp___ZN25PS_StreamRenderingContext11documentEndEv >>> > U >>> > >>> _imp___ZN25PS_StreamRenderingContext13documentStartERK5fixedIiLi10EES3_RK11BoundingBoxPKc >>> > U >>> > >>> _imp___ZN25PS_StreamRenderingContextC1ERK8SmartPtrI14AbstractLoggerERSoS0_I12FontDataBaseE >>> > U _imp___ZN25PS_StreamRenderingContextD1Ev >>> > U _imp___ZN4View16resetRootElementEv >>> > U _imp___ZN4View17setAvailableWidthERK5fixedIiLi10EE >>> > U _imp___ZN4View18setDefaultFontSizeEj >>> > U >>> > >>> _imp___ZN4View21setOperatorDictionaryERK8SmartPtrI24MathMLOperatorDictionaryE >>> > U >>> > >>> _imp___ZN4View25setMathMLNamespaceContextERK8SmartPtrI22MathMLNamespaceContextE >>> > U _imp___ZN4View27getDefaultConfigurationPathEv >>> > U _imp___ZN4View32getDefaultOperatorDictionaryPathEv >>> > U _imp___ZNK13Configuration13getStringListERKSs >>> > U >>> > _imp___ZNK13Configuration6getIntERK8SmartPtrI14AbstractLoggerERKSsi >>> > U >>> > >>> _imp___ZNK13Configuration9getStringERK8SmartPtrI14AbstractLoggerERKSsS6_ >>> > U _imp___ZNK14AbstractLogger11setLogLevelE10LogLevelId >>> > U _imp___ZNK14AbstractLogger3outE10LogLevelIdPKcz >>> > U _imp___ZNK4View14getBoundingBoxEv >>> > U >>> _imp___ZNK4View6renderER16RenderingContextRK5fixedIiLi10EES5_ >>> > U _imp___ZTV6Logger >>> > U atexit >>> > U free >>> > U malloc >>> > U strcat >>> > U strcpy >>> > U strdup >>> > U strncpy >>> > U strtof >>> > U strtok >>> > >>> > What is very confusing is all the undefined references from the stdc++ >>> > library and standard C functions (malloc, strcat etc). >>> > >>> > I must be missing something, because there are also undefined >>> references >>> > even between these objects. For instance, gl2psjni.o has undefined >>> > references that *should* be there from gl2ps.o (gl2psBeginPage, >>> > gl2psBeginViewport etc). >>> > >>> > Any insights would be greatly appreciated, and many thanks in advance >>> for >>> > taking the time to read this. >>> > >>> > -Sultan. >>> > >>> >>> >>> >>> **** >>> >>> -- >>> Best Regards, >>> xunxun >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Windows Azure Live! Tuesday, Dec 13, 2011 >>> Microsoft is holding a special Learn Windows Azure training event for >>> developers. It will provide a great way to learn Windows Azure and what >>> it >>> provides. You can attend the event by watching it streamed LIVE online. >>> Learn more at http://p.sf.net/sfu/ms-windowsazure >>> _______________________________________________ >>> MinGW-users mailing list >>> Min...@li... >>> >>> This list observes the Etiquette found at >>> http://www.mingw.org/Mailing_Lists. >>> We ask that you be polite and do the same. Disregard for the list >>> etiquette may cause your account to be moderated. >>> >>> _______________________________________________ >>> You may change your MinGW Account Options or unsubscribe at: >>> https://lists.sourceforge.net/lists/listinfo/mingw-users >>> Also: mailto:min...@li... >>> ?subject=unsubscribe**** >>> >>> >>> >>> **** >>> >>> ** ** >>> >>> -- >>> -sultan**** >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Windows Azure Live! Tuesday, Dec 13, 2011 >>> Microsoft is holding a special Learn Windows Azure training event for >>> developers. It will provide a great way to learn Windows Azure and what >>> it >>> provides. You can attend the event by watching it streamed LIVE online. >>> Learn more at http://p.sf.net/sfu/ms-windowsazure >>> _______________________________________________ >>> MinGW-users mailing list >>> Min...@li... >>> >>> This list observes the Etiquette found at >>> http://www.mingw.org/Mailing_Lists. >>> We ask that you be polite and do the same. Disregard for the list >>> etiquette may cause your account to be moderated. >>> >>> _______________________________________________ >>> You may change your MinGW Account Options or unsubscribe at: >>> https://lists.sourceforge.net/lists/listinfo/mingw-users >>> Also: mailto:min...@li... >>> ?subject=unsubscribe >>> >> >> >> >> -- >> -sultan >> > > > > -- > -sultan > -- -sultan |
From: Keith M. <kei...@us...> - 2011-12-18 19:50:09
|
Not attempting to quote from unintelligibly top-posted thread; this relates to ordering of object file and library references on gcc command line. On 18/12/11 07:06, Sultan Saini wrote: > By the way, is this a known issue with MinGW gcc? Yes, and no. Yes, the issue is well known; so well known that it is the subject of a FAQ: http://www.mingw.org/wiki/The_linker_consistently_giving_undefined_references However, the issue is NOT a MinGW gcc fault; it is user error. > Seems odd that the order of arguments to the compiler should cause > a problem like this. Not at all. It is standard behaviour for *nix linkers. Object file and library references are read in strictly left to right order, and symbols from libraries are only selected for inclusion in the output image if they have already been identified as needed, by reference in another file which has been read BEFORE the library itself is read. -- Regards, Keith. |
From: Sultan S. <jav...@gm...> - 2011-12-18 20:39:38
|
On Sun, Dec 18, 2011 at 2:49 PM, Keith Marshall < kei...@us...> wrote: > Not attempting to quote from unintelligibly top-posted thread; > this relates to ordering of object file and library references on > gcc command line. > > On 18/12/11 07:06, Sultan Saini wrote: > > By the way, is this a known issue with MinGW gcc? > > Yes, and no. Yes, the issue is well known; so well known that it > is the subject of a FAQ: > > > http://www.mingw.org/wiki/The_linker_consistently_giving_undefined_references > > However, the issue is NOT a MinGW gcc fault; it is user error. > > > Seems odd that the order of arguments to the compiler should cause > > a problem like this. > > Not at all. It is standard behaviour for *nix linkers. Object file and > library references are read in strictly left to right order, and symbols > from libraries are only selected for inclusion in the output image if > they have already been identified as needed, by reference in another > file which has been read BEFORE the library itself is read. Thanks for the explanation, Keith, and once again, my apologies for the top posting. Even using mingw32-gcc, putting the object files before the library options did not fix my problem, but switching to g++ did. I should start a new thread, given that the nature of my problem has changed. -sultan |
From: Peter R. <p.r...@sh...> - 2011-12-19 10:50:42
|
On 18/12/11 19:49, Keith Marshall wrote: > ...snip >> Seems odd that the order of arguments to the compiler should cause >> a problem like this. > Not at all. It is standard behaviour for *nix linkers. Object file and > library references are read in strictly left to right order, and symbols > from libraries are only selected for inclusion in the output image if > they have already been identified as needed, by reference in another > file which has been read BEFORE the library itself is read. > Just curious: I don't for a moment dispute the veracity of this but I have always wondered if there is some technical reason for this awkward behaviour? Is it behaviour common to all linkers? (From dim-and-distant recollections of other linkers I seem to think it might be but I stand to be corrected.) P. |
From: JonY <jo...@us...> - 2011-12-19 11:09:10
Attachments:
signature.asc
|
On 12/19/2011 18:50, Peter Rockett wrote: > On 18/12/11 19:49, Keith Marshall wrote: >> ...snip >>> Seems odd that the order of arguments to the compiler should cause >>> a problem like this. >> Not at all. It is standard behaviour for *nix linkers. Object file and >> library references are read in strictly left to right order, and symbols >> from libraries are only selected for inclusion in the output image if >> they have already been identified as needed, by reference in another >> file which has been read BEFORE the library itself is read. >> > Just curious: I don't for a moment dispute the veracity of this but I > have always wondered if there is some technical reason for this awkward > behaviour? Is it behaviour common to all linkers? (From dim-and-distant > recollections of other linkers I seem to think it might be but I stand > to be corrected.) > > P. > This goes back for historical reasons, see the book "Linkers and Loaders", it is a good book. IMHO, the biggest reason is that you do not want to ever change default behavior once it has taken roots. You do not want all the back-draft from your users if behavior ever becomes incompatible for some niche use case that is out there. |
From: LRN <lr...@gm...> - 2011-12-18 06:33:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18.12.2011 8:42, Sultan Saini wrote: > Hello, > > I'm trying to build a small jni dll with mingw gcc and am having > trouble during the linking step of the build. > > The linker command is thus: > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 > build/gl2ps.o build/gl2psjni.o build/mathml2ps.o -o > build/gl2psjni.dll > > What is very confusing is all the undefined references from the > stdc++ library and standard C functions (malloc, strcat etc). > > I must be missing something, because there are also undefined > references even between these objects. For instance, gl2psjni.o has > undefined references that *should* be there from gl2ps.o > (gl2psBeginPage, gl2psBeginViewport etc). > > Any insights would be greatly appreciated, and many thanks in > advance for taking the time to read this. > > -Sultan. A couple of things for you to try: A) Change the argument order. Put .o files before the libraries B) Do you have "extern C" guards on your headers? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO7YkvAAoJEOs4Jb6SI2Cwl7IIAKv1HggIHprOJUTJdIrrLzPo usT53q63PpWP/sB5f5R4uE8l8xmLv8PyRNhsSGGGgQAyUAxw95Y3l7ie1HwIGFjD qajPXnaQTJtedw33aBKVRnl6r+gqJKZPihXX8OThs/77XWCEw8ds8bOgnkpOszwM JMLN+8QheElusRjSb6nhA3e1zO4gqUS9axmO12OPqdYL16Vusav6Kr0u7rZzMgt+ XWSj5+/BQCKBYLYfHwn5GrAFtbVs6Z1LamCo/F6a9KXz9KWwfkIlK8VBgtAvcy9e yMofYBki1MhSLXLk1icU6TLSpTxTUajfKlqFP3awmNGT2uBeaFiACrpaOAQXRJs= =aJkb -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2011-12-18 15:20:27
|
I've read all the posts but choose to answer the original mail. First I will say DO NOT TOP POST. Second, trim the parts of the quoted mail you're not responding to. More below Sultan Saini wrote: > Hello, > > I'm trying to build a small jni dll with mingw gcc and am having trouble > during the linking step of the build. > > The linker command is thus: > > /c/MinGW/bin/mingw32-gcc.exe -w -fPIC -lstdc++ -shared -mwindows > -LC:/MinGW/lib/glut -LC:/MinGW/lib/GLU -LC:/MinGW/lib/GL -lm > -LC:/MinGW/lib/glib-2.0 -lopengl32 -lglu32 -lglut32 -lglib-2.0 > build/gl2ps.o build/gl2psjni.o build/mathml2ps.o -o build/gl2psjni.dll > 1) Command line order matters for the library specification. Libraries to resolve references in objects must follow the object specification and not precede it. 2) For C++ code you do to use G++ and not GCC for the link step. 3) Do not include the standard libraries like libstdc++ in the link step. 4) -lm is meaningless. http://www.mingw.org/wiki http://www.mingw.org/wiki/FAQ http://www.mingw.org/wiki/HOWTO -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Sultan S. <jav...@gm...> - 2011-12-18 18:17:38
|
On Sun, Dec 18, 2011 at 10:20 AM, Earnie <ea...@us...>wrote: > I've read all the posts but choose to answer the original mail. > > First I will say DO NOT TOP POST. > Second, trim the parts of the quoted mail you're not responding to. > Ok. My apologies, I'm new to the mailing list. > > 1) Command line order matters for the library specification. Libraries > to resolve references in objects must follow the object specification > and not precede it. > 2) For C++ code you do to use G++ and not GCC for the link step. > 3) Do not include the standard libraries like libstdc++ in the link step. > 4) -lm is meaningless. > > Thanks for those tips. After I switched to using g++, I was able to compile my c files using -x c. Most of the linking goes fine. There is, however, still a problem with one of the libraries. I now get failures like these: build/mathml2ps.o:mathml2ps.cc:(.text+0x1d7): undefined reference to `_imp___ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE' Using nm on the relevant object file, I see: $ nm --no-demangle /c/MinGW/lib/libmathview_backend_ps.a | grep "Backend6createERK8SmartPtrI14AbstractLoggerERKS" 00000d94 T __ZN10PS_Backend6createERK8SmartPtrI14AbstractLoggerERKS0_I13ConfigurationE I have made sure to compile libgtkmathview with --compat-implib, but it still seems to not have the _imp prefix on the exported names. I'm also getting C:/MinGW/lib/libmingw32.a(main.o): In function `main': C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined reference to `WinMain@16', which I can get around by adding a main() to one of the source files, but shouldn't that be taken care of by -mwindows? There's a lot of confusing info to be found regarding this error on the net. -Sultan -- -sultan |
From: Keith M. <kei...@us...> - 2011-12-18 21:28:51
|
On 18/12/11 20:39, Sultan Saini wrote: > Thanks for the explanation, Keith, You're welcome. > and once again, my apologies for the top posting. No problem; you corrected the issue as soon as possible, after it was brought to your attention. BTW, please adjust your mailer settings to elide real e-mail addresses; why give the spam-harvesters avoidable assistance? > Even using mingw32-gcc, putting the object files before the library > options did not fix my problem, but switching to g++ did. If your project is mixed C/C++, then you need to link with the standard C++ libraries. Using g++ for the link phase of your build will do that automatically; using gcc will not. You can use EITHER gcc OR g++ to COMPILE your sources; either is intelligent enough to make the correct choices, on the basis of the source file name extension: .c for C; .cc or .cpp (among others) for C++, (but do avoid .c vs .C contention, due to case insensitivity in MS-Windows). Some users may simply use g++ for everything; (any C++ compiler should be able to compile C code). Others may apportion the task to 'gcc -c ...' for C, and 'g++ -c ...' for C++. Just be sure to use g++ for linking. > I should start a new thread, given that the nature of my problem has > changed. That would be prudent. Please do. -- Regards, Keith. |
From: Sultan S. <jav...@gm...> - 2011-12-18 22:30:53
|
On Sun, Dec 18, 2011 at 4:28 PM, Keith Marshall <keithmarshall> wrote: > BTW, please adjust your mailer settings to elide real e-mail addresses; why give the spam-harvesters avoidable > assistance? > -- > Regards, > Keith. > > Hmm; I don't know of a way to do that automatically with gmail, but I can manually delete them, which I will. -sultan |
From: Ralph E. <ral...@gm...> - 2011-12-19 02:25:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe of some help so heres the bash script i use myself for java development. Drop it in /etc/profile.d and call it something like java-setup.sh. # # source this file (. /opt/java/java-setup.sh) in sh,ksh,zsh,bash to set # up paths for JAVA. # if [ ${MSYSTEM} == MINGW32 ]; then prefix="/opt/jdk32" exec_prefix="${prefix}" JAVA_HOME="$exec_prefix" ANT_HOME="$exec_prefix" CCK_HOME="$exec_prefix" PATH="${exec_prefix}/bin:${exec_prefix}/jre/bin:$PATH" LD_LIBRARY_PATH="${exec_prefix}/lib:${exec_prefix}/jre/lib:${LD_LIBRARY_PATH:-}" LD_RUN_PATH="${exec_prefix}/lib:${exec_prefix}/jre/lib:${LD_RUN_PATH:-}" C_INCLUDE_PATH="${exec_prefix}/include:${exec_prefix}/include/win32:${C_INCLUDE_PATH:-}" CPLUS_INCLUDE_PATH="${exec_prefix}/include:${exec_prefix}/include/win32:${CPLUS_INCLUDE_PATH:-}" export PATH LD_LIBRARY_PATH LD_RUN_PATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH export JAVAC JAVA_HOME ANT_HOME CCK_HOME unset prefix unset exec_prefix elif [ ${MSYSTEM} == MINGW64 ]; then prefix="/opt/jdk64" exec_prefix="${prefix}" JAVA_HOME="$exec_prefix" ANT_HOME="$exec_prefix" CCK_HOME="$exec_prefix" PATH="${exec_prefix}/bin:${exec_prefix}/jre/bin:$PATH" LD_LIBRARY_PATH="${exec_prefix}/lib:${exec_prefix}/jre/lib:${LD_LIBRARY_PATH:-}" LD_RUN_PATH="${exec_prefix}/lib:${exec_prefix}/jre/lib:${LD_RUN_PATH:-}" C_INCLUDE_PATH="${exec_prefix}/include:${exec_prefix}/include/win32:${C_INCLUDE_PATH:-}" CPLUS_INCLUDE_PATH="${exec_prefix}/include:${exec_prefix}/include/win32:${CPLUS_INCLUDE_PATH:-}" export PATH LD_LIBRARY_PATH LD_RUN_PATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH export JAVAC JAVA_HOME ANT_HOME CCK_HOME unset prefix unset exec_prefix fi As you might notice my mingw setup is a bit unusual as i use a 32 and 64 bit only version but it should be easy to adjust. This setup has allowed me to link with only minor problems to the java libraries. You need to recreate the import libraries with gendef and dlltool and put them in /opt/java32/lib or /opt/java64/lib depending on wheter you want to build a 32 or 64 bit executable. heres a modified version of the old gnuwin32 script to do just that. PROGNAME=${0##*/} if [ $(($#)) -lt 1 ] ; then echo "$PROGNAME: make MinGW import libraries from a dll" echo "Usage: $PROGNAME dllname.dll -l libname -d deffile" exit 1 fi function dumpargs { for dd in "$@"; do eval echo "$dd = \\\"\$$dd\\\"" done } DLLNAME=$1 shift while getopts ":d:l:" opt; do case $opt in d) DEFNAME="$OPTARG" ;; l) LIBNAME="$OPTARG" ;; \?) ;; esac done shift $(($OPTIND -1)) LIBNAME=${LIBNAME:-${DLLNAME%.dll}} LIBNAME=${LIBNAME%.a} LIBNAME=${LIBNAME%.dll} DEFNAME=${DEFNAME:-${DLLNAME%.dll}} DEFNAME=${DEFNAME%.def} # echo $DEFNAME if ! [ -s $DLLNAME ]; then echo "Error: Dynamic library $DLLNAME does not exist." exit 1 fi # Build MINGW import library echo "Creating MinGW import library: $LIBNAME.dll.a" DEFNAME=$DEFNAME.def if ! [ -s $DEFNAME ]; then gendef - $DLLNAME > $DEFNAME fi if ! [ -s $DEFNAME ]; then echo "Error: Definition file $DEFNAME does not exist." exit 1 fi if type -p dlltool.exe >/dev/null ; then dlltool.exe --dllname $DLLNAME --def $DEFNAME --output-lib $LIBNAME.dll.a else echo "Error: dlltool.exe not found" fi call it dll2a and dump it right in your mingw dir. The syntax to use it is dll2a dllname.dll -l libname -d defname . after that it should just work. Ralph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO7qCnAAoJEIjGvG7Y4HU8+hIH/AngNGy+ByL0apgvpK7hvBMs fFv+L7D4caRNHGNpE7GecJNo5Wk59qOUh71N/VdJ2kIq4Sk/QBXGj6KZDIrxyYcJ QiMdruzd5Du6mB4DiRgFryJ1Hr242V2gXMy/cOZ+UnMFROwr1ZWq7pWJQaPQOVCX IWZk3guGyVzyA9CSVg9IsAItZcFlEO/Q1sRc/V0ZIDEPTq30T8fTZYG4yXuDBPBD eynmchTeIjMt+wn1oge/mWFK6A9IYTqSUPgICRgeVbxSR8taD/AkWPHqNqAJDmDG X0q8erUDUg0A9I97ZcQ/J5Boc81tZhI8p7lCCkTdxDp7fUswEdBY4iOzFZzocVI= =oVPH -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2011-12-19 14:01:46
|
Sultan Saini wrote: > On Sun, Dec 18, 2011 at 4:28 PM, Keith Marshall <keithmarshall> wrote: > >> BTW, please adjust your mailer settings to > > elide real e-mail addresses; why give the spam-harvesters avoidable >> assistance? >> -- >> Regards, >> Keith. >> >> > Hmm; I don't know of a way to do that automatically with gmail, but I can > manually delete them, which I will. I don't see a method with the web interface either. You can use Thunderbird to read and respond to gmail by using IMAP or POP3. -- Earnie -- https://sites.google.com/site/earnieboyd/ |