Convert dynamic lib to static lib

Convert dynamic lib to static lib

[Sisyphus]

Hi,

I have a dynamic library that someone else has compiled - it's in fact 
the pgplot library built for Win32.

It contains:
cpgplot.h
libcpgplot.a
libcpgplot.dll
libpgplot.a
libpgplot.dll

When I build my apps I include the header file and link to the 2 '.a' 
files, and they build and run fine. But this is a dynamic build - and 
the 2 dll's need to be locatable at runtime.

For a particular project I would like to have a static build of that 
pgplot library - one that doesn't involve the loading of any dll's. Is 
it possible to convert that dynamic build that I have into a static 
build - and if so, how ?

I'm hoping to avoid having to compile pgplot from source as it looks 
like a bugger of a job on Win32.

Cheers,
Rob

Re: Convert dynamic lib to static lib

[Eljay Love-Jensen]

Hi Rob,

I don't know of any way to make a dynamically linked library (.dll or .so) 
into a statically linked archive library (.lib or .a).

I believe you'll have to recompile the source of the two .dll's (or at 
minimum, ar together the .o files - presuming there's no DLL 
instrumentation that happens to the object files at compile time) as an 
archive library instead of a shared library.

HTH,
--Eljay

Re: Convert dynamic lib to static lib

[Sisyphus]

Eljay Love-Jensen wrote:
> Hi Rob,
> 
> I don't know of any way to make a dynamically linked library (.dll or 
> .so) into a statically linked archive library (.lib or .a).
> 
> I believe you'll have to recompile the source of the two .dll's (or at 
> minimum, ar together the .o files - presuming there's no DLL 
> instrumentation that happens to the object files at compile time) as an 
> archive library instead of a shared library.
>

I found that I could extract the object files from the 2 '.a' files 
(with 'ar x') and then re-archive those object files with 'ar rc' ... 
but that just gets me back to where I started, and the dll's are still 
needed at runtime.

I'll have a crack at building a static library from source.

Thanks Eljay.

The folowing is superfluous and waaaay OT, but if anyone wants to offer 
some thoughts, they're welcome.

The project is to get the perl module 'PGPLOT-2.18' built. It actually 
compiles fine, but when I come to use it, I immediately get the fatal 
error that a particular "procedure entry point" in the pgplot.dll could 
not be found. I thought that if I could build the perl module against a 
static build of pgplot then, if the problem did not go away, it might 
present itself as something I knew how to deal with .... for I have 
absolutely no idea of how to deal with this current manifestation :-)

When I build C apps against this pgplot shared library, there is 
absolutely no problem .... so it's something in the PGPLOT-2.18 perl 
source that's triggering the problem. I've spent hours hacking at the 
source, trying to locate a cause for the error, but it still eludes me.

 From what I can gather, the complaint that the "procedure entry point 
for foo could not be found" is just telling me that the "foo" function 
aint in the dll, but it was expected to be there. But this particular 
"foo" isn't even mentioned in the perl module source.

I've tried contacting both the author of the perl module and the builder 
of the pgplot shared library - but neither has replied (as is their right).

So near and yet so far ....

Cheers,
Rob

RE: Convert dynamic lib to static lib

[lrtaylor]

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...

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Sisyphus
Sent: Friday, October 15, 2004 4:51 PM
Cc: gcc
Subject: Re: Convert dynamic lib to static lib

Eljay Love-Jensen wrote:
> Hi Rob,
> 
> I don't know of any way to make a dynamically linked library (.dll or 
> .so) into a statically linked archive library (.lib or .a).
> 
> I believe you'll have to recompile the source of the two .dll's (or at

> minimum, ar together the .o files - presuming there's no DLL 
> instrumentation that happens to the object files at compile time) as
an 
> archive library instead of a shared library.
>

I found that I could extract the object files from the 2 '.a' files 
(with 'ar x') and then re-archive those object files with 'ar rc' ... 
but that just gets me back to where I started, and the dll's are still 
needed at runtime.

I'll have a crack at building a static library from source.

Thanks Eljay.

The folowing is superfluous and waaaay OT, but if anyone wants to offer 
some thoughts, they're welcome.

The project is to get the perl module 'PGPLOT-2.18' built. It actually 
compiles fine, but when I come to use it, I immediately get the fatal 
error that a particular "procedure entry point" in the pgplot.dll could 
not be found. I thought that if I could build the perl module against a 
static build of pgplot then, if the problem did not go away, it might 
present itself as something I knew how to deal with .... for I have 
absolutely no idea of how to deal with this current manifestation :-)

When I build C apps against this pgplot shared library, there is 
absolutely no problem .... so it's something in the PGPLOT-2.18 perl 
source that's triggering the problem. I've spent hours hacking at the 
source, trying to locate a cause for the error, but it still eludes me.

 From what I can gather, the complaint that the "procedure entry point 
for foo could not be found" is just telling me that the "foo" function 
aint in the dll, but it was expected to be there. But this particular 
"foo" isn't even mentioned in the perl module source.

I've tried contacting both the author of the perl module and the builder

of the pgplot shared library - but neither has replied (as is their
right).

So near and yet so far ....

Cheers,
Rob

Re: Convert dynamic lib to static lib

[Sisyphus]

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