I have added them. Thanks<br><br><div class="gmail_quote">On Wed, Sep 8, 2010 at 5:30 PM, Sean McBride <span dir="ltr"><<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Dave,<br>
<br>
FYI, if I add:<br>
<br>
#define nc_inq_type vtk_netcdf_nc_inq_type<br>
#define nextUTF8 vtk_netcdf_nextUTF8<br>
#define nulldup vtk_netcdf_nulldup<br>
<br>
my app then links.  If I further add the utf8proc ones, VTK itself fails<br>
to link when rebuilt.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Wed, 8 Sep 2010 17:00:51 -0400, Dave Partyka said:<br>
<br>
>Thanks Sean, I'll take a look.<br>
><br>
>On Wed, Sep 8, 2010 at 4:56 PM, Sean McBride <<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>>wrote:<br>
><br>
>> On Tue, 17 Aug 2010 15:11:12 -0400, Dave Partyka said:<br>
>><br>
>> >I just upaded VTK's netcdf from 3.6.2 to 4.1.1. In addition to the<br>
>> >traditional C library I have also brought in the C++ version of the<br>
>> library<br>
>> >(vtkNetCDF_cpp). I spent time creating the proper DLL exports, allowing<br>
>> even<br>
>> >Windows developers to use the library! This provides a nicer API that<br>
>> >developers can use when writing new netcdf readers/writers. Also with<br>
>> netcdf<br>
>> >4.x we can now potentially use HDF5 based NetCDF files. See here for the<br>
>> >release notes for NetCDF 4. As always we value feedback from the<br>
>> community,<br>
>> >feel free to report any issues. In the mean time I will be monitoring the<br>
>> >dashboards.<br>
>><br>
>> Dave,<br>
>><br>
>> I believe there is some mangling missing after your change.  I just<br>
>> pulled VTK from git and my app, which links to both NetCDF and VTK, no<br>
>> longer links.  Error is:<br>
>><br>
>> ld: duplicate symbol _nc_inq_type in /path1/libnetcdf.a(nc.o) and /path2/<br>
>> libvtkNetCDF.a(nc.c.o)<br>
>><br>
>> If I do the following:<br>
>><br>
>> nm libvtkNetCDF.a | grep " [TRD] "<br>
>><br>
>> It lists several symbols that aren't prefixed by vtk_netcdf, namely:<br>
>><br>
>> 0000000000003083 T _nc_inq_type<br>
>> 0000000000000043 T _nextUTF8<br>
>> 00000000000008ae T _nulldup<br>
>> 00000000000018ae T _utf8proc_NFC<br>
>> 0000000000001860 T _utf8proc_NFD<br>
>> 000000000000194a T _utf8proc_NFKC<br>
>> 00000000000018fc T _utf8proc_NFKD<br>
>> 0000000000001998 T _utf8proc_check<br>
>> 0000000000000343 T _utf8proc_codepoint_valid<br>
>> 0000000000000fd1 T _utf8proc_decompose<br>
>> 00000000000005d9 T _utf8proc_decompose_char<br>
>> 00000000000003c6 T _utf8proc_encode_char<br>
>> 0000000000000000 T _utf8proc_errmsg<br>
>> 000000000000054b T _utf8proc_get_property<br>
>> 00000000000000cf T _utf8proc_iterate<br>
>> 000000000000172b T _utf8proc_map<br>
>> 000000000000126a T _utf8proc_reencode<br>
>><br>
>> nc_inq_type certainly should be in vtk_netcdf_mangle.h, not sure why/how<br>
>> you missed it.  My experience with updating VTK's freetype is that one<br>
>> must regenerate the symbol list on all the major platforms and merge the<br>
>> results.  Some symbols seem to only be exported on some OSes, see my<br>
>> comments in vtk_freetype_mangle.h.<br>
>><br>
>> Not sure about the other symbols.  "utf8proc" looks like 3rd party code<br>
>> used by NetCDF itself.  I wonder if these symbols should not be exported<br>
>> at all, I'm guessing they are not part of NetCDF's public API.<br>
<br>
<br>
</div></div></blockquote></div><br>