Open saulery opened 5 years ago
hostilefork
commented
5 years ago "I don't really use your language"
("Pick pathological build environment")
"Your tests in the language I can't read or write had a message when I built it, I'm filing a bug"
Ok...well..thanks for the report? But if you want this to be anything other than "low priority", you have to explain what it blocks you're trying to accomplish.
saulery
commented
5 years ago Excuse me, I understand that I annoy you so. I intend to learn the language little by little. It turns out that I started by testing the builds because I wanted a binary for OpenBSD and since there were some compilation problems I wanted to work in this vein just to see if we can find any bugs. Really.
As I do not have a thorough knowledge of C/C++ compilers I did not know that mingw-x64-c ++ is to be considered pathological.
What do you consider a healthy C/C++ compiler (under windows)?
gchiu
commented
5 years ago If you're using windows 10 why don't you install Bash for Windows which is an Ubuntu distribution written for Windows? And install the Gnu tools
hostilefork
commented
5 years ago It's not your fault if there are bugs. And I purposefully put in a lot of checks that other people don't, so the builds are very "noisy" if something goes wrong. As you can see this is a bug pertaining to some accounting that's not balancing at shutdown time (usually you'd have to run under something like valgrind to know this, but the debug build has the ability to notice without that)
If these things are happening it's good to know.
But all that said...it feels like just adding a lot of extra work for me (installing OpenBSD, figuring out how cygwin works). So I have to understand what the point is. I'm sure you could build for any infinity of untested environments and we'd notice some issues, but you have to use it!
saulery
commented
5 years ago @gchiu : I use Windows 7.
@hostilfork : Your recommendation is to use a version compiled with "debug: asserts". From the moment I have my two targets (windows + openBSD) bootstrapped like that I go to the next step.
With which environment was compiled the version for Windows that is in the git repository (native build / cross compilation from Linux) ? If it is possible I align myself with what has been done and drop cygwin / mingw-x64.
hostilefork
commented
5 years ago No, I apologize. :-/ It's just I started in the morning fixing one thing on cygwin, where it fakes the drive paths and lies to the program about it (says /C/wherever, which then doesn't work in the filesystem). I have to learn that it doesn't install a compiler by default, I have to learn that you re-download the setup program to add components...if it's not one thing it's another--the hours add up!
If there are problems I will address them. Just promise me you're going to do some Rebol programming before you pick any more build platforms!!!
In any case: I can't reproduce this in a cygwin build, from the link you gave me. I tried the command line you posted:
$ ../prebuilt/r3-windows-x86-8994d23.exe ../make.r config: ../configs/mingw-x64-c++.r debug: asserts
But that complained about missing DLLs related to libstdc++ and pthreads that do not appear to be anywhere in the installation. So instead I asked it to make a makefile:
$ ../prebuilt/r3-windows-x86-8994d23.exe ../make.r config: ../configs/mingw-x64-c++.r debug: asserts target: makefile
Then I added -static to the link line in the makefile, and it worked.
But then, no problems with going to the test directory and running ../build/r3 run-recover.r. (outside of the test I know about that has an issue, and some complaints about whitespace which get tended to now and again). So if you're getting an assert we'll have to find out what you've done differently.
(If there's an easy test of explaining what you might have done differently from me, then let me know...but if not, you may have to uninstall cygwin and reinstall, documenting the steps and what versions of everything you are picking...so I can follow those steps to reproduce it.)
saulery
commented
5 years ago Yes, cygwin is... an odd beast. :-)
That's why I tried TCC, TDM-GCC, MSVC. TCC : fight with headers, only C TDM-GCC : build with "debug: none", maybe your last fix is fine for "debug: asserts" Old version of GCC, not what you want for good tests. MSVC: I don't know how to use configs: vs2017-x64.r (cmmand line or IDE ?). I have VS2015 and need to reinstall VS2017 (It's long, I delayed this target).
I uninstalled cygwin32 and cygwin34. Reinstalled cygwin64 only to avoid conflicts with headers and build tools Installed only mingw-x64 (not mingw-i686 otherwise two compilers are detected and the build is fooled), GCC (it's two separate packages), libs, headers, build tools, only in the last version of each package.
Missing DLL are missing packages you didn't installed.
I think I could extract a list of packages installed tonight
%/C/devel/ren-c-orig/tests/network/dns.test.reb
(did all [ tuple? address: read dns://rebol.com "rebol.com" = read join dns:// address ]) "failed, test returned #[false]"
%/C/devel/ren-c-orig/tests/network/http.test.reb
( ; !!! Note that returning a WORD! from a function ending in ? is not seen ; as a good practice, and will likely change. ; 'file = exists? http://www.rebol.com/index.html ) "succeeded" (binary? read http://example.com) "succeeded" (binary? read https://example.com) "failed, error w/no ID"
At least one leaked series at shutdown... C Source File ..\src\core\m-pools.c, Line 330, Pointer 0000000003a9e538 At evaluator tick: 136643800 unmanaged series was likely created during evaluator tick: 12675151 C Source File ..\src\core\m-series.c, Line 488, Pointer 00000000007be640 At evaluator tick: 136643800 Rebol Internal Error If you need to file a bug in the issue tracker, please give thorough details on how to reproduce the problem:
Include the following information in the report:
Executable not built with DEBUG_SERIES_ORIGINS, no more info