Re: [Plplot-general] Problem with LNK2019 error unresolved external

[David Bergman via Plplot-general]

Two different approaches to the build were given to me.?? But essentially 
the same result, I set an install prefix and the bin, lib, share, and 
doc folders are deposited.?? I was speaking shorthand when I said 
"install dir", I simply meant that I was using the lbs and dlls from the 
correct folders in which they were placed after running the INSTALL 
project.?? I had stated previously that I removed ALL older builds so 
there was NO occurrence of plplot related code anywhere on the machine.



On 10/24/2019 3:59 PM, Alan W. Irwin wrote:

On 2019-10-24 18:36- Ferrell, Stephen via Plplot-general wrote:

If you are using strictly the defaults found in the CmakeLists.txt 
when using Cmake to generate your PLPlot solution file and then 
running the solution file, an install folder will not be created, so 
I'm not sure what you did to end up with an install folder containing 
DLL's and lib files.?? I suspect that your install folder and the 
files in it are from some previous build/installation that's 
incompatible with a 5.15 default build.


Yes, it is true that you should never mix various PLplot versions.
And because of the possibility of version clashes from an old install
folder, if you are working within the build folder you should refer to
nothing in the install folder, e.g., don't refer to the install folder in
your PATH, and better yet, when making a fresh start, always remove
all old install folders before proceeding.

Anyhow, I too am extremely happy to hear from David that he has found 
a solution.


Alan


-- The quality of your thoughts will determine the quality of your life.

 On Thursday, October 24, 2019, 07:45:44 AM MST, David Bergman 
 wrote:



Okay, wow.?? The following seems to have fixed the issue.?? I did not 
exactly what Steve suggested.?? What I did do is point to the



.\source\build\dll directory for the libs and dlls, and used the libs 
in there rather than in the install dir.


I am having some deja vu in that last time I was unable to get the 
install to work and made a monolithic folder canned plplot-man (for 
manual) in which I dropped the dll and lib files into.


I used everything in there just to be sure I didn't miss anything.


I still do not understand why but I'm just glad I'm past it. Could 
the install have corrupted a file that appears in the install 
folders??? Could that have been from the hanging I get using VS 2017 
for the install??? I am not sure if the install project just moves 
files around or implements some additional bindings etc.



Most likely I just did something wrong.?? In that case please accept 
my apologies for wasting your time.?? But thank you all for the help.



David




On 10/24/2019 10:30 AM, David Bergman wrote:


Also, I've been including all lib's in the dependencies.?? I will 
reduce the number.


On 10/24/2019 9:59 AM, David Bergman wrote:


I'll give it a try.?? That last one I tried had every .lib in the 
dependencies.?? Also, I am pointing to the install directories for the 
dll not the build directory.?? Is this not the correct thing to do??? 
Last but not least I am running the x00 example which does not use 
the widgets driver, so I would probably want to swap 
plplotwxwidgets.lib with wingcc.lib


David



On 10/23/2019 11:49 PM, Ferrell, Stephen wrote:

?? In your solution file, does your linker input look similar to 
this??? There should only be 2 link-libs listed.
??C:\plplot-5.15\build\dll\Release\plplotcxx.lib;C:\plplot-5.15\build\dll\Release\plplotwxwidgets.lib;%(AdditionalDependencies) 




??Under Linker/System it should read:
??Console (/SUBSYSTEM:CONSOLE)


??Your C++ pre-processor definitions should be:
??PL_USE_NAMESPACE;WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)


??Under C/C++ Code Generation it should be:
??Multi-threaded DLL (/MD)




??-- The quality of your thoughts will determine the quality of your 
life.


 On Wednesday, October 23, 2019, 02:53:25 PM MST, David Bergman 
 wrote:



Well then I don't know what to do.


Thanks anyway.



On 10/23/2019 5:33 PM, Ferrell, Stephen wrote:

?? This works perfectly on my system.?? As in the examples, plstream is 
delcared globally:

??-- #include "plc++demos.h"
??#ifdef PL_USE_NAMESPACE using namespace std; #endif
??plstream?? ?? ?? ?? ??*pls;

??int main(int argc, char ** argv) { ?? ?? cout << "About to declare and 
new a plstream variable..." << "\n" << endl;

 ?? pls = new plstream();
 ?? cout << "Testing delete plstream..." << "\n" << endl;
 ?? delete pls;
 ?? return 0; }







??-- The quality of your thoughts will determine the quality of your 
life.


 On Wednesday, October 23, 2019, 01:29:38 PM MST, David Bergman 
 wrote:



I didn't think I was trying random things.?? Here is a simple code 
snippet that causes the crash.


int main(int argc, char ** argv)
{
?? cout << "About to declare and new a plstream variable..." << "\n" 
<< endl;

?? plstream *pls;
?? pls = new 

Re: [Plplot-general] Problem with LNK2019 error unresolved external

[Alan W. Irwin]

On 2019-10-24 18:36- Ferrell, Stephen via Plplot-general wrote:


If you are using strictly the defaults found in the CmakeLists.txt when using 
Cmake to generate your PLPlot solution file and then running the solution file, 
an install folder will not be created, so I'm not sure what you did to end up 
with an install folder containing DLL's and lib files.  I suspect that your 
install folder and the files in it are from some previous build/installation 
that's incompatible with a 5.15 default build.


Yes, it is true that you should never mix various PLplot versions.
And because of the possibility of version clashes from an old install
folder, if you are working within the build folder you should refer to
nothing in the install folder, e.g., don't refer to the install folder in
your PATH, and better yet, when making a fresh start, always remove
all old install folders before proceeding.

Anyhow, I too am extremely happy to hear from David that he has found a 
solution.

Alan


-- The quality of your thoughts will determine the quality of your life.

   On Thursday, October 24, 2019, 07:45:44 AM MST, David Bergman 
 wrote:


Okay, wow.  The following seems to have fixed the issue.  I did not exactly 
what Steve suggested.  What I did do is point to the


.\source\build\dll directory for the libs and dlls, and used the libs in there 
rather than in the install dir.

I am having some deja vu in that last time I was unable to get the install to 
work and made a monolithic folder canned plplot-man (for manual) in which I 
dropped the dll and lib files into.

I used everything in there just to be sure I didn't miss anything.


I still do not understand why but I'm just glad I'm past it.  Could the install 
have corrupted a file that appears in the install folders?  Could that have 
been from the hanging I get using VS 2017 for the install?  I am not sure if 
the install project just moves files around or implements some additional 
bindings etc. 


Most likely I just did something wrong.  In that case please accept my 
apologies for wasting your time.  But thank you all for the help. 


David




On 10/24/2019 10:30 AM, David Bergman wrote:


Also, I've been including all lib's in the dependencies.  I will reduce the 
number.

On 10/24/2019 9:59 AM, David Bergman wrote:


I'll give it a try.  That last one I tried had every .lib in the dependencies.  
Also, I am pointing to the install directories for the dll not the build 
directory.  Is this not the correct thing to do?  Last but not least I am 
running the x00 example which does not use the widgets driver, so I would 
probably want to swap plplotwxwidgets.lib with wingcc.lib

David



On 10/23/2019 11:49 PM, Ferrell, Stephen wrote:

  In your solution file, does your linker input look similar to this?  There 
should only be 2 link-libs listed.
 
C:\plplot-5.15\build\dll\Release\plplotcxx.lib;C:\plplot-5.15\build\dll\Release\plplotwxwidgets.lib;%(AdditionalDependencies)


 Under Linker/System it should read:
 Console (/SUBSYSTEM:CONSOLE)


 Your C++ pre-processor definitions should be:
 PL_USE_NAMESPACE;WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)


 Under C/C++ Code Generation it should be:
 Multi-threaded DLL (/MD)




 -- The quality of your thoughts will determine the quality of your life.

 On Wednesday, October 23, 2019, 02:53:25 PM MST, David Bergman 
 wrote:


Well then I don't know what to do. 


Thanks anyway.



On 10/23/2019 5:33 PM, Ferrell, Stephen wrote:

  This works perfectly on my system.  As in the examples, plstream is delcared 
globally:
 --   #include "plc++demos.h"
 #ifdef PL_USE_NAMESPACE using namespace std; #endif
 plstream         *pls;

 int main(int argc, char ** argv) {     cout << "About to declare and new a plstream variable..." 
<< "\n" << endl;
     pls = new plstream();
     cout << "Testing delete plstream..." << "\n" << endl;
     delete pls;
     return 0; }







 -- The quality of your thoughts will determine the quality of your life.

 On Wednesday, October 23, 2019, 01:29:38 PM MST, David Bergman 
 wrote:


I didn't think I was trying random things.  Here is a simple code snippet that 
causes the crash.

int main(int argc, char ** argv)
{
    cout << "About to declare and new a plstream variable..." << "\n" << endl;
    plstream *pls;
    pls = new plstream();

    cout << "Testing delete plstream..." << "\n" << endl;

    delete pls;
    //x00 *x = new x00(argc, argv);
    //delete x;
    return 0;
}

Let me know if I am misusing plstream.  I've #incuded plc++demos.h in the code.




On 10/23/2019 11:57 AM, Phil Rosenberg wrote:

 Hi David
  So you have a build that succeeded. But causes an error at runtime.

  Rather than just trying random things to find a situation where the error 
does not occur - the best course of action next would be to create the minimum 
code sample that  still creates the error.

  So could you start commenting out parts of your example until the 

Re: [Plplot-general] Problem with LNK2019 error unresolved external

[Phil Rosenberg]

And you are correct to point to the install directory, not the build directory.

Phil

On Thu, 24 Oct 2019 at 15:42, Phil Rosenberg  wrote:
>
> Okay, brilliant
> Once you have stripped it down as much as you can, so it still builds, but 
> shows the error, then zip it up and send it out.
>
> Phil
>
> On Thu, 24 Oct 2019 at 15:30, David Bergman  wrote:
>>
>> Also, I've been including all lib's in the dependencies.  I will reduce the 
>> number.
>>
>> On 10/24/2019 9:59 AM, David Bergman wrote:
>>
>> I'll give it a try.  That last one I tried had every .lib in the 
>> dependencies.  Also, I am pointing to the install directories for the dll 
>> not the build directory.  Is this not the correct thing to do?  Last but not 
>> least I am running the x00 example which does not use the widgets driver, so 
>> I would probably want to swap plplotwxwidgets.lib with wingcc.lib
>>
>> David
>>
>>
>> On 10/23/2019 11:49 PM, Ferrell, Stephen wrote:
>>
>> In your solution file, does your linker input look similar to this?  There 
>> should only be 2 link-libs listed.
>>
>> C:\plplot-5.15\build\dll\Release\plplotcxx.lib;C:\plplot-5.15\build\dll\Release\plplotwxwidgets.lib;%(AdditionalDependencies)
>>
>>
>> Under Linker/System it should read:
>>
>> Console (/SUBSYSTEM:CONSOLE)
>>
>>
>> Your C++ pre-processor definitions should be:
>>
>> PL_USE_NAMESPACE;WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)
>>
>>
>> Under C/C++ Code Generation it should be:
>>
>> Multi-threaded DLL (/MD)
>>
>>
>>
>>
>> -- The quality of your thoughts will determine the quality of your life.
>>
>>
>> On Wednesday, October 23, 2019, 02:53:25 PM MST, David Bergman 
>>  wrote:
>>
>>
>> Well then I don't know what to do.
>>
>> Thanks anyway.
>>
>>
>> On 10/23/2019 5:33 PM, Ferrell, Stephen wrote:
>>
>> This works perfectly on my system.  As in the examples, plstream is delcared 
>> globally:
>>
>> --
>> #include "plc++demos.h"
>>
>> #ifdef PL_USE_NAMESPACE
>> using namespace std;
>> #endif
>>
>> plstream *pls;
>>
>>
>> int main(int argc, char ** argv)
>> {
>> cout << "About to declare and new a plstream variable..." << "\n" << 
>> endl;
>>
>> pls = new plstream();
>>
>> cout << "Testing delete plstream..." << "\n" << endl;
>>
>> delete pls;
>>
>> return 0;
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>> -- The quality of your thoughts will determine the quality of your life.
>>
>>
>> On Wednesday, October 23, 2019, 01:29:38 PM MST, David Bergman 
>>  wrote:
>>
>>
>> I didn't think I was trying random things.  Here is a simple code snippet 
>> that causes the crash.
>>
>> int main(int argc, char ** argv)
>> {
>> cout << "About to declare and new a plstream variable..." << "\n" << 
>> endl;
>> plstream *pls;
>> pls = new plstream();
>>
>> cout << "Testing delete plstream..." << "\n" << endl;
>>
>> delete pls;
>> //x00 *x = new x00(argc, argv);
>> //delete x;
>> return 0;
>> }
>>
>> Let me know if I am misusing plstream.  I've #incuded plc++demos.h in the 
>> code.
>>
>>
>> On 10/23/2019 11:57 AM, Phil Rosenberg wrote:
>>
>> Hi David
>> So you have a build that succeeded. But causes an error at runtime.
>>
>> Rather than just trying random things to find a situation where the error 
>> does not occur - the best course of action next would be to create the 
>> minimum code sample that still creates the error.
>>
>> So could you start commenting out parts of your example until the error 
>> stops occurring, in order to isolate which line is causing the error. Once 
>> you have a suspect part, put it back in and comment out as much other stuff 
>> as you can, while still confirming the error occurs.
>>
>> This should then give you a minimum sample with the error. You can confirm 
>> again that this part is causing the problem by removing it again and then 
>> putting it back again
>>
>> Once you have this sample can you zip up the whole sln and send it round and 
>> we can see if we can recreate it.
>>
>> Phil
>>
>> Get Outlook for Android
>>
>> 
>> From: David Bergman 
>> Sent: Wednesday, October 23, 2019 4:30:49 PM
>> To: Arjen Markus ; Phil Rosenberg 
>> ; Plplot-general@lists.sourceforge.net 
>> (plplot-general@lists.sourceforge.net) 
>> Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external
>>
>>
>> I just finished building and installing plplot without wxwidgets drivers.  
>> Still had problems with the install.
>>
>> It hung for a while and had to be restarted, don't know if this causes 
>> corruption.
>>
>> I first built with dyndrivers on and the install crashed with the following 
>> error:
>>
>> ErrorMSB6006"cmd.exe" exited with code 1.test_null_dyndriver
>> C:\Program Files (x86)\Microsoft Visual 
>> Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets   
>>  209
>>
>> I rebuilt with -DTEST_DYNDRIVERS=OFF and that worked.
>>
>> I set up an old example with the new paths (really the same but 

Re: [Plplot-general] Problem with LNK2019 error unresolved external

[Phil Rosenberg]

Sorry David
I just meant, let's try and work out where the error is coming from, rather 
than trying a whole different build.

Somehow I seem to have multiple threads on this, but I just sent an email 
asking if you could you zip up that solution and send it over.

If possible, could you also send the cmake command used to configure the plplot 
build. I have lost track.

Thanks
Phil

Get Outlook for Android


From: Ferrell, Stephen 
Sent: Thursday, October 24, 2019 4:49:20 AM
To: Phil Rosenberg ; Arjen Markus 
; Plplot-general@lists.sourceforge.net 
(plplot-general@lists.sourceforge.net) ; 
David Bergman 
Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external

In your solution file, does your linker input look similar to this?  There 
should only be 2 link-libs listed.

C:\plplot-5.15\build\dll\Release\plplotcxx.lib;C:\plplot-5.15\build\dll\Release\plplotwxwidgets.lib;%(AdditionalDependencies)


Under Linker/System it should read:

Console (/SUBSYSTEM:CONSOLE)


Your C++ pre-processor definitions should be:

PL_USE_NAMESPACE;WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)


Under C/C++ Code Generation it should be:

Multi-threaded DLL (/MD)




-- The quality of your thoughts will determine the quality of your life.


On Wednesday, October 23, 2019, 02:53:25 PM MST, David Bergman 
 wrote:



Well then I don't know what to do.

Thanks anyway.


On 10/23/2019 5:33 PM, Ferrell, Stephen wrote:
This works perfectly on my system.  As in the examples, plstream is delcared 
globally:

--
#include "plc++demos.h"

#ifdef PL_USE_NAMESPACE
using namespace std;
#endif

plstream *pls;


int main(int argc, char ** argv)
{
cout << "About to declare and new a plstream variable..." << "\n" << endl;

pls = new plstream();

cout << "Testing delete plstream..." << "\n" << endl;

delete pls;

return 0;
}








-- The quality of your thoughts will determine the quality of your life.


On Wednesday, October 23, 2019, 01:29:38 PM MST, David Bergman 
 wrote:



I didn't think I was trying random things.  Here is a simple code snippet that 
causes the crash.

int main(int argc, char ** argv)
{
cout << "About to declare and new a plstream variable..." << "\n" << endl;
plstream *pls;
pls = new plstream();

cout << "Testing delete plstream..." << "\n" << endl;

delete pls;
//x00 *x = new x00(argc, argv);
//delete x;
return 0;
}

Let me know if I am misusing plstream.  I've #incuded plc++demos.h in the code.


On 10/23/2019 11:57 AM, Phil Rosenberg wrote:
Hi David
So you have a build that succeeded. But causes an error at runtime.

Rather than just trying random things to find a situation where the error does 
not occur - the best course of action next would be to create the minimum code 
sample that still creates the error.

So could you start commenting out parts of your example until the error stops 
occurring, in order to isolate which line is causing the error. Once you have a 
suspect part, put it back in and comment out as much other stuff as you can, 
while still confirming the error occurs.

This should then give you a minimum sample with the error. You can confirm 
again that this part is causing the problem by removing it again and then 
putting it back again

Once you have this sample can you zip up the whole sln and send it round and we 
can see if we can recreate it.

Phil

Get Outlook for Android


From: David Bergman 

Sent: Wednesday, October 23, 2019 4:30:49 PM
To: Arjen Markus ; 
Phil Rosenberg ; 
Plplot-general@lists.sourceforge.net
 
(plplot-general@lists.sourceforge.net)
 

Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external


I just finished building and installing plplot without wxwidgets drivers.  
Still had problems with the install.

It hung for a while and had to be restarted, don't know if this causes 
corruption.

I first built with dyndrivers on and the install crashed with the following 
error:

ErrorMSB6006"cmd.exe" exited with code 1.test_null_dyndriver
C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets
209

I rebuilt with -DTEST_DYNDRIVERS=OFF and that worked.

I set up an old example with the new paths (really the same but with new files) 
and new dll and lib files as needed.

It ran fine but crashed upon closing with the ntdll.dll heap error again.

I also ran a wxWidgets sample and that ran and closed without issue so I am not 
sure but this may rule out widgets.

I am going to try and down load an older version of 

Re: [Plplot-general] Problem with LNK2019 error unresolved external

[Phil Rosenberg]

Hi David
So is that basically a 2 line example?
plstream *stream = new plstream;
delete stream;

If so, then as I suggested, please could you zip up that solution and send it 
over.

Phil

Get Outlook for Android


From: stuntguitar1969 
Sent: Wednesday, October 23, 2019 5:01:05 PM
To: Phil Rosenberg ; Arjen Markus 
; Plplot-general@lists.sourceforge.net 
(plplot-general@lists.sourceforge.net) 
Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external

I'm using the smallest plplot example and according to the debugger it crashes 
upon calling delete on the plstream variable.   That has always been the case.




Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Phil Rosenberg 
Date: 10/23/19 11:57 AM (GMT-05:00)
To: Arjen Markus , 
"Plplot-general@lists.sourceforge.net (plplot-general@lists.sourceforge.net)" 
, David Bergman 

Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external

Hi David
So you have a build that succeeded. But causes an error at runtime.

Rather than just trying random things to find a situation where the error does 
not occur - the best course of action next would be to create the minimum code 
sample that still creates the error.

So could you start commenting out parts of your example until the error stops 
occurring, in order to isolate which line is causing the error. Once you have a 
suspect part, put it back in and comment out as much other stuff as you can, 
while still confirming the error occurs.

This should then give you a minimum sample with the error. You can confirm 
again that this part is causing the problem by removing it again and then 
putting it back again

Once you have this sample can you zip up the whole sln and send it round and we 
can see if we can recreate it.

Phil

Get Outlook for Android


From: David Bergman 
Sent: Wednesday, October 23, 2019 4:30:49 PM
To: Arjen Markus ; Phil Rosenberg 
; Plplot-general@lists.sourceforge.net 
(plplot-general@lists.sourceforge.net) 
Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved external


I just finished building and installing plplot without wxwidgets drivers.  
Still had problems with the install.

It hung for a while and had to be restarted, don't know if this causes 
corruption.

I first built with dyndrivers on and the install crashed with the following 
error:

ErrorMSB6006"cmd.exe" exited with code 1.test_null_dyndriver
C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets
209

I rebuilt with -DTEST_DYNDRIVERS=OFF and that worked.

I set up an old example with the new paths (really the same but with new files) 
and new dll and lib files as needed.

It ran fine but crashed upon closing with the ntdll.dll heap error again.

I also ran a wxWidgets sample and that ran and closed without issue so I am not 
sure but this may rule out widgets.

I am going to try and down load an older version of plplot.  Many folks who 
have tried to recreate the issue were building with slight different set ups, 
older plplot and widgets, older VS version.  Could it be that the "most recent" 
was not stable?

David



On 10/23/2019 6:13 AM, Arjen Markus wrote:
Hi David,

Perhaps try the most basic set-up of PLplot first indeed. So no default 
drivers, only C bindings etc. The problem you are facing looks to be connected 
to your particular computer system, so let’s eliminate as many potential 
problem dimensions as possible.

Regards,

Arjen

From: stuntguitar1969 

Sent: 23 October 2019 12:10
To: Arjen Markus ; 
Phil Rosenberg ; 
Plplot-general@lists.sourceforge.net
 
(plplot-general@lists.sourceforge.net)
 

Subject: RE: [Plplot-general] Problem with LNK2019 error unresolved external

This is a pure plplot example, not the wxplplot example.  I don't think I'm 
invoking the widgets driver.  Unless it's always being invoked because widgets 
was connected in the build stage.  I could try building plplot with widgets off 
and see.



Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Arjen Markus mailto:arjen.mar...@deltares.nl>>
Date: 10/23/19 3:15 AM (GMT-05:00)
To: David Bergman 
mailto:stuntguitar1...@gmail.com>>, Phil Rosenberg 
mailto:p.d.rosenb...@gmail.com>>, 
"Plplot-general@lists.sourceforge.net 
(plplot-general@lists.sourceforge.net)"
 
mailto:plplot-general@lists.sourceforge.net>>
Subject: RE: [Plplot-general] Problem with LNK2019 error unresolved external

Hi David,

Have you tried to