Re: Convert dynamic lib to static lib

[Sisyphus <kalinabears at iinet dot net dot au>]

lrtaylor@micron.com wrote:
> Since the .o files are in the static libraries, that makes me think that
> you're not linking to them correctly, or that behind the scenes, the
> Perl module's Makefiles are still causing it to link to the shared DLLs.
> That is, it may not be a problem with your libraries, but the way that
> the PGPlot Makefiles are configured.  I guess that my point is that
> maybe you need to consider changing directions and take a look at that
> possibility before you spend too much time trying to rebuild your
> libraries...

Even in the purely C environment, I'm unable to compile apps that don't 
need the dll's at runtime.

gcc -static -o myapp.exe myapp.c -LD:/pgplot/lib -lcpgplot -lpgplot

At that stage it doesn't matter if the dll's can't be found, but when I 
come to run myapp.exe, it needs to load the 2 pgplot dll's. This leads 
me to believe that this particular pgplot library can be used only as a 
dynamic library - please correct me if that might not be the case.

Wrt C programs there's no problem with these dll's (that I can uncover, 
anyway). It's only when this perl module gets added to the mix that the 
problem arises. It's really quite strange.

I think you're right in that there's probably a solution to be found in 
altering the perl source - perhaps even in the makefiles as you suggest 
- but it's my inability to uncover that solution that led me to the 
possibility of building against a static lib. At least then I'm 
guaranteed of not getting *that* particular error :-)

One possibility that has just occurred to me is that since perl also 
builds its own pgplot.dll, perhaps there's some confusion 

                             regarding which of the 2 pgplot.dll's the 
procedure entry point is to be found in. ie perl might be looking in the 
wrong one ... and in fact that was the precise problem all along .... 
shit!!!!

I've just taken 15 minutes to rename the perl module to WPGPLOT (and 
make the necessary associated changes). This means that the perl dll 
that gets built is called wgplot.dll, and no confusion can arise. When I 
do that and recompile the module, all works fine. Bum!!!!!!!
Now all I have to do is uncover the "proper" way of fixing this. Come to 
think of it - my original idea of building the module against a static 
build of the PGPLOT library would probably work as there would only be 
the one (perl) pgplot.dll. I guess that would constitute one "proper" 
way of fixing the problem.

I hope I haven't taken up too much of your time with this - and thanks 
for the replies.

Cheers,
Rob