wxperl-users

Re: [wxperl-users] WxPerl 0.06 compilation on Win32

[Mattia B. <mb...@ds...>]

> wxPerl 0.06 source tarball
> wxWindows 2.26
> Win2000 Version 5.00.2195
> 
>     "gcc -v" lists gcc version as:
> Reading specs from
> c:\gcc-2.95.2-1\bin\..\lib\gcc-lib\mingw32\2.95.2\specs gcc driver
> version 2.95.2 19991024 (release) executing gcc version 2.95.2-mingw
> snapshot 20010329
I use a different one:
----
Reading specs from C:\Programmi\Devel\GCC\bin\..\lib\gcc-
lib\mingw32\2.95.2\specs
gcc driver version 2.95.2 19991024 (release) executing gcc version 
2.95.2-20001116
----
 but maybe it is an ld / libbfd problem...

>     wxWindows dll compiles fine, wxWindows samples compile and run
>     fine,
> wxPerl 0.05 source compiles, tests, and runs fine. Compiling wxPerl
> 0.06 reports no errors, but running "dmake test" does the following..
> 
> C:\Wx-0.06>dmake test
> C:\Perl\bin\Perl.exe -Mblib -IC:\Perl\lib -IC:\Perl\lib -e "use
> Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;"
> t\1_load.t t\2_inheritance.t Using C:/Wx-0.06/blib
> t\1_load............Can't load 'C:/Wx-0.06/blib/arch/auto/Wx/Wx.dll'
> for module Wx: load_file:Invalid access to memory location at
mmm... weird

>     Not sure what's going on here, especially since this compiler
>     setup
> works for everything _but_ wxPerl 0.06 (and higher, a cvs snapshot
> pulled this afternoon (May 2 2001) from sourceforge had the same
> results). I did notice that the makefile is using "g++ -shared" to
> make the wx dll's, rather than the "old", 2 step linking process used
> by the wxPerl 0.05 makefile (and the wxWindows 2.2.6 makefiles).
FWIW wxWindows 2.2.6 can be set up to use g++ -shared ( there is a
 comment in src/makeg95.env )

Anyway...
in wxPerl source tree
build/Win32_MinGW.pm , at the bottom there is a function starting
like this:

sub dynamic_lib {
  package MY;

  my( $this ) = shift;
  my( $text ) = $this->SUPER::dynamic_lib( @_ );

  return $text unless $text =~ m/dlltool/i;

  my $wximplib = MM->catfile( wxConfig::top_dir(),
                              qw(blib arch auto Wx Wx.a) );
 

change the line
  return $text unless $text =~ m/dlltool/i;
to
  return $text;

and redo the whole build ( perl Makefile.PL ; ... )
And let me know it it works...
Sorry for the bug, I use g++ -shared because it is faster, and
should be better in general...

BTW, your bug report is _great_
  ( I mean: detailed / well explained )

Thanks
Mattia

Re: [wxperl-users] WxPerl 0.06 compilation on Win32

[Mattia B. <mb...@ds...>]

> > > wxPerl 0.06 source tarball
> > > wxWindows 2.26
> > > Win2000 Version 5.00.2195

> Okay, we tried using the new USE_SHARED option in the cvs (grabbed
No, don't use it: using USE_SHARED you end up linking with
g++ -shared _as it did previously_, by _not_ using it
( or setting USE_SHARED=0 ) you should obtain a dlltool/dllwrap
default linking... the point of USE_SHARED is that I can use it
for developement, while people not knowing/using it obtain a standard
( hopefully safe... ) build, or know what they are doing
Sorry again for the wasted time.

> using cvs, not the nightly zip, (since you wanted to know)) copy, but
> that did not make a difference (i.e. still get the same error on
> "dmake test"). We think that maybe trying to get a mingw setup more
if you built with
perl Makefile.PL USE_SHARED=1

the results should be _identical_ to previous results

> closely identical to yours may be the next thing to try. Part of the
> problem may be incorrect/incompatible versions of the various mingw
> packages, and part of the problem may simply be that we aren't
> unpacking them all together quite correctly.
1 - if they are grabbed at the same time, there shuold be no problem
2 - if GCC works & compiles wxWIndows & wxPerl, it is unlikely
    that you have an unpacking problem... usually unpacking
    problems result in weird compile/link time errors
 
> To at least make sure that we are trying to work with the same
> versions, we'd like to know (if you could) what versions/dates of the
> various mingw packages you use. The packages that we have been
> downloading are the following:
 
binutils-2.10.91-20010114.zip
gcc-2.95.2-20001116.zip
ld-2.10.91-20010126.zip
libbfd-2.10.91-20010121.zip
make-3.77-mingw32.zip
mingw-runtime-0.5-20010221.tar.gz
mingw32-docs-html.exe
w32api-0.5-20010301.tar.gz

But is probably time that I get the "latest all" and try it out

> (We have been using 0.4 of mingw-runtime and w32api, to avoid having
> to go through the trouble of needing to patch the wxWindows source.)
Different w32api versions should not make any difference, anyway

Thanks for your patience...
Mattia

Re: [wxperl-users] WxPerl 0.06 compilation on Win32

[D.J.Moon <lm...@es...>]

> if you built with
> perl Makefile.PL USE_SHARED=1
>
> the results should be _identical_ to previous results
>

Sorry for not being quite clear before, we were doing
perl Makefile.PL USE_SHARED=0
..trying again with simply not specifying USE_SHARED at all had the same
results (it used dlltool, and still broke anyway)

> 1 - if they are grabbed at the same time, there shuold be no problem
> 2 - if GCC works & compiles wxWIndows & wxPerl, it is unlikely
>     that you have an unpacking problem... usually unpacking
>     problems result in weird compile/link time errors
>

That is good to know, at least by way of eliminating a level of paranoia
about what could be wrong.

>
> binutils-2.10.91-20010114.zip
> gcc-2.95.2-20001116.zip
> ld-2.10.91-20010126.zip
> libbfd-2.10.91-20010121.zip
> make-3.77-mingw32.zip
> mingw-runtime-0.5-20010221.tar.gz
> mingw32-docs-html.exe
> w32api-0.5-20010301.tar.gz
>

Tried these versions of the packages (well, with w32api 0.4), wxPerl
compiled fine again, and broke again in the same way. This is really wierd.
We have no idea what else could be going on here.

Re: [wxperl-users] WxPerl 0.06 compilation on Win32

[Mattia B. <mb...@ds...>]

> Sorry for not being quite clear before, we were doing
> perl Makefile.PL USE_SHARED=0
> ..trying again with simply not specifying USE_SHARED at all had the
> same results (it used dlltool, and still broke anyway)
I was _really_ hoping it was that simple...

> > binutils-2.10.91-20010114.zip
> > gcc-2.95.2-20001116.zip
> > ld-2.10.91-20010126.zip
> > libbfd-2.10.91-20010121.zip
> > make-3.77-mingw32.zip
> > mingw-runtime-0.5-20010221.tar.gz
> > mingw32-docs-html.exe
> > w32api-0.5-20010301.tar.gz
> >
> 
> Tried these versions of the packages (well, with w32api 0.4), wxPerl
> compiled fine again, and broke again in the same way. This is really
> wierd. We have no idea what else could be going on here.
Just to be sure, I did a fresh GCC install with these packages
( and w32api/mingw-runtime 0.4 ); after some header moving
( I have the w32api with the wrong packaging scheme... ), it
compiled wxWindows, ( just had to change typedef long INT32; ->
typedef int INT32; in jmorecfg.h ), then did a build
with perl -MConfig_m Makefile.PL in the cvs snapshot you're
using, guess what? all compiled/linked/run fine...

Last chance: send me your build log ( dmake > build.log )
I _now_ remember I had a similar problem: it was caused
by some combination of -mdll -lmsvcrt, or something like this
( the problem is that I don't remember if it happened with ActivePerl
  or perl built from sources, with dlltool or -shared... )
If it is this, it is a bug in Config_m.pm

Thanks
Mattia

Re: [wxperl-users] WxPerl 0.06 compilation on Win32

[D.J.Moon <lm...@es...>]

----- Original Message -----
From: "Mattia Barbon" <mb...@ds...>
To: <wxp...@li...>
Sent: Wednesday, May 02, 2001 5:07 PM
Subject: Re: [wxperl-users] WxPerl 0.06 compilation on Win32


> > wxPerl 0.06 source tarball
> > wxWindows 2.26
> > Win2000 Version 5.00.2195
> >
> >     "gcc -v" lists gcc version as:
> > Reading specs from
> > c:\gcc-2.95.2-1\bin\..\lib\gcc-lib\mingw32\2.95.2\specs gcc driver
> > version 2.95.2 19991024 (release) executing gcc version 2.95.2-mingw
> > snapshot 20010329
> I use a different one:
> ----
> Reading specs from C:\Programmi\Devel\GCC\bin\..\lib\gcc-
> lib\mingw32\2.95.2\specs
> gcc driver version 2.95.2 19991024 (release) executing gcc version
> 2.95.2-20001116
> ----
>  but maybe it is an ld / libbfd problem...
>

Okay, we tried using the new USE_SHARED option in the cvs (grabbed using
cvs, not the nightly zip, (since you wanted to know)) copy, but that did not
make a difference (i.e. still get the same error on "dmake test"). We think
that maybe trying to get a mingw setup more closely identical to yours may
be the next thing to try. Part of the problem may be incorrect/incompatible
versions of the various mingw packages, and part of the problem may simply
be that we aren't unpacking them all together quite correctly.

To at least make sure that we are trying to work with the same versions,
we'd like to know (if you could) what versions/dates of the various mingw
packages you use. The packages that we have been downloading are the
following:

binutils
gcc (but we already know you're using gcc-2.95.2-20001116)
ld
libbfd
mingw-runtime
w32api

(We have been using 0.4 of mingw-runtime and w32api, to avoid having to go
through the trouble of needing to patch the wxWindows source.)