On 2016-11-30 23:09+0100 Mario Emmenlauer wrote: > > Dear Alan, > > On 30.11.2016 21:48, Alan W. Irwin wrote: >> On 2016-11-30 20:06+0100 Mario Emmenlauer wrote: >> [...] >>> The symbol is defined in libvtkCommonCore-7.1.dll: >>> nm ../../bin/libvtkCommonCore-7.1.dll | c++filt | grep >>> 'vtkAOSDataArrayTemplate<unsigned char>::FastDownCast(vtkAbstractArray.*)' >>> >>> 0000000066bd10e0 T vtkAOSDataArrayTemplate<unsigned >>> char>::FastDownCast(vtkAbstractArray*) >>> >>> Am I missing something about linkage on Windows/MinGW? >> >> If nm shows the symbol is defined, yet the linker cannot see it, then >> that is very likely due to a symbol visibility issue. To check >> that compare results for >> >> nm --defined-only >> >> which only lists symbols that are defined by the library >> >> and >> >> nm --defined-only --extern-only >> >> which only lists symbols that are both defined by the library and >> externally visible. If your "missing" symbol is on the first list > > What you say makes perfect sense and is interesting to learn, thanks! > To my confusion however, the symbol seems defined and present in both > restrictions. I tried all combinations, here the intersection as an > example: > > #> nm --defined-only --extern-only ../../bin/libvtkCommonCore-7.1.dll | > c++filt > | grep 'vtkAOSDataArrayTemplate<unsigned > char>::FastDownCast(vtkAbstractArray.*)' > 0000000066bd10e0 T vtkAOSDataArrayTemplate<unsigned > char>::FastDownCast(vtkAbstractArray*) > > > Whats more: there are like a hundred undefined symbols in objects.a, > so it certainly must find quite a lot of them in some of the dlls, > otherwise I'd get more errors, would I not? Does that make any sense? > Am I maybe overlooking something?
Hi Mario: I suggest you carefully double-check the exact build command that was used and the error message that build generates. For example, it is possible the build command might not have properly instructed the linker to link objects.a to the library where nm reports that the symbol is both defined and visible. Or nm (which is a Unix command that is ported to Windows by the MinGW-w64/MSYS2 platform) may have a bug on Windows so that it does not report symbol visibility correctly on that platform. So you should probably attempt to verify the nm results using some native Windows application that looks at symbol visibility. But I should warn you I have hit (and likely exceeded) my Windows expertise in these matters since I develop almost entirely on Linux, and my knowledge of Windows visibility issues is almost entirely learned second-hand from my fellow developers for the PLplot software package who do have a lot of Windows development expertise. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
