[Issue 15392] dmd object files fail to link with ld.gold
https://issues.dlang.org/show_bug.cgi?id=15392 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- The sections are not supposed to be order dependent. --
[Issue 15384] assignment is sometimes still accepted as a condition
https://issues.dlang.org/show_bug.cgi?id=15384 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- I assume that this has to do with the way in which the comma operator works. The compiler then sees it not as two assignments, but the output of the comma operator (which is just a value). Not sure how difficult it would be to get the compiler to track down into a comma operator, since you can do arbitrary work inside it. --
[Issue 15390] 'abstract' should override final:
https://issues.dlang.org/show_bug.cgi?id=15390 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- I don't know whether I agree with your statement "naturally, this is the first line in any D class", but I agree that final: and abstract: should override each other as public:, protected:, etc. do. I assume that you are currently working around this buy having all of your abstracts up the top before your final: line? --
[Issue 15392] New: dmd object files fail to link with ld.gold
https://issues.dlang.org/show_bug.cgi?id=15392 Issue ID: 15392 Summary: dmd object files fail to link with ld.gold Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Recent master versions of dmd trigger an ld.gold assertion. /usr/bin/ld: internal error in add_output_section_to_load, at output.cc:4093 Seems like it complains about input section having a different order than the mapping in the linker script. https://sourceware.org/git/?p=binutils.git;a=blob;f=gold/output.cc;hb=a0a1bb07cb2c03b7d34f12e734c6f363ddb7c7b2#l4135 Apparently caused by this PR. https://github.com/D-Programming-Language/dmd/pull/5264 In my linker script .eh_frame follows .rodata but precedes .tdata. --
[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #5 from Martin Nowak ---
(In reply to Thomas Mader from comment #3)
> I was able to hack around the issue by patching the curl.d sourcefile.
>
> #Ugly hack so the dlopen call has a chance to succeed.
> substituteInPlace src/phobos/std/net/curl.d --replace libcurl.so
> ${curl}/lib/libcurl.so
>
>
> That's in the package description for the dmd package on NixOS. That's
> necessary because in NixOS every package is stored in isolation to
> everything else.
> So libcurl on my system resides in
> /nix/store/v5a69m1b823zm1yy8yvhrd2zi2w385b1-curl-7.44.0/lib/libcurl.so.
Maybe try to LD_LIBRARY_PATH instead?
As mentioned here https://dlang.org/changelog/2.069.0.html#curl-dynamic-loading
you can also link against libcurl (make sure to use no-as-needed), then the
symbols will get loaded from your executable.
--
[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #4 from Jonathan M Davis --- What are you doing differently from normal that makes it so that the normal path for the time zone files doesn't work? --
[Issue 15172] ICE(interpret.c ctfeCompile) Assertion `!fd->semantic3Errors' failed.
https://issues.dlang.org/show_bug.cgi?id=15172 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15172] ICE(interpret.c ctfeCompile) Assertion `!fd->semantic3Errors' failed.
https://issues.dlang.org/show_bug.cgi?id=15172 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0ff99ff004c49a370f2a014dbcd1cec0cf053f63 fix Issue 15172 - ICE(interpret.c ctfeCompile) Assertion `!fd->semantic3Errors' failed. https://github.com/D-Programming-Language/dmd/commit/d2880137c7a25e6cd167a713cdcec71b7910cb6f Merge pull request #5168 from 9rnsr/fix15172 Issue 15172 - ICE(interpret.c ctfeCompile) Assertion `!fd->semantic3Errors' failed. --
[Issue 15378] dlang.org does not completely work with https:
https://issues.dlang.org/show_bug.cgi?id=15378 --- Comment #3 from David Nadlinger --- (In reply to Adam D. Ruppe from comment #2) > The whole url bar showing as green is kinda rare, that signifies the > extended validation thing. My bank does it but no other site I go to does. I'm not talking about extended validation; just about Chrome even showing a lock symbol (which happens to be green, and also causes the https schema part of the URL to be rendered green). For example, https://www.rust-lang.org/ and https://golang.org/ show up as "secure" in this way on Chrome/OS X, while https://dlang.org does not. --
[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391
--- Comment #3 from Thomas Mader ---
I was able to hack around the issue by patching the curl.d sourcefile.
#Ugly hack so the dlopen call has a chance to succeed.
substituteInPlace src/phobos/std/net/curl.d --replace libcurl.so
${curl}/lib/libcurl.so
That's in the package description for the dmd package on NixOS. That's
necessary because in NixOS every package is stored in isolation to everything
else.
So libcurl on my system resides in
/nix/store/v5a69m1b823zm1yy8yvhrd2zi2w385b1-curl-7.44.0/lib/libcurl.so.
This also makes problems in the unittest of datetime.d. The path to the
zoneinfo is hardcoded so I needed to hack around it in a similar fashion.
#Ugly hack to fix the hardcoded path to zoneinfo in the source file.
substituteInPlace src/phobos/std/datetime.d --replace
/usr/share/zoneinfo/ ${tzdata}/share/zoneinfo/
I think it should be possible to specify those paths somehow via the Makefile
to get a clean build.
--
[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391 Thomas Mader changed: What|Removed |Added Summary|Deadlock in std.net.curl|Problems loading libcurl.so |unittest in checkPhase of |and running datetime |NixOS package build |unittest on NixOS package ||build --
[Issue 15378] dlang.org does not completely work with https:
https://issues.dlang.org/show_bug.cgi?id=15378 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #2 from Adam D. Ruppe --- The whole url bar showing as green is kinda rare, that signifies the extended validation thing. My bank does it but no other site I go to does. --
[Issue 15391] Deadlock in std.net.curl unittest in checkPhase of NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391 --- Comment #2 from Thomas Mader --- Running the testsuite in the shell instead of inside the package creation process gives me an Exception and the process deadlocks in the same place. So the libcurl dependency cannot be resolved. ** FAIL debug64 std.net.curl std.net.curl.CurlException@std/net/curl.d(3885): Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3". --
[Issue 15391] Deadlock in std.net.curl unittest in checkPhase of NixOS package build
https://issues.dlang.org/show_bug.cgi?id=15391 Thomas Mader changed: What|Removed |Added Summary|Deadlock in std.net.curl|Deadlock in std.net.curl |unittest|unittest in checkPhase of ||NixOS package build --
[Issue 15391] Deadlock in std.net.curl unittest
https://issues.dlang.org/show_bug.cgi?id=15391 --- Comment #1 from Thomas Mader --- I need to add that I try to run the unittests in the checkPhase of a package build of NixOS and the network is restricted in this case I guess. But the tests for std.socket were successful: 0.518s PASS debug64 std.socket --
[Issue 15391] New: Deadlock in std.net.curl unittest
https://issues.dlang.org/show_bug.cgi?id=15391 Issue ID: 15391 Summary: Deadlock in std.net.curl unittest Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: thomas.ma...@gmail.com I tried to run the unittests of phobos 2.069.1 but got the following deadlock in test_runner while running the std.net.curl unittest: (gdb) thread apply all bt Thread 2 (Thread 0x71ce5700 (LWP 19261)): #0 0x727a47dd in accept () from target:/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0 #1 0x7624eae4 in std.socket.Socket.accept() (this=0x77ef1700) at std/socket.d:2855 #2 0x76f7fb8a in std.net.curl.TestServer.loop(shared(std.socket.TcpSocket)) ( listener=0x77ef1700) at std/net/curl.d:213 #3 0x76fad46d in std.concurrency._spawn!(void(shared(std.socket.TcpSocket)) function*, shared(std.socket.TcpSocket))._spawn(bool, void(shared(std.socket.TcpSocket)) function*, shared(std.socket.TcpSocket)).exec() (this=0x77ef2100) at std/concurrency.d:517 #4 0x775c903f in core.thread.Thread.run() (this=0x77eee500) at src/core/thread.d:1351 #5 0x775c7f6c in thread_entryPoint (arg=0x60d850) at src/core/thread.d:347 #6 0x7279d484 in start_thread () from target:/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0 #7 0x71dcd05d in clone () from target:/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libc.so.6 Thread 1 (Thread 0x77ff25c0 (LWP 19260)): #0 0x7279e65d in pthread_join () from target:/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0 #1 0x775c85b5 in core.thread.Thread.join(bool) (this=0x77eee500, rethrow=true) at src/core/thread.d:741 #2 0x775c9b7f in thread_joinAll () at src/core/thread.d:2283 #3 0x775eed0b in rt_term () at src/rt/dmain2.d:207 #4 0x775ef240 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function*).runAll() (this=0x7fffd990) at src/rt/dmain2.d:476 #5 0x775ef1c1 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function*).tryExec(scope void() delegate) (this=0x7fffd990, dg=...) at src/rt/dmain2.d:447 #6 0x775ef12b in _d_run_main (argc=2, argv=0x7fffda98, mainFunc=0x4017b0 ) at src/rt/dmain2.d:480 #7 0x00401988 in main () #8 0x71d06995 in __libc_start_main () from target:/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libc.so.6 #9 0x004012e9 in _start () --
