wdas / ptex Goto Github PK

Hello,

I'm trying to build OpenImageIO with Ptex support and I'm having linking issues:

ptexinput.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl Ptex::v2_3::String::~String(void)" (__imp_??1String@v2_3@Ptex@@QEAA@XZ) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_2::PtexInput::open(class std::basic_string<char,struct std::char_traits<char>
,class std::allocator<char> > const &,class OpenImageIO_v2_2::ImageSpec &)" (?open@PtexInput@OpenImageIO_v2_2@@UEAA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEAVImageSpec@2@@Z) [...\openimageio\build\platform-windows\arch-AMD64\msvc-19.1\python-3.7\qt-5.15.
2.rf1\oiio\src\libOpenImageIO\OpenImageIO.vcxproj]

ptexinput.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class Ptex::v2_3::PtexTexture * __cdecl Ptex::v2_3::PtexTexture::open(char const *,class Ptex::v2_3::String &,bool)" (__imp_?open@PtexTexture@v2_3@Ptex@@SAPEAV123@PEBDAEAVString@23@_N@Z) referenced in function "public:
 virtual bool __cdecl OpenImageIO_v2_2::PtexInput::open(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class OpenImageIO_v2_2::ImageSpec &)" (?open@PtexInput@OpenImageIO_v2_2@@UEAA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEAVImageSpec@2@@Z
) [...\openimageio\build\platform-windows\arch-AMD64\msvc-19.1\python-3.7\qt-5.15.2.rf1\oiio\src\libOpenImageIO\OpenImageIO.vcxproj]
...\openimageio\build\platform-windows\arch-AMD64\msvc-19.1\python-3.7\qt-5.15.2.rf1\oiio\bin\Release\OpenImageIO.dll : fatal error LNK1120: 2 unresolved externals [...\openimageio\build\platform-windows\arch-AMD64\msvc-19.1\python-3.7\qt-5.15.2.rf1\
oiio\src\libOpenImageIO\OpenImageIO.vcxproj]

I looked at the exported symbols in my built Ptex.dll and there are small differences between what OpenImagIO is looking for and what is being exported:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>dumpbin /exports H:\Documents\Development\ThirdParty\Ptex\build\platform-windows\arch-AMD64\msvc-19.1\release\lib\Ptex.dll
Microsoft (R) COFF/PE Dumper Version 14.00.24245.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file H:\Documents\Development\ThirdParty\Ptex\build\platform-windows\arch-AMD64\msvc-19.1\release\lib\Ptex.dll

File Type: DLL

  Section contains the following exports for Ptex.dll

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
          19 number of functions
          19 number of names

    ordinal hint RVA      name

          1    0 0001E030 ??1String@v2_3@Ptex@@QEAA@XZ
          2    1 0001E040 ??4String@v2_3@Ptex@@QEAAAEAV012@PEBD@Z
          3    2 0001E640 ?BorderModeName@v2_3@Ptex@@YAPEBDW4BorderMode@12@@Z
          4    3 0001E660 ?ConvertFromFloat@v2_3@Ptex@@YAXPEAXPEBMW4DataType@12@H@Z
          5    4 0001E960 ?ConvertToFloat@v2_3@Ptex@@YAXPEAMPEBXW4DataType@12@H@Z
          6    5 0001EAD0 ?DataTypeName@v2_3@Ptex@@YAPEBDW4DataType@12@@Z
          7    6 0001EAF0 ?EdgeFilterModeName@v2_3@Ptex@@YAPEBDW4EdgeFilterMode@12@@Z
          8    7 0001EB10 ?EdgeIdName@v2_3@Ptex@@YAPEBDW4EdgeId@12@@Z
          9    8 0001EB30 ?MeshTypeName@v2_3@Ptex@@YAPEBDW4MeshType@12@@Z
         10    9 0001EB50 ?MetaDataTypeName@v2_3@Ptex@@YAPEBDW4MetaDataType@12@@Z
         11    A 00024B20 ?applyEdits@PtexWriter@v2_3@Ptex@@SA_NPEBDAEAVString@23@@Z
         12    B 00001FC0 ?create@PtexCache@v2_3@Ptex@@SAPEAV123@H_K_NPEAVPtexInputHandler@23@PEAVPtexErrorHandler@23@@Z
         13    C 00025180 ?edit@PtexWriter@v2_3@Ptex@@SAPEAV123@PEBD_NW4MeshType@23@W4DataType@23@HHHAEAVString@23@1@Z
         14    D 00077000 ?f2hTable@PtexHalf@v2_3@Ptex@@2PAGA
         15    E 00004C80 ?fromFloat_except@PtexHalf@v2_3@Ptex@@CAGI@Z
         16    F 00004920 ?getFilter@PtexFilter@v2_3@Ptex@@SAPEAV123@PEAVPtexTexture@23@AEBUOptions@123@@Z
         17   10 00037000 ?h2fTable@PtexHalf@v2_3@Ptex@@2PAIA
         18   11 0000AE80 ?open@PtexTexture@v2_3@Ptex@@SAPEAV123@PEBDAEAVString@23@_N@Z
         19   12 00026CE0 ?open@PtexWriter@v2_3@Ptex@@SAPEAV123@PEBDW4MeshType@23@W4DataType@23@HHHAEAVString@23@_N@Z

  Summary

       46000 .data
        3000 .pdata
        B000 .rdata
        1000 .reloc
        1000 .rsrc
       2B000 .text

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>undname ??1String@v2_3@Ptex@@QEAA@XZ
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "??1String@v2_3@Ptex@@QEAA@XZ"
is :- "public: __cdecl Ptex::v2_3::String::~String(void) __ptr64"
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>undname ?open@PtexTexture@v2_3@Ptex@@SAPEAV123@PEBDAEAVString@23@_N@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "?open@PtexTexture@v2_3@Ptex@@SAPEAV123@PEBDAEAVString@23@_N@Z"
is :- "public: static class Ptex::v2_3::PtexTexture * __ptr64 __cdecl Ptex::v2_3::PtexTexture::open(char const * __ptr64,class Ptex::v2_3::String & __ptr64,bool)"

• OIIO: public: __cdecl Ptex::v2_3::String::~String(void)
• Ptex: public: __cdecl Ptex::v2_3::String::~String(void) __ptr64
• OIIO: public: static class Ptex::v2_3::PtexTexture * __cdecl Ptex::v2_3::PtexTexture::open(char const *,class Ptex::v2_3::String &,bool)
• Ptex: public: static class Ptex::v2_3::PtexTexture * __ptr64 __cdecl Ptex::v2_3::PtexTexture::open(char const * __ptr64,class Ptex::v2_3::String & __ptr64,bool)

As far as I can tell, the only difference is __ptr64, I'm building everything for x64 and I'm unclear if it is an OIIO issue at this point or Ptex. Paging @lgritz just in case he has an idea!

Cheers,

Thomas

the use of PTEXAPI could be expanded to include both Mac and Linux builds with use of:

__attribute__ ((visibility("default")))

#if defined(_WIN32) || defined(_WINDOWS) || defined(_MSC_VER)
# ifndef PTEXAPI
#  ifndef PTEX_STATIC
#    ifdef PTEX_EXPORTS
#       define PTEXAPI __declspec(dllexport)
#    else
#       define PTEXAPI __declspec(dllimport)
#    endif
#  else
#    define PTEXAPI
#  endif
# endif
#else
#  ifndef PTEXAPI
#    define PTEXAPI  __attribute__ ((visibility("default")))
#  endif
#  ifndef DOXYGEN
#    define PTEX_USE_STDSTRING
#  endif
#endif

It would be nice to:

• Wherever possible switch dependencies to git submodules (zlib): users wouldn't have to locate, build & configure anymore for those
• Author PtexConfig.cmake file so that Ptex itself can be embedded as a git module into other projects (glfw does this, but seems to be missing some pieces)

Hello,

This error cropped up when disabling static library builds under GCC on Linux (various distros and GCC versions tested). Tested the v2.4.1 tag source.

We don't see a similar error on Windows and Mac, so it doesn't appear to be an issue with symbol visibility in shared libraries.

Here's reproducible steps (output from Ubuntu 20.04 and GCC 9 and CMake 3.22.3):

cmake -Bbuild -Ssrc -DPTEX_BUILD_STATIC_LIBS=OFF

gives

-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE  
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'zlib'
--   Found zlib, version 1.2.11
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/parallels/dev/ptex-test/build

then

make -C build -j2

giving

<omitted successful output>
[ 66%] Linking CXX executable ptxinfo
[ 76%] Built target rtest
make[2]: Entering directory '/home/parallels/dev/ptex-test/build'
Consolidate compiler generated dependencies of target ftest
make[2]: Leaving directory '/home/parallels/dev/ptex-test/build'
[ 85%] Built target ftest
make[2]: Entering directory '/home/parallels/dev/ptex-test/build'
make[2]: Leaving directory '/home/parallels/dev/ptex-test/build'
make[2]: Entering directory '/home/parallels/dev/ptex-test/build'
[ 90%] Building CXX object src/tests/CMakeFiles/halftest.dir/halftest.cpp.o
/usr/bin/ld: CMakeFiles/ptxinfo.dir/ptxinfo.cpp.o: in function `DumpMetaData(Ptex::v2_4::PtexMetaData*)':
ptxinfo.cpp:(.text+0xd6a): undefined reference to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)'
/usr/bin/ld: ptxinfo.cpp:(.text+0xfbd): undefined reference to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)'
/usr/bin/ld: ptxinfo.cpp:(.text+0x11cf): undefined reference to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)'
/usr/bin/ld: ptxinfo.cpp:(.text+0x13df): undefined reference to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)'
/usr/bin/ld: ptxinfo.cpp:(.text+0x15cb): undefined reference to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)'
/usr/bin/ld: CMakeFiles/ptxinfo.dir/ptxinfo.cpp.o:ptxinfo.cpp:(.text+0x1832): more undefined references to `Ptex::v2_4::PtexReader::MetaData::getEntry(int)' follow
collect2: error: ld returned 1 exit status
make[2]: *** [src/utils/CMakeFiles/ptxinfo.dir/build.make:99: src/utils/ptxinfo] Error 1

The failing link command is this:

cd /home/parallels/dev/ptex-test/build/src/utils && /snap/cmake/1035/bin/cmake -E cmake_link_script CMakeFiles/ptxinfo.dir/link.txt --verbose=1
/usr/bin/c++  -Wall -Wextra -pedantic -O3 -DNDEBUG CMakeFiles/ptxinfo.dir/ptxinfo.cpp.o -o ptxinfo  -Wl,-rpath,/home/parallels/dev/ptex-test/build/src/ptex: ../ptex/libPtex.so.2.4 /usr/lib/x86_64-linux-gnu/libz.so -pthread

Is this something you've seen before?

Thanks,
Mark

Will it be possible to include a versioning for .so file like libPtex.so.0 for example? See the build result for rpm package on: https://download.copr.fedorainfracloud.org/results/luya/blender-egl/fedora-rawhide-x86_64/01694327-ptex/builder-live.log.gz

Thanks in advance.

In a release tarball, there is no version file and no git files to query. This means we need to manually specify the PTEX_VER during config.

Without defining PTEX_VER the replace on line 48 fails.

I'm building on windows, and get compile errors with mulit-core builds enabled, but compiles fine single threaded.

cmake -G "Visual Studio 14 2015 Win64" ^
-DCMAKE_INSTALL_PREFIX="%current%\local" ^
-DZLIB_INCLUDE_DIR="%current%\local\include" ^
-DZLIB_LIBRARY="%current%\local\lib\zlib.lib" ^
....\ptex

// This works:
cmake --build . --target install --config Release -- /maxcpucount:1

// This fails with build errors:
cmake --build . --target install --config Release -- /maxcpucount:16

share/cmake is a agnostic architecture path

if build ptex in 32bit mode (if have already installed the library in 64 bits mode), lead to overwrite the current .cmake files, wich now point to /usr/lib{32bits build} instead the 64bits path. lead to mix architectures when to build any program wich depends in ptex

the content of the archive is

└───╼  cat /usr/share/cmake/Ptex/ptex-exports-release.cmake
#----------------------------------------------------------------
# Generated CMake target import file for configuration "Release".
#----------------------------------------------------------------

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

# Import target "Ptex::Ptex_static" for configuration "Release"
set_property(TARGET Ptex::Ptex_static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(Ptex::Ptex_static PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libPtex.a"
  )

list(APPEND _IMPORT_CHECK_TARGETS Ptex::Ptex_static )
list(APPEND _IMPORT_CHECK_FILES_FOR_Ptex::Ptex_static "${_IMPORT_PREFIX}/lib/libPtex.a" )

# Import target "Ptex::Ptex_dynamic" for configuration "Release"
set_property(TARGET Ptex::Ptex_dynamic APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(Ptex::Ptex_dynamic PROPERTIES
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libPtex.so.2.4"
  IMPORTED_SONAME_RELEASE "libPtex.so.2.4"
  )

list(APPEND _IMPORT_CHECK_TARGETS Ptex::Ptex_dynamic )
list(APPEND _IMPORT_CHECK_FILES_FOR_Ptex::Ptex_dynamic "${_IMPORT_PREFIX}/lib/libPtex.so.2.4" )

# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)

lib is the path where store the 64bit libs in my distro

for avoid overrwite the .cmake files and lead to cmake search the library in the correct architecture path, the cmake files should be installed in ${CMAKE_INSTALL_LIBDIR}\cmake\Ptex

greetings

http://ptex.us/download.html vs.
https://github.com/wdas/ptex/releases

Could some source code examples be added on how to create PTex files?
Particular if the source geometry contains n-gons. I.e. how to create the pentagon example?

👋 When I was checking the license in the repo. I found two different licenses got referenced in two places.

https://github.com/wdas/ptex/blob/master/Ptex.spec.in#L7 says Apache
https://github.com/wdas/ptex/blob/master/src/doc/License.txt says BSD

This might also be related to the old issue, #27

cc @SeekingMeaning @Rylan12

The top-level CMakeLists.txt file has:

if ("$ENV{FLAVOR}" MATCHES "debug")
    set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "type of build" FORCE)
else ()
    set(CMAKE_BUILD_TYPE "Release" CACHE STRING "type of build" FORCE)
endif ()

The problem with this is that if one is building a larger project that has ptex as a submodule, then if one runs cmake -DCMAKE_BUILD_TYPE=Debug ... at the top level, then the debug setting for the entire project is overridden by the explicit override of CMAKE_BUILD_TYPE in ptex's CMakeLists.txt.

In general, I'd suggest not overriding CMAKE_BUILD_TYPE at all. As an alternative, what about changing that else() to something like:

elseif ("$ENV{FLAVOR}" MATCHES "release")

so that if FLAVOR isn't set at all, then no override of CMAKE_BUILD_TYPE is done?

• Update our Linux CI verification to install ptex and then build a downstream project against it to verify that the packaging details are working as expected.
• Add github actions to verify building both static and dynamic libraries on Windows.
• Consider replacing our Travis CI Linux setup with github actions as well.

Related-to: #59 #61 #62

ptex-version.cmake isn't the name that CMake fill look for, so relying on the current set of config files doesn't quite work, the version won't be detected. As far as I can tell, it's not enough that ptex-config.cmake "includes" the version file. (CMake won't do the right things in the right order with the PACKAGE_VERSION.)

Also, side note, in ptex-config.cmake, those find_package calls ought to be find_dependency, which is customary for the exported config files and the semantics are slightly different.

Please include a copy of the license in the repository root.

PTexReader.h includes zlib.h for the z_stream_s member but this also has the side-effect of leaving symbols in other libraries for no reason.

Compare:
PixarAnimationStudios/OpenUSD#790

I don't know how to run the software.

Hi,

I'm currently trying to use PBRT v3 on several operating systems and one of them is FreeBSD. While trying to install PBRT I found an issue with the following error:

/ptex/src/ptex/PtexPlatform.h:73:10: faltal error: 'alloca.h' file not found
#include <alloca.h>

1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /ptex/build
*** Error code 1

Stop.
make[1]: stopped in /ptex/build
*** Error code 1

Stop.
make: stopped in /ptex/build

While troubleshooting, I found the following change in FreeBSD ports: https://cgit.freebsd.org/ports/commit/?id=5c793405d0e9f0aa05553a2888d6e31b1a17edb1

These were the specific changes that worked for me:

• PtexPlatform.h
• PtexWriter.cpp

Hi,

I am building ptex on Pop!_OS with the following commands :

make prefix=$PWD/install
make test
make install
make doc

But there's no target doc :

ninja: error: unknown target 'doc', did you mean 'all'?
make: *** [Makefile:67: doc] Error 1

Does the readme needs to be updated?

Thanks

Hello,

The Cisco Talos team found a security vulnerability impacting Walt Disney Per-Face Texture (PTEX) customers. As this is a sensitive security issue, we request an email address along with PGP. If PGP is unavailable, please confirm we have correct repository for reporting security issues.

For further information about the Cisco Vendor Vulnerability Reporting and Disclosure Policy please refer to this document which also links to our public PGP key. http://www.cisco.com/web/about/security/psirt/vendor_vulnerability_policy.html

Please CC [email protected] on all correspondence related to this issue

The current Ptex version that Homebrew installs, tag v2.1.10, does not install PtexVersion.h because it's prior to the Jan 5 commit by Brent that added it to the install list (aside: you should also update the README that lists header files).

If you tag a new release that includes that, somebody will probably update Homebrew so that it installs a usable release.

How can I uninstall ptex? actually I am getting this below error and want to remove everything.
install/bin/ptxinfo: error while loading shared libraries: libPtex.so: cannot open shared object file: No such file or directory

When I check out Ptex at v2.4.0 and do a CMake-based build, I seem to end up with a $PREFIX/share/cmake/Ptex/ptex-version.cmake that says,

set(PACKAGE_VERSION "2.3")

whereas I would expect this to say "2.4.0".

This seems to be because it's falling into the default case of setting PTEX_VER to "v2.3.X" at CMakeLists.txt#L64

Now, I should point out that I was trying to build into a directory that was a sibling (rather than a child) of the cloned ptex repo. Like this:

$ git clone https://github.com/wdas/ptex -b v2.4.0 ptex
$ cmake -B build -S ptex 
$ cmake --build build --target install

I tried it where the build is done inside the checked-out repo:

$ git clone https://github.com/wdas/ptex -b v2.4.0 ptex
$ cd ptex
$ cmake -B build -S .
$ cmake --build build --target install

And in this case, it works!

I would really like to build in the first way if possible. I'm not sure why the logic in CMakeLists is failing to figure out the version in this case.

There are three possible fixes. From laziest to most robust:

1. Just change the default from "v2.3.X" to "v2.4.X" since it's a 2.4 release now.

2. Fix whatever is broken about the version parsing logic.

3. Overhaul the version logic to the more standard practice of simply opening with

project(Ptex VERSION 2.4.0)

and then there is no more logic necessary, this is the one and only place where the version needs to be defined, since the project function in CMake automatically parses the version and set PROJECT_MAJOR_VERSION (and MINOR, PATCH, TWEAK if supplied) and for that matter, also Ptex_MAJOR_VERSION, etc. (based on your project name). This business of querying git for the latest tag, and then trying to extract the major/minor version numbers from that string... unusual, to say the least, and apparently a bit error prone.

Also, it would be nice if all places with versions define all 3 levels (major, minor, and patch) -- including in the exported cmake config as well as in PtexVersion.h -- since that's the way you're tagging releases.

Have you considered using the standard CMake option BUILD_SHARED_LIBS to control whether a static or dynamic library is generated? I'm perhaps speaking from a slightly windows-centric point of view, but it causes problems when building since the export library from the dynamic build will always just overwrite the static library file.

It also seems like there is some scattershot internally regarding which target is used, where the dynamic target is used for the tests, but the static target is used for the utilities (this, in spite of the fact that both are declared with -DPTEX_STATIC). Having the option to select how the tests/utilities are built might be nice.

I can make a PR to demonstrate these ideas if you're interested. It would be fairly minimal in terms of changes, I just don't want to seem like I'm imposing on your library or anything.

Hey,

I tried building ptex for Windows x64 with VS 2019.
Unfortunetly I got a linking error for the Symbol: h2fTable and fthTable. When building the halftest Projekt.

LNK2001 ""public: static unsigned int * Ptex::v2_3::PtexHalf::h2fTable" (?h2fTable@PtexHalf@v2_3@Ptex@@2PAIA)". halftest D:\Bibliotheken\ptex\build\src\tests\halftest.obj 1
LNK2001 ""public: static unsigned short * Ptex::v2_3::PtexHalf::f2hTable" (?f2hTable@PtexHalf@v2_3@Ptex@@2PAGA)". halftest D:\Bibliotheken\ptex\build\src\tests\halftest.obj 1

I was able to fix this problem by adding the line:
#include "PtexHalfTables.h"
under
#include "PtexHalf.h"
In halftest.cpp
But I'm not sure if this is "best practice".

Best Regards,
Jonas