Re: Config{libpth} substitution problem

Chris,

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

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