phobos build issue with dmd-2.102.2
Hello all,
I have an older system I am trying to build dmd-2.102.2 on from source:
stock Slackware 14.0 x86_64
binutils 2.22.52.0.2, gcc 4.7.1, glibc 2.15, kernel 3.2.x, and
dmd-2.102.1 installed (which I built from source on this system)
I started with dmd-2.067.1, bootstrapped it with only a C++ compiler,
mainly to see if it could done. It built no problem. I then used
the dmd just built to build newer versions. This worked fine up
through dmd-2.102.1.
I have a script that builds dmd, druntime, phobos, and some D tools,
in that order. I patterned it after instructions in the wiki:
[https://wiki.dlang.org/Building_under_Posix] using the
"make -f posix.mak" build commands for all steps.
Attempting to build dmd-2.102.2, it builds dmd and druntime OK,
but fails building phobos in unittest code, specifically in
phobos-2.102.2/std/math/exponential.d.
...(I removed duplicate 'Error' lines)...
std/math/exponential.d(3782): Error: number `0x0.8p-126f` is not
representable as a `float`
std/math/exponential.d(3784): Error: number `0x0.56p-126f` is not
representable as a `float`
std/math/exponential.d(3795): Error: number `0x0.8p-1022` is not
representable as a `double`
std/math/exponential.d(3797): Error: number `0x0.5p-1022` is
not representable as a `double`
make: *** [generated/linux/release/64/libphobos2.a] Error 1
It appears related to this commit:
https://github.com/dlang/phobos/commit/a76836b5a66f2e6f89026f48b0a53100d4b65a75
I ran the same build script for dmd-2.102.2 on another system and
everything built OK:
Slackware 14.1 x86_64 heavily modified
binutils 2.25.1, gcc 4.9.4, glibc 2.17, kernel 3.16.x, and
dmd-2.102.1 installed (also built from source)
I was thinking this might be a glibc or binutils issue since
versions are different between the two systems. I ran the
following tests on both systems:
```c
/* C99: testfloat.c */
/* compile: gcc -std=c99 testfloat.c */
#include
int main()
{
float f = 0x0.8p-126f;
printf("f: %0lg\n", f);
return 0;
}
```
The C program is compiled with the system's C compiler.
It prints the same output on both systems:
$ gcc -std=c99 testfloat.c; ./a.out
f: 5.87747e-39
Then I tried the D version, using the existing dmd-2.102.1:
```d
// testfloat.d
import std.stdio;
int main()
{
float f = 0x0.8p-126f;
writeln("f: ", f);
return 0;
}
```
Slackware 14.1 host prints, same as the C version:
f: 5.87747e-39
Slackware 14.0 host returns an error:
$ rdmd testfloat.d
testfloat.d(5): Error: number `0x0.8p-126f` is not representable as a
`float`
testfloat.d(5):https://dlang.org/spec/lex.html#floatliteral
Failed: ["/usr/bin/dmd", "-v", "-o-", "testfloat.d", "-I."]
Comparing the build logs the only difference I found was in the
phobos build. Slackware 14.1 has extra options, that I did not add.
I'm not sure where these are coming from:
-shared -defaultlib= -debuglib= -L-lpthread -L-lm
../dmd/generated/linux/release/64/dmd -conf= -I../dmd/druntime/import
-w -de -preview=dip1000 -preview=dtorfields -preview=fieldwise -m64
-fPIC -O -release -shared -defaultlib= -debuglib= -L-lpthread -L-lm
-ofgenerated/linux/release/64/libphobos2.so.0.102.2
-L-soname=libphobos2.so.0.102
../dmd/druntime/../generated/linux/release/64/libdruntime.so.a -L-ldl
std/array.d std/ascii.d ...massive line
trimmed...
The Slackware 14.0 only has -lib, none of the other options.
The rest of this huge line is the same.
../dmd/generated/linux/release/64/dmd -conf= -I../dmd/druntime/import
-w -de -preview=dip1000 -preview=dtorfields -preview=fieldwise -m64
-fPIC -O -release -lib -ofgenerated/linux/release/64/libphobos2.a
../dmd/druntime/../generated/linux/release/64/libdruntime.a std/array.d
std/ascii.d ...massive line trimmed...
This is mainly an academic exercise, but I would like to understand
why the phobos build fails on the older system.
thanks,
scot
Re: dub.sdl bindbc-glfw is returning a deprecation warming. So what do I do now?
On Thursday, 9 March 2023 at 00:21:02 UTC, WhatMeWorry wrote: my small dub.sdl project uses: dependency "bindbc-glfw" version="~>1.0.1" versions "GLFW_33" and returns Building bindbc-glfw 1.0.1: building configuration [dynamic] C:\Users\Admin\AppData\Local\dub\packages\bindbc-glfw-1.0.1\bindbc-glfw\source\bindbc\glfw\binddynamic.d(557,11): Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated So now what? I'm pretty sure deprecation means to replace with something better but what would that be? I looked on github code in binddynamic.d at line 557 and the package info at the DUB web site and I'm still clueless. Sorry about that. Try updating to bindbc-glfw 1.0.2, should be fixed now. If you see any other deprecation warnings from BindBC bindings you can silence them with `-d` until they're updated.
Re: help: Unresolvable dependencies to package openssl
On 3/8/23 7:52 PM, mw wrote:
Hi,
In my dub.json, I have:
```
"dependencies": {
"apache-thrift": "==0.16.0",
...
}
"subConfigurations": {
"apache-thrift": "use_openssl_1_1",
"pyd": "python39"
},
```
But:
$ dub build
Unresolvable dependencies to package openssl:
apache-thrift 0.16.0 depends on openssl ~>2.0.3
apache-thrift 0.16.0 depends on openssl ~>1.1.6
app ~master depends on openssl ~>2.0.3
Why the subConfigurations: "use_openssl_1_1":
https://github.com/apache/thrift/blob/master/dub.json#L26
{
"name": "use_openssl_1_1",
"versions": ["use_openssl_1_1_x"],
"dependencies": {
"openssl": {
"version": "~>2.0.3"
}
}
}
did not pick up the 2.0.3? but report conflict instead?
Thanks.
This is a known limitation -- dub builds the selections file based on
*all* configurations in the file. If you have conflicting ones, it will
not know what to pick.
However, if you manually construct the selections file, then it will work.
See https://github.com/dlang/dub/issues/1217
-Steve
help: Unresolvable dependencies to package openssl
Hi,
In my dub.json, I have:
```
"dependencies": {
"apache-thrift": "==0.16.0",
...
}
"subConfigurations": {
"apache-thrift": "use_openssl_1_1",
"pyd": "python39"
},
```
But:
$ dub build
Unresolvable dependencies to package openssl:
apache-thrift 0.16.0 depends on openssl ~>2.0.3
apache-thrift 0.16.0 depends on openssl ~>1.1.6
app ~master depends on openssl ~>2.0.3
Why the subConfigurations: "use_openssl_1_1":
https://github.com/apache/thrift/blob/master/dub.json#L26
{
"name": "use_openssl_1_1",
"versions": ["use_openssl_1_1_x"],
"dependencies": {
"openssl": {
"version": "~>2.0.3"
}
}
}
did not pick up the 2.0.3? but report conflict instead?
Thanks.
Re: dub.sdl bindbc-glfw is returning a deprecation warming. So what do I do now?
On 3/8/23 7:21 PM, WhatMeWorry wrote: my small dub.sdl project uses: dependency "bindbc-glfw" version="~>1.0.1" versions "GLFW_33" and returns Building bindbc-glfw 1.0.1: building configuration [dynamic] C:\Users\Admin\AppData\Local\dub\packages\bindbc-glfw-1.0.1\bindbc-glfw\source\bindbc\glfw\binddynamic.d(557,11): Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated So now what? I'm pretty sure deprecation means to replace with something better but what would that be? I looked on github code in binddynamic.d at line 557 and the package info at the DUB web site and I'm still clueless. It's newly deprecated, without much explanation: https://github.com/BindBC/bindbc-loader/commit/d13d7f246f325472b26282cfac8d2b02b26eccac Last commit to bindbc-glfw is from last year, so it makes sense why it is triggering this. I feel it was in error to deprecate symbols without bumping the major revision. -Steve
dub.sdl bindbc-glfw is returning a deprecation warming. So what do I do now?
my small dub.sdl project uses: dependency "bindbc-glfw" version="~>1.0.1" versions "GLFW_33" and returns Building bindbc-glfw 1.0.1: building configuration [dynamic] C:\Users\Admin\AppData\Local\dub\packages\bindbc-glfw-1.0.1\bindbc-glfw\source\bindbc\glfw\binddynamic.d(557,11): Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated So now what? I'm pretty sure deprecation means to replace with something better but what would that be? I looked on github code in binddynamic.d at line 557 and the package info at the DUB web site and I'm still clueless.
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Well, bounds check often cost a few percent, and you can disable it or use .ptr @safe will push you to use slices instead of raw pointers, and those can occupy the stack a bit more, but it's not a huge effect. Lack of dangerous "fast math" "optimizations" is a real boon for correctness. We don't have integers overflows, those would also cost a few percent. Your D programs by being easy to modify will have very few performance bottlenecks that are problematic, often the CPU-bound or memory-bound stuff that would be slow in any language. For example I like to merge array allocations, this necessitates the same code in C, C++, or any native language. I think it's important not to go overboard with lazy chains and templates though. Honestly the increased productivity will leave you ample time to make things fast, and you can use the native profilers, for example Intel Vtune. This year I released a free VST compressor named Lens, it does more than the closest manybands competitor while being in the ballpark CPU-wise, and they are using ICC AVX2 which does dynamic instruction set dispatch, while we use SSSE3. Optimization is all about having the time to do it.
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: So, having no clue about D (just bought some books), I wanted to ask if nice looking code can become slow, in general. In the mentioned case it's just that I like the packaging of functions into some sort of scope (OOP) versus the flat C and Go stuff. I like OOP for this reason, but now I'm unsure whether I might stay out of creating classes at all. Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Kind regards If you write D like Java, it will be slow like Java - actually slower, because D's GC isn't as good. If you remember to use structs for value types (no `class Vector3f`, `class Point` etc.), you should be fine. Though as a general rule, don't worry about it too much. Even slow D is still fast.
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe. [...] Don't bother with it. This kind of optimization is done when compiling with -O, and I really doubt about your bottleneck being that you're calling a virtual call. Wait when you actually need to optimize before making your code ugly.
Re: How to build a static lib properly?
On Monday, 6 March 2023 at 05:59:09 UTC, Mike Parker wrote: On Monday, 6 March 2023 at 02:09:23 UTC, ryuukk_ wrote: dub should build a static library for the project i build, that includes each library it uses that are referenced as "library" since the default is "staticLibrary" according to rikki What you're asking for is a different use case. `staticLibrary` is for compiling a specific dub package as a static library. It does not imply that all of that package's dependencies should also be compiled into a single static library. Nor should it. You're asking for a package and its dependencies to be bundled for use outside of the dub ecosystem as a single static library. I won't say it's not a legitimate use case, it's just not one that dub currently supports, nor was it originally intended to (I wouldn't expect it to be a common one either, but then again common expectations are always changing). As a potential dub enhancement, e.g., `staticLibraryBundle`, I do agree it's worth exploring. I don't believe you can expect every package to "just work" in that environment. As Steve mentioned, there will always be link-time dependencies to any shared libraries on which those bundled libraries depend. And some packages may be set up in a way that causes issues, as Rikki noted when he said he had to make some tweaks on his successful build. But for the time being, dealing with static libraries in D is just the same as dealing with them in the C and C++ world. They always have been a PITA to deal with, and that's why the trend in recent years has been to move away from them. Build tools like dub hide them from you when used as intended. It's when you mix build systems that you run into trouble. Still, I suggest you send an email to soc...@dlang.org as part of the Gripes and Wishes campaign so that this gets added into the dataset. Anything that enhances dub's usability should be looked at. Having a way to define a static library bundle is really great. It does help a lot when you create a package where it is initialized in non D code. Right now, this is the third time I'm going to need it for my engine, for MacOS I need to manually assign my dependencies, and having only the main code as a library doesn't work for that purpose. I have done before a simple program which executes dub describe for taking the dependencies then I build the program as a staticLibrary, problem is that this requires a 2-pass build and it is not standard.
Can nice D code get a bit slow?
Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe. I thought, without any D knowledge, it could be that with shorter code I might create virtual calls by accident. It might in some rare case have an impact on performance, but it might - on the good side - be the optimizer of one of the three compilers that puts that handling of maybe-virtual calls away or whatever might happen. So, having no clue about D (just bought some books), I wanted to ask if nice looking code can become slow, in general. In the mentioned case it's just that I like the packaging of functions into some sort of scope (OOP) versus the flat C and Go stuff. I like OOP for this reason, but now I'm unsure whether I might stay out of creating classes at all. I do like to write 'in' and 'ref' keywords at their places, for maybe creating some little speed benefits and safety, but the 'final' keyword I then might write because I opted in into OOP looks, for just the visual reason. Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Kind regards
