Closed Chrjstoph closed 7 years ago
ingowald
commented
7 years ago Hey, Christoph, Could you be a bit more specific? Ideally send a build log or something to go from? For example, at a minimum the output of "make clean; make VERBOSE=1" would be useful - i just double-checked on my laptop and everything compiled and linked fine ....
ingowald
commented
7 years ago Please note I also just pushed a new version that contains some bugfixes - nothing related to linking, though; and before pushing I had tried both my version as well as the one here on github - both worked.... so the build log would still be useful
Chrjstoph
commented
7 years ago Hello Hingo and thank you for your quick reply.
I added “ospray_common_EXPORTS” to the preprocessor Definitions of common.
I am rather ignorant of CMake and advanced VS stuff.
Best Regrads Christoph
From: Ingo Wald Sent: Monday, January 30, 2017 6:52 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Hey, Christoph, Could you be a bit more specific? Ideally send a build log or something to go from? For example, at a minimum the output of "make clean; make VERBOSE=1" would be useful - i just double-checked on my laptop and everything compiled and linked fine ....
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "
Chrjstoph
commented
7 years ago An unedited Build results in the following log.
Also: I removed following line (parsePLY, l159):
// THROW_SG_ERROR("#osp:sg:ply: gzipped file not supported yet on Windows");
Christoph
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Chrjstoph
commented
7 years ago I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago Give me a few secs (or hours!?) ... I just added this parser to our ospray CI build system, which also compiles on windows. the downside is that I'll have to do a lot of pushes of half-ready code, because my only way of getting back a compile result is to push in whatever I just edited, and see what the CI system makes out of it.
Cheers,
Ingo
On 01/31/2017 11:10 AM, Christoph wrote:
I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276443854, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwZteX2g0X70UkI_DXNA3K-0PsGO62aks5rX3kOgaJpZM4LxifB.
Chrjstoph
commented
7 years ago I tried stepping your program with filename “.../pbrt-v3-scenes/simple/buddha.pbrt” but there are no tokens to parse through.
Could you give an exemplary use case?
From: Ingo Wald Sent: Tuesday, January 31, 2017 7:13 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Give me a few secs (or hours!?) ... I just added this parser to our ospray CI build system, which also compiles on windows. the downside is that I'll have to do a lot of pushes of half-ready code, because my only way of getting back a compile result is to push in whatever I just edited, and see what the CI system makes out of it.
Cheers,
Ingo
On 01/31/2017 11:10 AM, Christoph wrote:
I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276443854, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwZteX2g0X70UkI_DXNA3K-0PsGO62aks5rX3kOgaJpZM4LxifB.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago pretty sure that means that it could not open the file. Just added an exception if that happens; the old code silently ignored that.
Are you sure, for example, about the three dots at the beginning of the filename? If not, check your working dir. It definitely works in my case:
parsing: /home/wald/models/pbrt-v3-scenes/simple/buddha.pbrt
Parsing PBRT World
Parsing PBRT World - done!
==> parsing successful (grammar only for now)
writing Object '
and I also just test-rendred the exported obj with ospray - no materials (that is expected right now), but the geometry is sound.
Cheers,
Ingo
On 01/31/2017 12:23 PM, Christoph wrote:
I tried stepping your program with filename “.../pbrt-v3-scenes/simple/buddha.pbrt” but there are no tokens to parse through.
Could you give an exemplary use case?
From: Ingo Wald Sent: Tuesday, January 31, 2017 7:13 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Give me a few secs (or hours!?) ... I just added this parser to our ospray CI build system, which also compiles on windows. the downside is that I'll have to do a lot of pushes of half-ready code, because my only way of getting back a compile result is to push in whatever I just edited, and see what the CI system makes out of it.
Cheers,
Ingo
On 01/31/2017 11:10 AM, Christoph wrote:
I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub
https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276443854,
or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276464095, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwZtY0wusj0ey8T2uPKBuDK95qkdEbvks5rX4oagaJpZM4LxifB.
Chrjstoph
commented
7 years ago Those 3 dots are just to obfuscate my path and avoid confusion. So much for that :)
Materials are written.
Also, I just synced again, build your new stuff and the old problem is gone, however I removed the “PBRT_PARSER_INTERFACE” on members where necessary.
And I have a new linker error, log appended.
Good Night
From: Ingo Wald Sent: Tuesday, January 31, 2017 8:35 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
pretty sure that means that it could not open the file. Just added an exception if that happens; the old code silently ignored that.
Are you sure, for example, about the three dots at the beginning of the filename? If not, check your working dir. It definitely works in my case:
parsing: /home/wald/models/pbrt-v3-scenes/simple/buddha.pbrt
Parsing PBRT World
Parsing PBRT World - done!
==> parsing successful (grammar only for now)
writing Object '
and I also just test-rendred the exported obj with ospray - no materials (that is expected right now), but the geometry is sound.
Cheers,
Ingo
On 01/31/2017 12:23 PM, Christoph wrote:
I tried stepping your program with filename “.../pbrt-v3-scenes/simple/buddha.pbrt” but there are no tokens to parse through.
Could you give an exemplary use case?
From: Ingo Wald Sent: Tuesday, January 31, 2017 7:13 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Give me a few secs (or hours!?) ... I just added this parser to our ospray CI build system, which also compiles on windows. the downside is that I'll have to do a lot of pushes of half-ready code, because my only way of getting back a compile result is to push in whatever I just edited, and see what the CI system makes out of it.
Cheers,
Ingo
On 01/31/2017 11:10 AM, Christoph wrote:
I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub
https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276443854,
or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276464095, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwZtY0wusj0ey8T2uPKBuDK95qkdEbvks5rX4oagaJpZM4LxifB.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Chrjstoph
commented
7 years ago I have burrowed a little further and managed to parse the geometry of the buddha, by hard copying parsePLY.
I take it, you will rearrange that, if time permits.
Note, that you free “free(ply->elems);” in parsePLY.cpp l.363, after having closed the ply object (l.342).
The vs debugger is not happy about that.
From: Ingo Wald Sent: Tuesday, January 31, 2017 8:35 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
pretty sure that means that it could not open the file. Just added an exception if that happens; the old code silently ignored that.
Are you sure, for example, about the three dots at the beginning of the filename? If not, check your working dir. It definitely works in my case:
parsing: /home/wald/models/pbrt-v3-scenes/simple/buddha.pbrt
Parsing PBRT World
Parsing PBRT World - done!
==> parsing successful (grammar only for now)
writing Object '
and I also just test-rendred the exported obj with ospray - no materials (that is expected right now), but the geometry is sound.
Cheers,
Ingo
On 01/31/2017 12:23 PM, Christoph wrote:
I tried stepping your program with filename “.../pbrt-v3-scenes/simple/buddha.pbrt” but there are no tokens to parse through.
Could you give an exemplary use case?
From: Ingo Wald Sent: Tuesday, January 31, 2017 7:13 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Give me a few secs (or hours!?) ... I just added this parser to our ospray CI build system, which also compiles on windows. the downside is that I'll have to do a lot of pushes of half-ready code, because my only way of getting back a compile result is to push in whatever I just edited, and see what the CI system makes out of it.
Cheers,
Ingo
On 01/31/2017 11:10 AM, Christoph wrote:
I’ve pulled your lates update, however you might want to have a look at : https://msdn.microsoft.com/de-de/library/t72ahzw1.aspx
Your members must not be declared with interface, only the structs/classes. I’ll try if it works when I remove the culprits-
From: Ingo Wald Sent: Monday, January 30, 2017 7:57 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
Outch. I'm mostly a linux user; and though most of the infrastructure should be in there to get it working on windows (all of ospcommon is from ospray, for example, which builds fine on windows) I currently have no windows machine to even built it myself to see where it's stuck.
Windows is notoriously fickle with anything DLLs and linking (on windows you have to explicitly export every symbol you want to use; while on linux everything in a dll is visible by default); so I'm pretty sure that 99% of the problem is classes, methods, and functions in pbrt/pbrt.h that are not properly tagged with the right dll export attributes. I just defined a pbrt_parser_EXPORTS define and plugged it to all the "obvious" places; but again, I have no means of even seeing a compile output right now. If you send me a copy-n-paste of VS's error outputs I can fix them, but we'd probably need several iterations of this "you compile and send me the errors; i fix them" procedure. I'd be happy to do this, but not sure how useful that would be to you...
CMake actually helps a lot in this process - it already defines the right "_EXPORTS" flags when including the headers vs when building the DLL; but of course these "PBRT_PARSER_INTERFACE" and "OSPCOMMON_INTERFACE" macros have to be added to every dll function the app is finally going to use. I've just fixed some of the naming, but again, I'd need some windows output to do more than that.... :-/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub
https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276443854,
or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ingowald/pbrt-parser/issues/1#issuecomment-276464095, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwZtY0wusj0ey8T2uPKBuDK95qkdEbvks5rX4oagaJpZM4LxifB.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago My CI tests show this code now compiles and links fine on osx, centos, ubuntu, and windows; can you confirm?
Chrjstoph
commented
7 years ago did you commit?
latest commit was 23h ago
From: Ingo Wald Sent: Wednesday, February 1, 2017 7:42 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
My CI tests show this code now compiles and links fine on osx, centos, ubuntu, and windows; can you confirm?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago I did, but it took a bit more work today - yesterday's code DID compile under windows, but only with intel compiler. CURRENT code also compiles with Microsoft compiler.
Sent from my iPhone
On Feb 1, 2017, at 12:08 PM, Christoph notifications@github.com wrote:
did you commit?
latest commit was 23h ago
From: Ingo Wald Sent: Wednesday, February 1, 2017 7:42 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
My CI tests show this code now compiles and links fine on osx, centos, ubuntu, and windows; can you confirm?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Chrjstoph
commented
7 years ago It compiles smoothly. Though with a lot of warnings.
From: Ingo Wald Sent: Thursday, February 2, 2017 1:48 AM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
I did, but it took a bit more work today - yesterday's code DID compile under windows, but only with intel compiler. CURRENT code also compiles with Microsoft compiler.
Sent from my iPhone
On Feb 1, 2017, at 12:08 PM, Christoph notifications@github.com wrote:
did you commit?
latest commit was 23h ago
From: Ingo Wald Sent: Wednesday, February 1, 2017 7:42 PM To: ingowald/pbrt-parser Cc: Christoph ; Author Subject: Re: [ingowald/pbrt-parser] VS2013, LinkerError FileName, pbrt2obj (#1)
My CI tests show this code now compiles and links fine on osx, centos, ubuntu, and windows; can you confirm?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ingowald
commented
7 years ago confirmed to work; closing this.
Hi, Linking fails. And I fail to find the solution.