Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2014-04-06

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 rurban joined #perl11
00:11 Will_the_Chill rurban: surfing today?  :)
00:38 bulk88 <@Will_the_Chill> bulk88: your code is dying because the code must have write permission to it's own directories:
00:38 bulk88 explain
00:40 Will_the_Chill as shown, rperltypes_mode.h needs to be able to rename itself to rperltypes_mode.h.orig, etc
00:41 bulk88 everything in /blib is marked read-only by EUMM during the build process
00:41 Will_the_Chill then why does it work fine for me?
00:42 bulk88 http://i61.tinypic.com/ny71nq.png notice most of the files have "R" on them
00:43 bulk88 under attributes colum
00:44 bulk88 i'm not sure what .pms are marked as on *nix perms wise
00:46 bulk88 EUMM chmod eerything to 755 on windows
00:46 bulk88 but what is 755 on Win32? ;-)
00:57 Will_the_Chill just a min
00:58 Will_the_Chill okay it is just the lib/ directories themselves that must be writable by the user running the program
01:00 Will_the_Chill originally the lib/ directory was set to be writable by my wbraswell user on my machine, so that when I ran the software as wbraswell it could rename the rperltypes_mode.h files as mentioned, and those files used to only be in the lib/ directory
01:00 Will_the_Chill now all of that is presumably happening in the blib/lib/ directory instead
01:00 Will_the_Chill because I think I successfully changed everything over from lib/ to blib/lib/ last night
01:01 Will_the_Chill $ ls -l blib
01:01 bulk88 http://paste.scsys.co.uk/342089 here is what a dmake -n (show dont run_) on a clean tree looks like
01:01 Will_the_Chill drwxr-xr-x 5 wbraswell wbraswell 4096 2014-04-05 20:01 lib
01:01 Will_the_Chill my blib/lib/ is created as rwx for my user wbraswell when I run make
01:02 Will_the_Chill so you need to throw in an extra command to make the blib/lib/ directory writable to yourself???
01:04 bulk88 ... /lib isn't supposed to be writable at runtime, use /tmp for that
01:05 Will_the_Chill well for now you can make it work with one command
01:05 bulk88 on your own system "drwxr-xr-x " you cant write to it
01:05 bulk88 you can, but not other users
01:05 Will_the_Chill yeah, I can, so it works
01:06 bulk88 ill strip the RO and do admake test again and see what happens
01:06 Will_the_Chill roger, let me know what the command is and I'll put it in INSTALL
01:06 rurban joined #perl11
01:07 bulk88 my point is,  you'll have to fix that one day, I think on *nix only root can install system wide  perl modules, the files are RO to normal users
01:08 bulk88 if RPelr is to be installing like a normal PM, then it cant runtime write to itself
01:08 bulk88 not in /lib
01:08 Will_the_Chill yes I understand
01:13 bulk88 http://msdn.microsoft.com/en-us/library/1z319a54%28v=vs.71%29.aspx MS does implement a chmod but its docs are useleslly vague
01:32 Will_the_Chill uh, I guess you just do the equivalent of chmod by some point-and-click?
01:38 bulk88 dmake test is still running
01:38 Will_the_Chill roger
01:39 bulk88 http://paste.scsys.co.uk/342118
01:39 bulk88 done
01:42 Will_the_Chill looks like the same error to me!
01:44 Will_the_Chill tme6Wgux
01:44 Will_the_Chill oops I mean...  died: Can't move rperltypes_mode.h input file to rperltypes_mode.h.orig: Permission denied, dying at C:\sources\rperl\blib\lib/rperltypes.pm
01:47 bulk88 the files aren't marked RO
01:47 Will_the_Chill the directory
01:47 Will_the_Chill blib/lib/ must be writable
01:48 Will_the_Chill that's what I was saying
01:48 bulk88 something has a lock on the file
01:48 Will_the_Chill oh well I don't know about any file lock?
01:48 bulk88 ill start ressearching
01:49 Will_the_Chill those rperltypes_mode.h files are what the C compiler uses to determine if it should compile in Perl types mode or C++ types mode
01:50 Will_the_Chill so whenever you switch modes, it switches around 1 or 2 lines on those files
02:04 rurban joined #perl11
02:05 bulk88 http://www.tradercounselor.com/stock_trading_computers_8screens.jpg do you write all your code on one of these? rperltype.pm is very hard to read, even with lien wrapping
02:06 Will_the_Chill I just have a regular little laptop
02:07 mirjam joined #perl11
02:07 bulk88 in sub types_enable  , you close $TYPES_H_FILEHANDLE_OUT but I dont see a matching close for $TYPES_H_FILEHANDLE_IN
02:07 bulk88 why?
02:08 Will_the_Chill uh, looks like that may be an error on my part
02:09 Will_the_Chill are you saying that may be causing the file locking issue?
02:10 bulk88 im rerunnign the 04.t with a 2nd close now, ill see what happens
02:10 Will_the_Chill roger
02:12 bulk88 only 8 out of 273 fail on 04.t now, previously it was ~25
02:13 bulk88 "input " is gone nmow
02:13 bulk88 *now
02:13 bulk88 "Can't move rperltypes_mode.h input file to rperltypes_mode.h.orig: Permission denied, dying at C:\sources\rperl\blib\lib/rperltypes.pm line 118, <$TYPES_H_FILEHANDLE_IN> line 9." is gone now
02:13 bulk88 close($TYPES_H_FILEHANDLE_OUT);
02:13 bulk88 close($TYPES_H_FILEHANDLE_IN);
02:13 bulk88
02:13 bulk88 if ($rperltypes_h_modified)
02:16 Will_the_Chill got it, testing on my machine to make sure
02:17 mirjam joined #perl11
02:20 bulk88 03.t is going to need the NO_XSLOCKS define, it crashes every time right on schedule, since 03.t isn't rperl specific the flag you added yesterday has no effect on 03.t
02:20 bulk88 make test is still running
02:21 Will_the_Chill tests pass on my machine w/ the second close()
02:21 Will_the_Chill will look at 03.t now
02:27 bulk88 there are 2 close($TYPES_H_FILEHANDLE_OUT);s in rperltypes.pm, one of them is before a die, you probably want 2 closes on _IN then
02:28 Will_the_Chill roger, wilco
02:30 Will_the_Chill an I just overwrite the CCFLAGS for 03.t or do I have to do the same thing with $Config{ccflags} again?
02:33 Will_the_Chill and also, do we not need to worry about -DNO_XSLOCKS in 02.t?
02:36 Will_the_Chill oh, well according to http://search.cpan.org/~davido/Inline-CPP-0.49/lib/Inline/CPP.pod#CCFLAGS
02:36 Will_the_Chill CCFLAGS
02:36 Will_the_Chill Specifies extra compiler flags. Corresponds to the MakeMaker option.
02:36 Will_the_Chill "extra" compiler flags
02:37 Will_the_Chill which means our $Config stuff in lib/RPerl/Inline.pm may be redundant???
02:37 Will_the_Chill CCFLAGS => $Config{ccflags} . ' -DNO_XSLOCKS -Wno-deprecated -std=c++0x -Wno-reserved-user-defined-literal -Wno-literal-suffix',
02:37 bulk88 CCFLAGSEX is for extra ones
02:37 bulk88 CCFLAGS ovverwrrites
02:38 Will_the_Chill no, CCFLAGSEX is for extra ones in Inline::C
02:38 Will_the_Chill I'm talking about Inline::CPP
02:38 Will_the_Chill two different packages
02:38 bulk88 if CCFLAGSEX doesnt exist, then you need $Config{ccflags}
02:38 Will_the_Chill unless you've dug into the code and know this to be true, I'm just going off the docs
02:38 bulk88 i havent dug in
02:38 Will_the_Chill CCFLAGSEX exists for Inline::C, not for Inline::CPP
02:39 bulk88 1 moment i need to researcg my git
02:39 Will_the_Chill but the docs for Inline::CPP CCFLAGS clearly says "extra compiler flags" as shown abovve
02:39 bulk88 +use Inline  (CPP => Config => CCFLAGSEX => ' -DNO_XSLOCKS ');
02:39 bulk88 thats why i put on 03.t to stop the crash yesterday\
02:40 bulk88 *thats what I put in 03.t
02:41 Will_the_Chill huh, Inline::CPP docs don't show CCFLAGSEX
02:42 Will_the_Chill Inline::CPP requires Inline::C, so it must be getting CCFLAGSEX from Inline::C
02:45 Will_the_Chill okay I've updated lib/RPerl/Inline.pm to use CCFLAGSEX instead of CCFLAGS and disabled the $Config stuff, also updated 03.t to use CCFLAGSEX for -DNO_XSLOCKS
02:45 Will_the_Chill testing now on my machine
02:50 Will_the_Chill tests pass, new code on github, please give it a try
02:53 travis-ci [travis-ci] RPerl Commit By Will Braswell. The build passed. http://travis-ci.org/wbraswell/rperl/builds/22366391
02:55 Will_the_Chill hey, thanks travis!  :D
02:57 bulk88 im still doing a make test, i have a feel we will run into C++11 issues later today since I'm seeing C/++ syntax errors in the console already (the test is still running)
02:57 bulk88 *feeling
02:58 Will_the_Chill wow make test only takes like 1 - 2 minutes in Linux
03:00 bulk88 http://paste.scsys.co.uk/342186 down from 25 fails in 04.t to 8
03:00 bulk88 ill try your git now
03:03 Will_the_Chill cool beans
03:05 Will_the_Chill from your latest paste:
03:05 Will_the_Chill C:\sources\rperl\_Inline\build\eval_760_f05a\Filters3604.c:2:46: error: 'std::to_string' has not been declared
03:12 Will_the_Chill a-ha, I bet it is because of this, also from your last paste:
03:12 Will_the_Chill Warning (mostly harmless): No library found for -lstdc++
03:13 Will_the_Chill I'm guessing there are lots of things that will break if libstdc++ can't be loaded
03:17 bulk88 if you google that, GCC's devs and mingw's devs are acting like HS girls over the issue
03:17 rurban joined #perl11
03:17 bulk88 doing new make tests
03:18 bulk88 with RO blib, its back to 25 failed tests in 04.t
03:18 Will_the_Chill rurban: hey look at us compiling RPerl in Windows.  :)
03:18 Will_the_Chill bulk88: yeah you have to manually make blib writable
03:18 Will_the_Chill I have no way to automate that
03:18 bulk88 automate what?
03:19 Will_the_Chill automate the making of blib/ writable
03:19 Will_the_Chill I did put it in the INSTALL notes!
03:19 bulk88 id have to research the history of the chmod 755 code and why EUMM parts make it
03:19 bulk88 i may do it later if I have time
03:19 bulk88 *and what EUMM parts make oit
03:20 Will_the_Chill cool
03:23 bulk88 http://stackoverflow.com/questions/22571838/gcc-4-8-1-stdto-string-error mingw something 4.8.1 still has the problem
03:28 bulk88 http://paste.scsys.co.uk/342209 RW blib, your 2nd close() git
03:28 bulk88 03.t now passes
03:31 Will_the_Chill checking
03:32 Will_the_Chill cool
03:32 Will_the_Chill so what's the deal w/ the libstdc++ thing?
03:32 Will_the_Chill gcc 4.8.1 is the culprit?
03:53 bulk88 the bug isnt a missing libstdc, a missing .a will never create a C/++ syntax error
03:54 bulk88 the problem is Citrus GCC (the one included with Strawberry perl), http://sourceforge.net/projects/perlmingw/files/Compiler%20for%2032%20bit%20Windows/ is old
03:56 mirjam joined #perl11
04:11 rurban joined #perl11
04:28 Will_the_Chill checking
04:29 Will_the_Chill okay I see
04:29 Will_the_Chill how to fix?
04:58 bulk88 dont use std::to_string or write your own, unofficial hacks involve changing the compiler http://tehsausage.com/mingw-to-string
04:58 bulk88 im not sure how to get a 4.8.1 mingw, ill investigate it
04:59 bulk88 also Citrus is a different build than Mingw.org and Mingw64
04:59 bulk88 so IDK how much hell I will unleash by using Mingw64 with Strawberry
04:59 Will_the_Chill huh, weird
05:00 Will_the_Chill McFist: do you know about this stuff?
05:00 bulk88 the problem is, GCC doesn't support Win32, and they do not take Win32 code
05:00 bulk88 Mingw.org forked GCC and does not participate with GNU
05:01 bulk88 Mingw64 participates with GNU, but they release multiple builds with different ABIs, threads, and exeception handling
05:02 bulk88 Cygwin has their own forked pool of Win32 code and participates with GNU, but Mingw64 and Cygwin dont share code
05:02 bulk88 IDK about cygwin tho, since it wouldnt work with Strawberry Perl
05:02 bulk88 *IDC
05:03 bulk88 Citrus/Strawberry used Mingw.org at one time, then switch to Mingw64 since .org's management was backwards
05:03 Will_the_Chill huh, complicated!
05:03 Will_the_Chill but interesting
05:03 bulk88 ActivePerl distributes their own GCC made from Mingw.org's code
05:04 bulk88 ActivePerl usually is compiled with Visual C, but installs GCC from AS's CPAN repo, that gcc tarball has a mingw.org gcc in it
05:05 Will_the_Chill okay
05:05 bulk88 in ActivePerl 5.18 AS switches to a GCC Perl, no more Visual C, but IDK if they are still using an old Mingw.org or Mingw64 now
05:06 Will_the_Chill sounds like a mess
05:08 bulk88 it is a mess, offering machine code incompatible C++ exceptions, gdb symbols, and threads is criminal, so 2 different tarballs from Mingw64, that use 2 different C++ exception systems under the hood, link object code from 2 different tarballs, crash at runtime
05:08 bulk88 mingw.org and mingw64 linking C++ code together is also risky
05:08 bulk88 gdb segvs last time I tried
05:09 Will_the_Chill whose fault is it?
05:09 bulk88 I'm not debugging gdb, its not worth me researching since they will just categorically reject tickets saying we dont support other side of the fence
05:12 bulk88 my opinion is all the projects refuse to "clone" Visual C's behaviors out of "its not free" or "F MS" or "we dont support the enemy" or "we dont want to get sued"
05:13 bulk88 MS has never tried to sue any GCC project or any non-MS Win32 compiler saying "the license does not allow you to create binaries for our proprietary OS"
05:14 Will_the_Chill well all I care about is compiling Perl
05:14 Will_the_Chill we can't afford to get embroiled in that political quagmire
05:16 bulk88 ill try a newer mingw64 and see if I can get it run without loosing my hair
05:16 Will_the_Chill okay I'm here to help
05:17 Will_the_Chill if Dmitry (McFist) shows up he might be able to help, I think he uses both Windows and Linux
05:19 rurban joined #perl11
05:32 mirjam joined #perl11
06:26 bulk88 ld.exe crashed on me
06:28 bulk88 c:\sources\mingw64\i686-w64-mingw32\bin\ld.exe , cmd line ""c:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld.exe" "--sysroot=C:/Temp/msys64/tmp/i686-482-win32-sjlj-rt_v3-r0/mingw32" "-m" "i386pe" "--dll" "-Bdynamic" "-e" "_DllMainCRTStartup@12" "--enable-auto-image-base" "-o" "blib\arch\auto\eval_157_1128\eval_157_1128.dll" "-s" "c:/sources/mingw64/
06:28 bulk88 bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o" "c:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/crtbegin.o" "-LC:\sp3216\perl\lib\CORE" "-LC:\sp3216\c\lib" "-Lc:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2" "-Lc:/sources/mingw64/bin/../lib/gcc" "-Lc:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/
06:28 bulk88 lib/../lib" "-Lc:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../lib" "-Lc:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib" "-Lc:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../.." "--base-file" "dll.base" "eval_157_1128.o" "C:\sp3216\perl\lib\CORE\libperl516.a" "C:\sp3216\c\i686-w64-mingw32\lib\libmoldname.a" "C:\sp3216\
06:28 bulk88 c\i686-w64-mingw32\lib\libkernel32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libuser32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libgdi32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libwinspool.a" "C:\sp3216\c\i686-w64-mingw32\lib\libcomdlg32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libadvapi32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libshell32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libole32.a" "C:\sp3216\c\i686-w64-m
06:28 bulk88 ingw32\lib\liboleaut32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libnetapi32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libuuid.a" "C:\sp3216\c\i686-w64-mingw32\lib\libws2_32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libmpr.a" "C:\sp3216\c\i686-w64-mingw32\lib\libwinmm.a" "C:\sp3216\c\i686-w64-mingw32\lib\libversion.a" "C:\sp3216\c\i686-w64-mingw32\lib\libodbc32.a" "C:\sp3216\c\i686-w64-mingw32\lib\libodbccp32.a"
06:28 bulk88 "C:\sp3216\c\i686-w64-mingw32\lib\libcomctl32.a" "dll.exp" "-lstdc++" "-lmingw32" "-lgcc_s" "-lgcc" "-lmoldname" "-lmingwex" "-lmsvcrt" "-ladvapi32" "-lshell32" "-luser32" "-lkernel32" "-liconv" "-lmingw32" "-lgcc_s" "-lgcc" "-lmoldname" "-lmingwex" "-lmsvcrt" "c:/sources/mingw64/bin/../lib/gcc/i686-w64-mingw32/4.8.2/crtend.o""
06:28 Will_the_Chill I don't see anything here that I can go off of
06:28 bulk88 and its picking up libs/.as from the from dirs...
06:29 bulk88 which are .a files from the 4.6.3 Citrus GCC that came with strawberrt
06:30 bulk88 .a files dont even contain machine code, just DLL import info, yet 2 different Mingw64 GCC builds can't link each others .o/.a files
06:34 bulk88 http://tinypic.com/view.php?pic=e62lja&amp;s=8
06:44 Will_the_Chill wow
06:44 Will_the_Chill that sucks
06:45 Will_the_Chill McFist: are you there?
06:46 bulk88 a part of the problem above is perl/EUMM
06:46 Will_the_Chill oh?
06:46 Will_the_Chill *going to eat*
06:46 rurban joined #perl11
06:47 bulk88 when you pass -l to EUMM, depending on which param to WriteMakefile you put it in, it will abs path every lib on the command line, no -L no -lsomelibrary anymore
06:49 Will_the_Chill hmm.  if we need to fix or change EUMM I'm willing to do it
06:49 Will_the_Chill we already had to fix Inline::Filters
06:50 bulk88 http://paste.scsys.co.uk/342340 how do I kill the LIBS param ina  Inline build dir?
06:50 bulk88 where in RPerl is it
06:51 Will_the_Chill just a min
06:52 Will_the_Chill I guess you could overwrite it the same place as the rest, in lib/RPerl/Inline.pm
06:52 Will_the_Chill we are not currently setting LIBS but you could add it
06:53 Will_the_Chill okay really going to eat!  :)
06:55 bulk88 there is no LIBS setting in Inline.pm, or in any git tracked code grrrr
07:02 bulk88 https://metacpan.org/source/DAVIDO/Inline-CPP-0.49/lib/Inline/CPP/Config.pm#L15
07:02 bulk88 ill be back later
07:47 rurban joined #perl11
07:50 Will_the_Chill bulk88: ah yes, I've seen Inline/CPP/Config.pm before, I forgot libstdc++ was in there!
07:51 bulk88 LIBS => '',  in RPerl/Inline.pm has no effect
07:52 bulk88 probably because Inline CPP for LIBS is catted not replaced
07:52 bulk88 according to its docs
07:52 Will_the_Chill okay
07:53 Will_the_Chill so try hard-coding it in Inline/CPP/Config.pm just to see if it works?
07:53 Will_the_Chill we can have Reini help us modify Inline stuff if we can figure out what needs to be done
07:53 Will_the_Chill or Ingy
07:53 Will_the_Chill either of them
07:54 bulk88 im hacking it on my side
07:54 bulk88 the -stdc probably should be there
07:55 bulk88 the problem it causes the lib abs path behavior
07:55 bulk88 which is a problem specific to my system (trying to use a different GCC with Strawberry Perl than it was built with)
07:57 Will_the_Chill oh, okay, I see
07:57 Will_the_Chill gotcha
08:00 bulk88 OT: trains try to go up stairs in Chicago  https://pbs.twimg.com/media/BjncaMkCEAATXfV.jpg:large
08:00 rurban joined #perl11
08:02 bulk88 this is getting stupid
08:02 bulk88 from the makefile "#     LIBS => [q[ ]]"
08:02 bulk88 that will trigger EUMM's make all libs absolte paths mode
08:03 bulk88 I commented out #our $libs     = '-lstdc++'; in inline-cpp-config.pm
08:03 bulk88 that is a space, and not empty string tho
08:06 bulk88 https://metacpan.org/diff/file?target=DAVIDO/Inline-CPP-0.49/&amp;source=DAVIDO/Inline-CPP-0.46/ see "-our $LOGFILE = q{c:/Users/daoswald/programming/repos/Inline-CPP/ilcpp.log};" lol
08:07 Will_the_Chill haha okay
08:07 bulk88 i think ill upgrade my inline CPP since I have 0.46 and 0.49 is the latest and doesn't have that comical path in it
08:07 Will_the_Chill good idea!
08:07 bulk88 there aren't many changes as you see from the diff but atleast I wont have that darn path in my disk
08:08 bulk88 *on
08:08 Will_the_Chill yeah I have 0.49
08:09 Will_the_Chill the trains-up-stairs thing is wild, I saw it a few days ago, scary!  okay, time for another early night for me, gotta do stuff in the morning, will log back in tomorrow!
09:01 rurban joined #perl11
09:05 basiliscos joined #perl11
10:02 rurban joined #perl11
11:02 rurban joined #perl11
12:03 rurban joined #perl11
12:45 rurban joined #perl11
15:33 mirjam joined #perl11
17:53 mirjam joined #perl11
21:47 Will_the_Chill joined #perl11
22:06 rurban joined #perl11
22:50 bulk88 libstdc++-6.dll is GCC compiler specific, yet the folks at Mingw broke ABI in 4.7.0, so no C++ dlls compiled with < 4.7.0 will ever work with GCC >= 4.7.0
22:51 bulk88 http://tinypic.com/r/vq5m43/8 airplane nonprint crashed when calling std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*)
22:51 bulk88 also known as _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E
22:57 Will_the_Chill dang!
22:57 Will_the_Chill McFist: we need you
22:58 bulk88 http://i59.tinypic.com/mrz9y0.png see, this is a much better warning than a segv
22:59 bulk88 http://stackoverflow.com/questions/13100324/upgrade-to-g-4-7-with-c11-support-any-abi-incompatibility
22:59 bulk88 if you read through all the noise, they changed C++ member functions from cdecl to thiscall
22:59 bulk88 they didn't change the symbol names tho
22:59 bulk88 or the dll name
23:02 bulk88 http://mingw-users.1079350.n2.nabble.com/Conflicting-libstdc-6-dll-requirements-and-licensing-tp6160814p6169131.html
23:03 bulk88 Im not having that problem, I dont think I am since perl doesn't use libstdc
23:06 bulk88 http://tehsausage.com/clang-mingw-gcc-4-7
23:08 bulk88 https://github.com/mozilla/rust/issues/5712
23:08 rurban joined #perl11
23:08 Will_the_Chill over my head
23:18 bulk88 long story short, you need to version your apis and dlls/sos when you change the machine code interface of everything, not leave it to segv
23:19 bulk88 libstdc++-6.dll has a name, its called 6, they shouldve bumped it to 7 when they changed GCC to thiscall, but they didn't
23:29 Will_the_Chill okay so how do we fix it for RPerl?  :)
23:32 bulk88 i have to try replacing DLLs, ill try it later today
23:32 Will_the_Chill cool beans

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary