Front page | perl.win32.vanilla |
Postings from October 2011
Re: Config{libpth} substitution problem
Thread Previous
|
Thread Next
From:
chm
Date:
October 31, 2011 13:12
Subject:
Re: Config{libpth} substitution problem
Message ID:
4EAF0110.7060700@gmail.com
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.
>>>
>>
>>
>
Thread Previous
|
Thread Next