Re: Config{libpth} substitution problem

chm Mon, 31 Oct 2011 14:06:21 -0700

On 10/31/2011 4:52 PM, kmx wrote:

Chris,


there is always a chance :) But seriously, we are currently focusing on
releasing 5.14.2.0 (MSI).


Yes, I understand but I figured it wouldn't hurt to ask.
It is a help to me to have SPP editions with different
perl versions.  I've stopped with the SPP 5.10.x because
I started to get gcc crashes for some XO builds.

5.12.3 works well but then this recent hiccup.  At least
the patch appears to work very well so far.  That'll keep
me going until the move to the newest release.  I try to
keep my perl version fairly stable and not too recent.
Otherwise, I end up coding with new features and it is
difficult to verify backwards compatibility.

Thanks for the patch and response,
Chris

Alias is the person to answer the question about the next portable
release. My guess is that it is more likely to see a new
5.14.2.<something>-portable than new 5.12.<whatever>-portable (but it is
just my guess).

--
kmx


On 31.10.2011 21:12, chm wrote:

Thanks, kmx. With the patch applied, I was able
to build and install Prima and Prima::OpenGL on
strawberry perl portable 5.12.3.0. Any chance of
releasing an updated spp with the patch for 5.12?

--Chris

On 10/31/2011 8:13 AM, kmx wrote:

It is a bug in strawberry portable perl - probably the same as
https://rt.cpan.org/Ticket/Display.html?id=68937

According to my testing the enclosed portable_libpth_ugly_hack.diff
should fix it

--
kmx


On 31.10.2011 12:30, chm wrote:

For reference, this problem was for the portable edition at

http://strawberryperl.com/download/5.12.3.0/strawberry-perl-5.12.3.0-portable.zip



with the following perl -V output:

Summary of my perl5 (revision 5 version 12 subversion 3)
configuration:

Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
uname='Win32 strawberryperl 5.12.3.0 #1 Sun May 15 09:44:53 2011 i386'
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX',
optimize='-s -O2',
cppflags='-DWIN32'
ccversion='', gccversion='4.4.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long
long', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++.exe', ldflags ='-s
-L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE"
-L"C:\chm\strawberry\perl_512_3_0\c\lib"'
libpth=C:\chm\strawberry\perl_512_3_0\c\lib
libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32
-lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32
-lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
libc=, so=dll, useshrplib=true, libperl=libperl512.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-mdll -s
-L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE"
-L"C:\chm\strawberry\perl_512_3_0\c\lib"'

Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
USE_SITECUSTOMIZE
Built under MSWin32
Compiled at May 15 2011 14:40:22
@INC:
C:/chm/strawberry/perl_512_3_0/perl/site/lib
C:/chm/strawberry/perl_512_3_0/perl/vendor/lib
C:/chm/strawberry/perl_512_3_0/perl/lib
.


Cheers,
Chris

On 10/31/2011 6:19 AM, Dmitry Karasik wrote:

Hello,

I have I problem with building Prima on strawberry 5.12.3, which
appears when I use
Strawberry installed in something other than c:/strawberry directory.
The problem
didn't re-appear cleanly when I tried to take a clean vmware box, and
install it there,
so I'm not 100% sure how to reproduce it. However a Prima user send
that bug to me,
so there's something wrong not only on my machine.

The problem is as such: Prima needs libgdi32.a, which is not found
because $Config{libpth}
doesn't contain the path to it (it's in
c:/somewhere_else/c/i686-w64-mingw32/lib ). However in Config.pm
there is this line:

libpth => 'C:\\strawberry\\c\\lib
C:\\strawberry\\c\\i686-w64-mingw32\\lib',

which seems valid, but if I call either 'perl -V:libpth' or 'perl
-MConfig -le "print $Config{libpth}"
I get printed

c:\somewhere_else\c\lib

only. Some substitution gone wrong. To test this further I've
temporarily removed Config.pm to see if some
other Config.pm gets picked, - no, it wasn't. Next, I've hacked a
copy of Config.pm into Config2.pm (and renamed
it inside), and unsurprisingly, calling 'perl -MConfig2 -le "print
$Config{libpth}' yielded just that
unsubstituted line:

C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib

I tried to find where the substitution magic is executed to see if
the problem is indeed there, but couldn't
find where it gets done.

So I'll need your help here. If anyone can confirm that (and when)
$Config{libpth} gets hacked, or point me
to the code where the magic is done, that'd be really appreciated.

Re: Config{libpth} substitution problem

Reply via email to