- User Since
- Jul 10 2014, 12:13 PM (214 w, 4 d)
Wed, Jul 25
Jul 20 2017
Code looks good, but is not working well on OpenBSD 6.1-current which provides GNU tar 1.29:
"rm" -f bindistprep/ghc-8.3.20170720-x86_64-unknown-openbsd.tar cd bindistprep && "/usr/local/bin/gtar" --posix hcf - -T ../bindist-list | /usr/local/bin/xz -c > ../bindistprep/ghc-8.3.20170720-x86_64-unknown-openbsd.tar.xz /usr/local/bin/gtar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options Try '/usr/local/bin/gtar --help' or '/usr/local/bin/gtar --usage' for more information. mv bindistprep/*.tar.xz . $ $ gtar --version tar (GNU tar) 1.29 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Oct 18 2016
Oct 17 2016
Yes, probably yes. Honestly speaking I've googled for equivalent option and its need and found this: http://stackoverflow.com/questions/596076/solaris-linker-equivalent-to-the-gnu-ld-export-dynamic-flag -- I've also build on Solaris with the patch and run testsuite and there are no new errors judging form quick look. I've also compared nm iserv|wc -l on Solaris and Linux and found that 31511 and 31123 are pretty similar numbers. I've not investigated more, but if you know some iserv's symbol which you are interested in and which is exported as dynamic one on Linux, I would grep for it here on Solaris for verification. Thanks.
Oct 7 2016
Works on Solaris 11.2. Tested on i386 platform, but since this is hardware platform independent issue I would not expect any issue on amd64. Thanks for the patch! Karel
Aug 22 2016
Aug 15 2016
@simonmar Good catch! Working on that. I'm not sure I can update closed Dx, so I'll try to provide a new one.
Aug 14 2016
So if I may ask, I would go with this forward till the time we do have proper patch for W^X. Thanks!
replace tabs with spaces
I've changed the #ifdef a bit to test for specific GNU C version. Also I've reformatted code as per Eric's advice. I've tested on OpenBSD-current with its GNU C 4.2.1 and verified I get to abort() code branch and on Solaris 11 with GNU C 4.8.2 and verified that I get to __builtin_unreachable code branch so #ifdef machinery should be ok. Thanks for review and comments.
Do not use openbsd_HOST_OS #ifdef but rather test for specific GNU C version
Aug 13 2016
@erikd will do tomorrow in the evening (CEST). Thanks for the comment.
@erikd of course let's wait for @kili 's patch(es). I'm not sure, but I think he is working on OpenBSD's GHC 7.10.x base so either he or I'll attempt to forward port his patch(es) to HEAD and provide better solution. Anyway, let's keep this open for few next days and see what kili/me can bring... After all, this is really just workaround to get things running better on OpenBSD-current...
Mar 29 2016
update code comment: listing standards and related trac ticket
@hvr agree with you on consistency C99 versus POSIX/XOPEN. Let me test following diff
diff --git a/rts/PosixSource.h b/rts/PosixSource.h index 6246e3e..8246fda 100644 --- a/rts/PosixSource.h +++ b/rts/PosixSource.h @@ -11,25 +11,13 @@
@hvr uff, sorry about commit, I've noted your changed of mind too late.
@hvr it's not IMHO the question about what macros are not implemented on Solaris but the question about Solaris strickness. It simply claims
346 /* 347 * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application 348 * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, 349 * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 350 * or a POSIX.1-2001 application with anything other than a c99 or later 351 * compiler. Therefore, we force an error in both cases. 352 */ 353 #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) 354 #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ 355 and pre-2001 POSIX applications" 356 #elif !defined(_STDC_C99) && \ 357 (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) 358 #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \ 359 require the use of c99" 360 #endif
and the error on line 354 is what I hit here. By defining _XOPEN_SOURCE to 600 this is corrected. Apparently Linux is not that strict and allows you to compile non XPG6 code with C99 compiler. Basically if you look here: https://github.com/joyent/illumos-joyent/blob/master/usr/src/uts/common/sys/feature_tests.h -- this is nearly the same like Solaris 11's own file except that Illumos modernize it to also support XPG7. Anyway, the logic of test above is still the same.
Mar 28 2016
Feb 23 2016
Jan 15 2016
@thomie Hold on, gmake 3.80 is distributed with Solaris 10 up to these days IIRC and even there is nearly zero chance someone will update their GHC to 8.x on this system, still if the warning hurts nobody I would rather keep it there.
@bgamari failed on ghc-stage1 running out of memory. Can't see how this may be related to the proposed change...
Jan 14 2016
@bgamari you are right about it so I removed that.
do not set make command in mk/config.mk.in (not necessary for shake)
Jan 13 2016
Jan 12 2016
Dec 23 2015
- fix compilation issue of previous long line fix
- fix long line issue
@hvr: I don't know what's exactly culprit. The error looks like:
Compile failed (status 256) errors were: ghc-stage2: /usr/lib/libpthread.a: unknown symbol `_DYNAMIC' ghc-stage2: unable to load package `unix-22.214.171.124'
Dec 22 2015
Nov 19 2015
@hvr: arc upgrade solved the issue. I've tested D on OpenBSD/AMD64 and Solaris/AMD64 and builds fine including bindisttest hello world.
Created and checked out branch arcpatch-D1500. Exception You may not set new credentials after authenticating conduit. (Run with `--trace` for a full exception trace.) 49
well just in case you are curious if this runs on Solaris/OpenBSD, can't help you till this is solved. Any idea?
Tested on OpenBSD/AMD64 and Solaris/i386. Builds fine.
Nov 16 2015
I've compiled HEAD + this Dx on Solaris/AMD64 and OpenBSD/AMD64. I'm not lucky with Solaris/i386 which fails with
"/opt/ghc-7.10.1-i386/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -this-package-key ghc-7.11 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0-29bb26a0797af39b979b99b93e9d62fd -package-id base-126.96.36.199-82f21b46ed153fd6b19071a60f2e7937 -package-id binary-0.7.5.0 -package-id bytestring-0.10.6.0-79779027caa792766a3e8dc3e9cb98de -package-id containers-0.5.6.2-90712e174b339b5587c1656969878fb0 -package-id directory-188.8.131.52-73de5f636b1ca4c49aef15924617292c -package-id filepath-184.108.40.206-129f3fdd2b5de4f823a2641d7cf29327 -package-id ghc-boot-0.0.0.0 -package-id hoopl-220.127.116.11 -package-id hpc-0.6.0.2 -package-id process-18.104.22.168-77cd256a28bb4c7cc8cecb076a8fbc37 -package-id template-haskell-22.214.171.124 -package-id time-126.96.36.199-f5db9cf4a7dcb8716611e730437a1fd6 -package-id transformers-0.4.3.0 -package-id unix-188.8.131.52-57629c7ceba7cbcf210cc85471e45e07 -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing -fwarn-tabs -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Outputable.hs -o compiler/stage1/build/Outputable.o
Nov 12 2015
I've tested advised:
echo $((2*1000 + 16*10 + 0))
and on both Solaris and OpenBSD I got the expected 2160. So this works well...
Nov 11 2015
Ben, I truly admire Erik's work on Linker. I also feel kind of guilty to kind of reverse its direction with this patch. On the other hand I tried to have that as simple as possible for Erik to exactly see where the culprit is. BTW: the issue is not only in SHN_INDEX being undefined but also in SHT_SYMTAB_SHNDX which is neither defined. In the current patch version this is hidden by SHN_INDEX #ifdef so fixed. Anyway, I still think there is a possibility to refactor this cleanly, but IMHO it's better when one man does this. There is too much code going into Linker.c these days and too much breakage slipping from it so no need to make things even more complex by stepping on Erik's foots with any attempt to cleverly refactor this into a clean code...
Anyway, if I understand this right, Erik does have final word here and even if you accept this code he still need to either ok this or require change(s). Erik, this is up to you now. Thanks for the review!
Nov 10 2015
@thomie: silly me! I've kept in head a need to verify that this test passes on builder, but then submitted too quickly. :-) Of course since it already fails this is no regression so for my platforms this D looks fine.
@thomie: Solaris/i386 runs fine. Solaris/amd64 fails with:
=====> recomp011(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory recomp011 </dev/null > recomp011.run.stdout 2> recomp011.run.stderr Actual stdout output differs from expected: Warning: missing newline at end of file ./recomp011.stdout.normalised Warning: missing newline at end of file ./recomp011.run.stdout.normalised --- ./recomp011.stdout.normalised Tue Nov 10 10:25:19 2015 +++ ./recomp011.run.stdout.normalised Tue Nov 10 10:25:19 2015 @@ -1,10 +1,6 @@ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 42 -[1 of 1] Compiling Main ( Main.hs, Main.o ) [B.hsinc changed] -Linking Main ... -43 -[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] -Linking Main ... -4343 -4343 +42 +42 +42 *** unexpected failure for recomp011(normal)
Nov 7 2015
Nov 2 2015
Nov 1 2015
@bgamari: Thanks for letting me know. Now, it's clear. :-)
@erikd: Any comment to your do-not-approve sign? I would really appreciate that. Thanks! Karel
Oct 31 2015
Adding some comments to not confuse future code reader
Oct 22 2015
Someone adds me as reviewer to this, so I think I will just comment: honestly I do not like the way configuration is handled. I definitely think we should stay with what we have today with --with-<tool>=<tool path>. I see author does not agree with this but such is my feeling that it's better to use kind of common way, otherwise it will be inconvenient for GHC builders/advanced-users just to remember exactly this and this tool needs different way. Anyway, I still think that --with-<tool> also supports authors way of configuration: AR=gar NM=nm ./configure.... -- so I think this more universal...
Otherwise the patch looks OK, at least what I see in it...