From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19126 invoked by alias); 16 Oct 2004 01:18:02 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 19085 invoked from network); 16 Oct 2004 01:18:01 -0000 Received: from unknown (HELO mail.iinet.net.au) (203.59.3.38) by sourceware.org with SMTP; 16 Oct 2004 01:18:01 -0000 Received: (qmail 2788 invoked from network); 16 Oct 2004 01:17:59 -0000 Received: from unknown (HELO iinet.net.au) (203.217.35.149) by mail.iinet.net.au with SMTP; 16 Oct 2004 01:17:58 -0000 Message-ID: <41707584.5090007@iinet.net.au> Date: Sat, 16 Oct 2004 01:18:00 -0000 From: Sisyphus User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 MIME-Version: 1.0 CC: gcc-help@gcc.gnu.org Subject: Re: Convert dynamic lib to static lib References: <363801FFD7B74240A329CEC3F7FE4CC4030963B1@ntxboimbx07.micron.com> In-Reply-To: <363801FFD7B74240A329CEC3F7FE4CC4030963B1@ntxboimbx07.micron.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00124.txt.bz2 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