Re: vibe-d linker error: undefined reference to deimos openssl

2024-09-16 Thread Curtis Spencer via Digitalmars-d-learn
On Saturday, 14 September 2024 at 12:31:01 UTC, Steven 
Schveighoffer wrote:
On Tuesday, 10 September 2024 at 20:41:12 UTC, Curtis Spencer 
wrote:
I'm attempting to upgrade the vibe-d dependencies of a 
project. The project compiles fine using `dub`, but the linker 
fails with:



…


I'm at a loss for how to fix this linker error. Any help would 
be appreciated.


You may have to specify the OpenSSL version with vibe-stream:tls

https://vibed.org/docs#http-https

-Steve


Thanks. I added the following to my dub.sdl file:
```
dependency "vibe-stream:tls" version="~>1.0"
subConfiguration "vibe-stream:tls" "openssl-3.0"
```

but I am still getting essentially the same error:
```
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x70): undefined reference to `_D6deimos7openssl3bio12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x78): undefined reference to `_D6deimos7openssl3err12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x80): undefined reference to `_D6deimos7openssl8opensslv12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x88): undefined reference to `_D6deimos7openssl4rand12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x90): undefined reference to `_D6deimos7openssl3ssl12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0x98): undefined reference to `_D6deimos7openssl5stack12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-stream-1.1.0/vibe-stream/tls/.dub/build/openssl-3.0-debug-linux.posix-x86_64-dmd_v2.101.2-FEA5B9042BC39B78C28FD73CFFA319B61AF4FDBEB7F2781D40C450C1C5A40CC0/libvibe-stream_tls.a(openssl.o):(.data.rel.ro+0xa0): undefined reference to `_D6deimos7openssl6x509v312__ModuleInfoZ'

collect2: error: ld returned 1 exit status
Error: linker exited with status 1
```

Also, should I be using `vibe-d:stream` or `vibe-d:tls` in my 
dub.sdl file? I'm a little confused because both sub-projects are 
listed [here](https://code.dlang.org/packages/vibe-d), but 
`vibe-tls` isn't in the project structure a little further down 
like `vibe-stream` is.


Re: vibe-d linker error: undefined reference to deimos openssl

2024-09-14 Thread Steven Schveighoffer via Digitalmars-d-learn
On Tuesday, 10 September 2024 at 20:41:12 UTC, Curtis Spencer 
wrote:
I'm attempting to upgrade the vibe-d dependencies of a project. 
The project compiles fine using `dub`, but the linker fails 
with:



…


I'm at a loss for how to fix this linker error. Any help would 
be appreciated.


You may have to specify the OpenSSL version with vibe-stream:tls

https://vibed.org/docs#http-https

-Steve


vibe-d linker error: undefined reference to deimos openssl

2024-09-10 Thread Curtis Spencer via Digitalmars-d-learn
I'm attempting to upgrade the vibe-d dependencies of a project. 
The project compiles fine using `dub`, but the linker fails with:


```
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x70): undefined reference to `_D6deimos7openssl3bio12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x78): undefined reference to `_D6deimos7openssl3err12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x80): undefined reference to `_D6deimos7openssl8opensslv12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x88): undefined reference to `_D6deimos7openssl4rand12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x90): undefined reference to `_D6deimos7openssl3ssl12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0x98): undefined reference to `_D6deimos7openssl5stack12__ModuleInfoZ'
/usr/bin/ld: 
../../.dub/packages/vibe-d-0.9.8/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-dmd_v2.101.2-BCC9E2A9CB402B67930FAFFBF7360088035232BADBED8A5363A1A4DE1DBD7D7C/libvibe-d_tls.a(openssl.o):(.data.rel.ro+0xa0): undefined reference to `_D6deimos7openssl6x509v312__ModuleInfoZ'

collect2: error: ld returned 1 exit status
Error: linker exited with status 1
```

Here's version info:
```
$ dub --version
DUB version 1.30.0, built on Jan  1 2023
$ dmd --version
DMD64 D Compiler v2.101.2
Copyright (C) 1999-2022 by The D Language Foundation, All Rights 
Reserved written by Walter Bright

$ openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

```

And my dub dependencies are:
```
dependency "vibe-core" version="~>2.9.0"
dependency "vibe-d:http" version="~>0.9.8"
dependency "vibe-d:data" version="~>0.9.8"
dependency "openssl" version="~>3.3.3"
```

I'm running Ubuntu 24.04 and have libssl-dev installed.
```
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/";
SUPPORT_URL="https://help.ubuntu.com/";
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
$ apt list --installed | grep libssl

libssl-dev/noble-updates,noble-security,now 3.0.13-0ubuntu3.4 
amd64 [installed]
libssl3t64/noble-updates,noble-security,now 3.0.13-0ubuntu3.4 
amd64 [installed,automatic]

```

I'm at a loss for how to fix this linker error. Any help would be 
appreciated.


Re: Trying to call some C code using Extern(C) but got unexpected linker error

2024-06-08 Thread Basile B. via Digitalmars-d-learn

On Saturday, 8 June 2024 at 02:22:00 UTC, Xiaochao Yan wrote:
Hi, I am new to D and is experimenting with game development 
using D and C.


I had some problem when trying to recreate the
https://dlang.org/spec/importc.html

[...]

Thanks in advance!


on a recent compiler this should work:

```d
// .d file
import std.stdio;
import std.conv;
import test;

void main() {
writeln("Hello, World!");

pragma(mangle, "printMessage");
extern (C) void printMessage();

printMessage();
}
```

This was fixed by the dear GH Ghost in 
https://github.com/dlang/dmd/pull/15582.
A short technical explanation: mangling and call conventions are 
not 100% related.

You need to stuff the mangle for that to work.


Re: Trying to call some C code using Extern(C) but got unexpected linker error

2024-06-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On Saturday, 8 June 2024 at 02:22:00 UTC, Xiaochao Yan wrote:
Hi, I am new to D and is experimenting with game development 
using D and C.


I had some problem when trying to recreate the
https://dlang.org/spec/importc.html

Environment:
Windows 11
gcc.exe (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 
8.1.0


Error Message:
```
lld-link: error: undefined symbol: 
_D4test4mainFZ12printMessageUZv

referenced by test.obj:(_Dmain)


```

```
// .c file
#include 

void printMessage() {
printf("Hello from C!\n");
}
```

```
// .d file
import std.stdio;
import std.conv;
import test;

void main() {

writeln("Hello, World!");
extern (C) void printMessage();
printMessage();
}
```
Thanks in advance!


Put `printMessage` outside the main function. Inside the main 
function, it has C linkage, but not C name mangling.


-Steve


Trying to call some C code using Extern(C) but got unexpected linker error

2024-06-07 Thread Xiaochao Yan via Digitalmars-d-learn
Hi, I am new to D and is experimenting with game development 
using D and C.


I had some problem when trying to recreate the
https://dlang.org/spec/importc.html

Environment:
Windows 11
gcc.exe (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 8.1.0

Error Message:
```
lld-link: error: undefined symbol: _D4test4mainFZ12printMessageUZv

referenced by test.obj:(_Dmain)


```

```
// .c file
#include 

void printMessage() {
printf("Hello from C!\n");
}
```

```
// .d file
import std.stdio;
import std.conv;
import test;

void main() {

writeln("Hello, World!");
extern (C) void printMessage();
printMessage();
}
```
Thanks in advance!


Re: Linker error, doing something wrong?

2023-07-09 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/9/23 10:01 AM, Dmitry Olshansky wrote:

Trying to compile the following:

https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d

with:
ldc2 curl_download.d -L-lcurl

get:

   "__D6photon12__ModuleInfoZ", referenced from:
   __D13curl_download12__ModuleInfoZ in curl_download.o
   "__D6photon5macos4core2goFDFZvZv", referenced from:
   __D13curl_download4mainFZ13spawnDownloadMFAyaQdZv in curl_download.o
   "__D6photon5macos4core9startloopFZv", referenced from:
   __Dmain in curl_download.o
   "__D6photon9runFibersFZv", referenced from:
   __Dmain in curl_download.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

Error: /usr/bin/cc failed with status: 1

Am I missing something?


You need to link the library that contains photon.

-Steve


Linker error, doing something wrong?

2023-07-09 Thread Dmitry Olshansky via Digitalmars-d-learn

Trying to compile the following:

https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d

with:
ldc2 curl_download.d -L-lcurl

get:

  "__D6photon12__ModuleInfoZ", referenced from:
  __D13curl_download12__ModuleInfoZ in curl_download.o
  "__D6photon5macos4core2goFDFZvZv", referenced from:
  __D13curl_download4mainFZ13spawnDownloadMFAyaQdZv in 
curl_download.o

  "__D6photon5macos4core9startloopFZv", referenced from:
  __Dmain in curl_download.o
  "__D6photon9runFibersFZv", referenced from:
  __Dmain in curl_download.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

Error: /usr/bin/cc failed with status: 1

Am I missing something?

--
Dmitry Olshansky
https://olshansky.me



Re: Linker Error with Template Function

2022-10-15 Thread Kyle Ingraham via Digitalmars-d-learn

On Saturday, 1 October 2022 at 21:18:05 UTC, Ali Çehreli wrote:

On 10/1/22 11:15, Kyle Ingraham wrote:

> storing structs as
> `void*` in a wrapper struct with information about their
module and
> identifier saved elsewhere.

Perhaps unrelated but that part reminded me of the following 
discussion:


  https://forum.dlang.org/post/tfbn10$19nv$1...@digitalmars.com

Ali


Thanks for this Ali. I found it useful to see another way to 
solve this problem. Seems like it would be great to have a `Type` 
type that can store a type at compile-time for use at run-time.


Re: Linker Error with Template Function

2022-10-01 Thread Ali Çehreli via Digitalmars-d-learn

On 10/1/22 11:15, Kyle Ingraham wrote:

> storing structs as
> `void*` in a wrapper struct with information about their module and
> identifier saved elsewhere.

Perhaps unrelated but that part reminded me of the following discussion:

  https://forum.dlang.org/post/tfbn10$19nv$1...@digitalmars.com

Ali




Re: Linker Error with Template Function

2022-10-01 Thread Kyle Ingraham via Digitalmars-d-learn
On Tuesday, 13 September 2022 at 08:43:45 UTC, Nick Treleaven 
wrote:
On Tuesday, 13 September 2022 at 03:00:17 UTC, Kyle Ingraham 
wrote:
Any suggestions for being able to call one function for any 
instance given but maintain flexible return types?


Not sure if it helps, but you can define final methods in an 
interface, which can call virtual interface methods:

```d
interface PathConverter
{
string getValue();

final T toD(T)()
{
import std.conv : to;

return to!T(getValue());
}
}
```
Not tested as AFK.


Thanks for the suggestion Nick. I solved this by storing structs 
as `void*` in a wrapper struct with information about their 
module and identifier saved elsewhere. I use that information to 
setup casts to the appropriate type then call `toD`. That way I 
can call the same method for functions that return different 
types and store disparate structs to the same wrapper struct. The 
wrapper struct gets used in function signatures.


Re: Linker Error with Template Function

2022-09-13 Thread Nick Treleaven via Digitalmars-d-learn
On Tuesday, 13 September 2022 at 03:00:17 UTC, Kyle Ingraham 
wrote:
Any suggestions for being able to call one function for any 
instance given but maintain flexible return types?


Not sure if it helps, but you can define final methods in an 
interface, which can call virtual interface methods:

```d
interface PathConverter
{
string getValue();

final T toD(T)()
{
import std.conv : to;

return to!T(getValue());
}
}
```
Not tested as AFK.


Re: Linker Error with Template Function

2022-09-12 Thread Kyle Ingraham via Digitalmars-d-learn

On Tuesday, 13 September 2022 at 01:46:14 UTC, Paul Backus wrote:
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham 
wrote:
I am writing a library where I would like to be able to store 
instances of a type of class to an associative array for later 
usage. Each class stored has to implement a function as part 
of the required interface. The argument given is always the 
same type but the return value should be flexible. I solved 
this with an interface:


```d
interface PathConverter
{
T toD(T)(const string value) @safe;
}
```


https://dlang.org/spec/template.html#limitations

Templates cannot be used to add non-static fields or virtual 
functions to classes or interfaces.


You *should* get an error from the compiler for trying to do 
this, instead of just a linker error somewhere else down the 
line, but either way it's not going to work. You'll have to 
find another solution.


Thanks for the spec help Paul. I must've skirted around the 
compiler somehow. This is a minimal example that triggers the 
linker error:


```d
interface PathConverter
{
T toD(T)(string value);
}

class NumberConverter(T) : PathConverter
{
T toD(T)(string value)
{
import std.conv : to;

return to!T(value);
}
}

alias IntConverter = NumberConverter!int;

void main()
{
PathConverter[string] allConverters;
allConverters["int"] = new IntConverter;
int converted = allConverters["int"].toD!int("9");
}
```

Any suggestions for being able to call one function for any 
instance given but maintain flexible return types?


Re: Linker Error with Template Function

2022-09-12 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham 
wrote:
I am writing a library where I would like to be able to store 
instances of a type of class to an associative array for later 
usage. Each class stored has to implement a function as part of 
the required interface. The argument given is always the same 
type but the return value should be flexible. I solved this 
with an interface:


```d
interface PathConverter
{
T toD(T)(const string value) @safe;
}
```


https://dlang.org/spec/template.html#limitations

Templates cannot be used to add non-static fields or virtual 
functions to classes or interfaces.


You *should* get an error from the compiler for trying to do 
this, instead of just a linker error somewhere else down the 
line, but either way it's not going to work. You'll have to find 
another solution.




Linker Error with Template Function

2022-09-12 Thread Kyle Ingraham via Digitalmars-d-learn
I am writing a library where I would like to be able to store 
instances of a type of class to an associative array for later 
usage. Each class stored has to implement a function as part of 
the required interface. The argument given is always the same 
type but the return value should be flexible. I solved this with 
an interface:


```d
interface PathConverter
{
T toD(T)(const string value) @safe;
}
```

That interface lets me type the associative array and any other 
part of the library that needs to use implementers of that 
interface e.g.


```d
PathConverter[string] converters;
```

The problem I'm running into is that when compile the library I 
receive the following error during linking:


```
error LNK2019: unresolved external symbol 
_D3app13PathConverter__T3toDTAyaZQjMFNfxAyaZQp referenced in 
function 
_D3app14TypedURLRouter__T10setHandlerTPFNfC4vibe4http6server17HTTPServerRequestCQBlQBjQBh18HTTPServerResponseAyaZvZQDmMFEQDaQCy6common10HTTPMethodQBlQEhZ__T9__lambda4TQEvTQDoTASQGt16PathCaptureGroupZQBrMFNfQGiQFaQBlZv


fatal error LNK1120: 1 unresolved externals

Error: linker exited with status 1120
```

The call is within a delegate to a function that returns a class 
instance from the associative array. At runtime I fill the 
associative array. The call looks like this:


```d
tailArgs[i] = getPathConverter("id 
string").toD!(Parameters!(handler)[i])("string to convert");

```

Am I running into this error because the linker can't find the 
instantiation of the template method? How would I give the linker 
the information it needs? Is there a better way to have an 
interface with flexible return values?


Re: freebsd dub linker error

2022-09-01 Thread Alain De Vos via Digitalmars-d-learn

On Wednesday, 1 June 2022 at 15:23:14 UTC, Kagamin wrote:

Try to run clang with -v option and compare with gcc.


I've tracked down the problem to the solution where i specify as 
linker to use gcc12 instead of a clang/llvm.

The following works.
```
export CC=clang14
ldc2 --link-defaultlib-shared --gcc=gcc12 ...
```
But i have no explanation.


Re: Request assistance resolving linker error: Undefined symbol(s) for architecture x86_64

2022-08-03 Thread anonymouse via Digitalmars-d-learn

On Wednesday, 3 August 2022 at 09:39:36 UTC, ryuukk_ wrote:

Does adding ```-m64``` work


I'm using macOS so I don't think that applies. But no, it doesn't 
do anything for me.


Thanks,
--anonymouse


Re: Request assistance resolving linker error: Undefined symbol(s) for architecture x86_64

2022-08-03 Thread ryuukk_ via Digitalmars-d-learn

Does adding ```-m64``` work


Re: Request assistance resolving linker error: Undefined symbol(s) for architecture x86_64

2022-08-02 Thread anonymouse via Digitalmars-d-learn

On Wednesday, 3 August 2022 at 05:04:08 UTC, H. S. Teoh wrote:
On Wed, Aug 03, 2022 at 04:28:57AM +, anonymouse via 
Digitalmars-d-learn wrote:
How do I go about tracking down what's causing the following 
error:


```
Undefined symbols for architecture x86_64:
  "__D3std8internal6memory12__ModuleInfoZ", referenced from:
  __D3loxQe12__ModuleInfoZ in dlux.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v 
to see

invocation)
```

I'm not explicitly calling anything in std.internal.memory so 
not sure how to resolve. Thanks.

[...]

This is often a sign of version mismatch between libraries and 
compiler. Did you recently upgrade your compiler?  Did you 
accidentally install two versions of the standard library and 
the new compiler is mistakenly picking up the old library?


Interesting... no I only have one version of DMD installed on this
computer (v2.100.0) and it's never been updated.


Maybe try also recompiling your project from clean slate just 
in case your build process is picking up stale binaries for 
whatever reason. If you have object files compiled with the old 
version of the compiler still lying around, and they get picked 
up when compiling with the new compiler, it would cause link 
errors like the above.


This project aims at learning how compilers work. I'm simply 
adapting Robert Nystrom's code from his book [Crafting 
Compiler](http://www.craftinginterpreters.com/scanning.html). The 
source tree currently looks like this:


```
lox
  |
  + lox.d
  |
  + main.d
  |
  + scanner.d
  |
  + token.d
  |
  + tokentype.d
```

My entire build process comprises issuing the command:
```
dmd -of=dlux lox/*
```

I've tried using -J, -I, and moving main to the current working 
directory but all these result in the same error.


--anonymouse



Re: Request assistance resolving linker error: Undefined symbol(s) for architecture x86_64

2022-08-02 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Aug 03, 2022 at 04:28:57AM +, anonymouse via Digitalmars-d-learn 
wrote:
> How do I go about tracking down what's causing the following error:
> 
> ```
> Undefined symbols for architecture x86_64:
>   "__D3std8internal6memory12__ModuleInfoZ", referenced from:
>   __D3loxQe12__ModuleInfoZ in dlux.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ```
> 
> I'm not explicitly calling anything in std.internal.memory so not sure
> how to resolve. Thanks.
[...]

This is often a sign of version mismatch between libraries and compiler.
Did you recently upgrade your compiler?  Did you accidentally install
two versions of the standard library and the new compiler is mistakenly
picking up the old library?

Maybe try also recompiling your project from clean slate just in case
your build process is picking up stale binaries for whatever reason. If
you have object files compiled with the old version of the compiler
still lying around, and they get picked up when compiling with the new
compiler, it would cause link errors like the above.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win 
are idiots.


Request assistance resolving linker error: Undefined symbol(s) for architecture x86_64

2022-08-02 Thread anonymouse via Digitalmars-d-learn
How do I go about tracking down what's causing the following 
error:


```
Undefined symbols for architecture x86_64:
  "__D3std8internal6memory12__ModuleInfoZ", referenced from:
  __D3loxQe12__ModuleInfoZ in dlux.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

```

I'm not explicitly calling anything in std.internal.memory so not 
sure how to resolve. Thanks.


--anonymouse


Re: freebsd dub linker error

2022-06-01 Thread Kagamin via Digitalmars-d-learn

Try to run clang with -v option and compare with gcc.


Re: freebsd dub linker error

2022-06-01 Thread Alain De Vos via Digitalmars-d-learn

The detailed error is :
```
/usr/bin/clang test.o -o test -L/usr/local/lib -lphobos2-ldc 
-ldruntime-ldc -Wl,--gc-sections -lexecinfo -lpthread -lm -m64

ld: error: undefined hidden symbol: __start___minfo

referenced by test.d
  test.o:(ldc.register_dso)


```


Re: freebsd dub linker error

2022-06-01 Thread Alain De Vos via Digitalmars-d-learn

Performed additional tests.
Compiling helloworld.d
```
export CC=gcc11 ; ldc2 helloworld.d
```
works fine.

Compiling helloworld.d
```
export CC=clang ; ldc2 helloworld.d
```
returns:
```
d: error: undefined hidden symbol: __start___minfo

referenced by test.d
  test.o:(ldc.register_dso)


ld: error: undefined hidden symbol: __stop___minfo

referenced by test.d
  test.o:(ldc.register_dso)
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

Error: /usr/bin/clang failed with status: 1
```

So I have a workaround by fixing it to gcc


Re: freebsd dub linker error

2022-05-16 Thread Alain De Vos via Digitalmars-d-learn

Bugs in the clang/llvm toolchain but not in the gcc toolchain ?


Re: freebsd dub linker error

2022-05-16 Thread Alain De Vos via Digitalmars-d-learn

The following worked , and i don't know what is going on:
```
ldc2 --gcc=gcc11
```



Re: freebsd dub linker error

2022-05-16 Thread Alain De Vos via Digitalmars-d-learn

The problem re-appeared and i have totally no idea what caused it.
ldc2 test.d
ld: error: undefined hidden symbol: __start___minfo

referenced by test.d
  test.o:(ldc.register_dso)


ld: error: undefined hidden symbol: __stop___minfo

referenced by test.d
  test.o:(ldc.register_dso)
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)

Error: /usr/bin/cc failed with status: 1

The only thing i did was disabling 32-bit code in kernel and 
userland.


Re: freebsd dub linker error

2022-03-17 Thread rikki cattermole via Digitalmars-d-learn



On 18/03/2022 5:56 PM, rikki cattermole wrote:

Are you trying to build dub on Android?

Android support for ldc is currently broken to due to removal of a 
linker that is currently required for TLS support.


https://github.com/ldc-developers/ldc/issues/3918


My bad I didn't see FreeBSD.

Similar issue, quite possibly related given the old version 2.069.0 
being referenced.


https://github.com/ldc-developers/ldc/pull/3106


Re: freebsd dub linker error

2022-03-17 Thread rikki cattermole via Digitalmars-d-learn

Are you trying to build dub on Android?

Android support for ldc is currently broken to due to removal of a 
linker that is currently required for TLS support.


https://github.com/ldc-developers/ldc/issues/3918


freebsd dub linker error

2022-03-17 Thread Alain De Vos via Digitalmars-d-learn
I disabled 32bit code maybe this created the following error 
while building dub :


[00:02:18] 
===
[00:02:18] ===>

[00:02:18] ===>  Configuring for dub-1.14.0
[00:02:23] 
===
[00:02:23] ===>

[00:02:23] ===>  Building for dub-1.14.0
[00:02:41] build.sh: cannot open 2.069.0: No such file or 
directory

[00:02:41] Using existing version file.
[00:02:41] Running ldmd2...
[00:02:58] Serializing composite type BuildRequirements which has 
no serializable fields
[00:02:58] Serializing composite type BuildOptions which has no 
serializable fields
[00:02:59] source/dub/dub.d(1602): Deprecation: function 
`std.typecons.Nullable!(PackageRecipe).Nullable.get_` is 
deprecated - Implicit conversion with `alias Nullable.get this` 
will be removed after 2.096. Please use `.get` explicitly.
[00:02:59] source/dub/packagesuppliers/maven.d(81): Deprecation: 
module `std.xml` is deprecated - Will be removed from Phobos in 
2.101.0. If you still need it, go to 
https://github.com/DigitalMars/undeaD
[00:02:59] source/dub/project.d(288): Deprecation: variable `c` 
is shadowing variable `dub.project.Project.validate.c`. Rename 
the `foreach` variable.
[00:03:00] source/dub/generators/build.d(338): Deprecation: 
module `std.digest.digest` is deprecated - import std.digest 
instead of std.digest.digest. std.digest.digest will be removed 
in 2.101

[00:04:19] ld: error: undefined hidden symbol: __start___minfo
[00:04:19] >>> referenced by sdl.d
[00:04:19] >>>   bin/dub.o:(ldc.register_dso)
[00:04:19]
[00:04:19] ld: error: undefined hidden symbol: __stop___minfo
[00:04:19] >>> referenced by sdl.d
[00:04:19] >>>   bin/dub.o:(ldc.register_dso)
[00:04:19] cc: error: linker command failed with exit code 1 (use 
-v to see invocation)

[00:04:19] Error: /usr/bin/cc failed with status: 1
[00:04:19] *** Error code 1
[00:04:19]
[00:04:19] Stop.
[00:04:19] make: stopped in /usr/ports/devel/dub
[00:04:20] =>> Cleaning up wrkdir
[00:04:20] ===>  Cleaning for dub-1.14.0
[00:04:23] build of devel/dub | dub-1.14.0 ended at Fri Mar 18 
03:59:34 CET 2022

[00:04:23] build time: 00:04:23
[00:04:23] !!! build failure encountered !!!



Re: Linker error under Ubuntu

2022-01-17 Thread murphybeck via Digitalmars-d-learn
Most of the time these are dependency-issues. You need to install 
a package called python-dev. This package includes header files, 
a static library and development tools for building Python 
modules, extending the Python interpreter or embedding Python in 
applications. When encountering this error please note before the 
error it may say you are missing a package or header file — you 
should find those and install them and verify if it works


For Python 2.x use:

$ sudo apt-get install python-dev

If you using 
[python](http://net-informations.com/python/iq/default.htm)3, try 
to replace python-dev with python3-dev


For a specific version of Python 3, replace x with the minor 
version in


$ sudo apt-get install python3.x-dev




Re: Linker error

2021-10-12 Thread bauss via Digitalmars-d-learn

On Tuesday, 12 October 2021 at 00:01:25 UTC, jfondren wrote:
On Monday, 11 October 2021 at 23:43:17 UTC, Ruby The Roobster 
wrote:

package mixin template move__() {
	pragma(inline) package void mv(Point moveby, ref Skeleton 
tomove)	{

foreach(i;tomove.faces) {
foreach(k;i.lines)  {
foreach(j;k.mid_points) {
j += moveby;
}
k.start += moveby;
k.stop += moveby;
}
i.center += moveby;
}
tomove.center += moveby;
}
}


It compiles if this `pragma(inline)` is removed.


Not to mention there is no point in marking mv with either 
pragma(inline) or package.


It's mixed into the function move(), which means it cannot be 
accessed outside of the function anyway, so that makes package 
unnecessary.


Inline will probably do nothing as the inline really just tells 
the compiler it should inline if it can or wants to, it's not a 
guarantee and it probably can't inline the function in this case.


Re: Linker error

2021-10-11 Thread jfondren via Digitalmars-d-learn
On Monday, 11 October 2021 at 23:43:17 UTC, Ruby The Roobster 
wrote:

package mixin template move__() {
	pragma(inline) package void mv(Point moveby, ref Skeleton 
tomove)	{

foreach(i;tomove.faces) {
foreach(k;i.lines)  {
foreach(j;k.mid_points) {
j += moveby;
}
k.start += moveby;
k.stop += moveby;
}
i.center += moveby;
}
tomove.center += moveby;
}
}


It compiles if this `pragma(inline)` is removed.


Linker error

2021-10-11 Thread Ruby The Roobster via Digitalmars-d-learn

So, I have the following two files:

skeleton.d:
```d
/*skeleton.d by Ruby The Roobster*/
/*Version 1.0 Release*/
/*Module for representing skeletons in the D Programming Language 
2.0*/
/*This program is free software: you can redistribute it and/or 
modify
it under the terms of the GNU General Public License as published 
by

the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see 
.*/

/** Copyright: 2021, Ruby The Roobster*/
/**Author: Ruby The Roobster, michaeleverest...@gmail.com*/
/**Date: October 1, 2021*/
/** License:  GPL-3.0*/
module dutils.skeleton;
/**Struct for representing a point.*/
public struct Point { //Point structure...
///Point.x is the 'x' coordinate of the point.
real x;
///Point.y is the 'y' coordinate of the point.
real y;
///Point.z is the 'z' coordinate of the point.
real z;
void opAssign(Point rhs){
this.x = rhs.x;
this.y = rhs.y;
this.z = rhs.z;
}
void opOpAssign(string op)(Point rhs)   {
mixin("this.x " ~ op ~ "= rhs.x;");
mixin("this.y " ~ op ~ "= rhs.y;");
mixin("this.z " ~ op ~ "= rhs.z;");
}
}
/**Struct for representing a face of a skeleton that is made out 
of lines.*/

public struct Face  { //Face(of a 3D shape) structure...
	///Face.lines is an array of all the lines that connect to form 
the face.

Line[] lines;
///Face.center is the center point of the face.
Point center;
void opAssign(Face rhs) {
this.lines.length = rhs.lines.length;
foreach(i;0 .. this.lines.length)   {
this.lines[i] = rhs.lines[i];
}
}
}
/**Struct for representing a 3D skeleton.*/
public struct Skeleton  { //Skeleton of a 3D structure...
	///Skeleton.faces is an array of the faces that make up the 
Skeleton.

Face[] faces;
///Skeleton.center is the center point of the skeleton.
Point center;
void opAssign(Skeleton rhs) {
this.faces.length = rhs.faces.length;
foreach(i;0 .. this.faces.length)   {
this.faces[i] = rhs.faces[i];
}
this.center = rhs.center;
}
}

/**Struct for representing a line composed of at least a starting 
point and an end point.

  *Notes:
  *This struct doesn't check to make sure that the line made is 
an actual line and assumes the user knows what they are doing.

*/
public struct Line  { //Line struct...
	///Line.mid_points is an array containing all of the points that 
are neither start nor end points.

Point[] mid_points;
///Line.start is the start point of the line.
Point start;
///Line.end is the end point of the line.
Point stop;
void opAssign(Line rhs) {
this.start = rhs.start;
this.stop = rhs.stop;
this.mid_points.length = rhs.mid_points.length;
foreach(i;0 .. this.mid_points.length)  {
this.mid_points[i] = rhs.mid_points[i];
}
}
}
```

physics.d:
```d
/*physics.d by Ruby The Roobster*/
/*Version 0.35 testing*/
/*Module for basic physics in the D Programming Language 2.0*/
/*This program is free software: you can redistribute it and/or 
modify
it under the terms of the GNU General Public License as published 
by

the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see 
.*/

/** Copyright: 2021, Ruby The Roobster*/
/**Author: Ruby The Roobster, michaeleverest...@gmail.com*/
/**Date: October 11, 2021*/
/** License: GPL-3.0*/
module dutils.physics;
public import dutils.skeleton;

package mixin template move__() {
	pragma(inline) package void mv(Point moveby, ref Skeleton 
tomove)	{

foreach(i;tomove.faces) {
foreach(k;i.lines)  {
foreach(j;k.mid_points) {
j += moveby;
}
k.start += mo

Re: alias using Complex!Double in module ... linker error??

2021-08-03 Thread james.p.leblanc via Digitalmars-d-learn

On Wednesday, 4 August 2021 at 01:10:15 UTC, Mike Parker wrote:
On Tuesday, 3 August 2021 at 21:40:09 UTC, james.p.leblanc 
wrote:

[...]


The alias to Complex!double is a template instantiation. A 
template instantiation creates a symbol that needs to be 
linked. So you need to compile my_module.d along with my_main.d.


```
dmd my_main.d my_module.d
```

Or alternatively:

```
dmd -i my_main.d
```

double is a built-in type, so that alias doesn't create any 
symbols that need linking.


An alias in and of itself is a compile-time-only construct, but 
the symbols you assign it might require linking something.


Mike,

Aha... that makes sense now!

Thanks kindly for helping me understand what was happening with 
your
informative reply.  The fact of template instantiations and 
symbols

had escaped me completely.

I appreciate it.

Best Regards,
James


Re: alias using Complex!Double in module ... linker error??

2021-08-03 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 3 August 2021 at 21:40:09 UTC, james.p.leblanc wrote:

I am getting linker errors with this stripped-down example:

---
**my_main.d:**

import std.stdio;
import std.complex;
import my_module;


void main(){
  my_TYPE xxx;
  writeln(xxx);
}

---
**my_module.d:**

module my_module;

import std.complex;

alias my_TYPE = Complex!double;*// this causes link error: 
"undefined reference"*


/* alias my_TYPE = double; */  *// this works fine*

--

Why does the linker fail when I alias to the Complex!double ...
but would work fine when alias to the double ??

Any help to understand what is greatly appreciated.
James


The alias to Complex!double is a template instantiation. A 
template instantiation creates a symbol that needs to be linked. 
So you need to compile my_module.d along with my_main.d.


```
dmd my_main.d my_module.d
```

Or alternatively:

```
dmd -i my_main.d
```

double is a built-in type, so that alias doesn't create any 
symbols that need linking.


An alias in and of itself is a compile-time-only construct, but 
the symbols you assign it might require linking something.


alias using Complex!Double in module ... linker error??

2021-08-03 Thread james.p.leblanc via Digitalmars-d-learn

I am getting linker errors with this stripped-down example:

---
**my_main.d:**

import std.stdio;
import std.complex;
import my_module;


void main(){
  my_TYPE xxx;
  writeln(xxx);
}

---
**my_module.d:**

module my_module;

import std.complex;

alias my_TYPE = Complex!double;*// this causes link error: 
"undefined reference"*


/* alias my_TYPE = double; */  *// this works fine*

--

Why does the linker fail when I alias to the Complex!double ...
but would work fine when alias to the double ??

Any help to understand what is greatly appreciated.
James




Re: Linker error under Ubuntu

2020-05-15 Thread kinke via Digitalmars-d-learn

On Thursday, 14 May 2020 at 16:09:16 UTC, solidstate1991 wrote:
When I try to compile my own project under Ubuntu with dub, I 
get the following linker error:


/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o: 
undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
/usr/bin/ldc2 failed with exit code 1.


This sounds like a misconfigured distro-LDC. zlib is usually 
integrated into libphobos, but distros tend to favor the distro's 
libz.so and patch it out. That must be handled in /etc/ldc2.conf 
though, with something like 
`-defaultlib=phobos2-ldc,z,druntime-ldc` (and possibly a 
zlib1g-dev package dependency).


Re: Linker error under Ubuntu

2020-05-15 Thread evilrat via Digitalmars-d-learn

On Friday, 15 May 2020 at 23:49:37 UTC, solidstate1991 wrote:


Dub should do the linking by itself.


How does it know what to link?



Re: Linker error under Ubuntu

2020-05-15 Thread solidstate1991 via Digitalmars-d-learn

On Friday, 15 May 2020 at 03:46:57 UTC, evilrat wrote:


Um, pardon the stupid question, but did you just forgot to link 
it? I can't see a mention of it anywhere in both the old json 
and dub.sdl, and I don't see subpackages either. (does it links 
implicitly by the compiler?)


Also if it's digged up somewhere, another possibility is the 
link order issue(you need to put libs in order that adds linker 
symbols for previous libs to consume, for circular dependencies 
you can specify libs multiple times). The MS linker and LLVM 
linkers(not sure about GNU gold) does some work for you so you 
don't have to reorder libs most of the time.


Dub should do the linking by itself.


Re: Linker error under Ubuntu

2020-05-14 Thread evilrat via Digitalmars-d-learn

On Thursday, 14 May 2020 at 16:09:16 UTC, solidstate1991 wrote:
When I try to compile my own project under Ubuntu with dub, I 
get the following linker error:


/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o: 
undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
/usr/bin/ldc2 failed with exit code 1.

I've checked for zlib and it was already preinstalled. I tried 
to install LLD, but that didn't help.


The latest version of my project found here: 
https://github.com/ZILtoid1991/pixelperfectengine


Um, pardon the stupid question, but did you just forgot to link 
it? I can't see a mention of it anywhere in both the old json and 
dub.sdl, and I don't see subpackages either. (does it links 
implicitly by the compiler?)


Also if it's digged up somewhere, another possibility is the link 
order issue(you need to put libs in order that adds linker 
symbols for previous libs to consume, for circular dependencies 
you can specify libs multiple times). The MS linker and LLVM 
linkers(not sure about GNU gold) does some work for you so you 
don't have to reorder libs most of the time.


Linker error under Ubuntu

2020-05-14 Thread solidstate1991 via Digitalmars-d-learn
When I try to compile my own project under Ubuntu with dub, I get 
the following linker error:


/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o: 
undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
/usr/bin/ldc2 failed with exit code 1.

I've checked for zlib and it was already preinstalled. I tried to 
install LLD, but that didn't help.


The latest version of my project found here: 
https://github.com/ZILtoid1991/pixelperfectengine


Re: Linker error: _D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m

2019-05-30 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-05-30 15:36:53 +, Robert M. Münch said:

I updated to the latest DMD compiler and just re-compiled a project and 
now I get two unresolved external errors:


widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m".
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m".


What is this about? That looks like some D internal stuff...


Ok, so the problem was, that the 64-bit phobos lib wasn't updated. It 
was still the old one from a DMD version before.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Linker error: _D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m

2019-05-30 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-05-30 16:06:48 +, KnightMare said:


immutable(ulong[2]) object.RTInfoImpl!([48, 57]).RTInfoImpl
immutable(ulong[2]) object.RTInfoImpl!([32, 14]).RTInfoImpl
through
writeln( demangle("_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m"));
writeln( demangle("_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m"));


Thanks, forgot about demangle()... However, that doesn't help my any 
further. Any ideas?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Linker error: _D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m

2019-05-30 Thread KnightMare via Digitalmars-d-learn
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m".
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m".




immutable(ulong[2]) object.RTInfoImpl!([48, 57]).RTInfoImpl
immutable(ulong[2]) object.RTInfoImpl!([32, 14]).RTInfoImpl
through
writeln( demangle("_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m"));
writeln( demangle("_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m"));


Linker error: _D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m

2019-05-30 Thread Robert M. Münch via Digitalmars-d-learn
I updated to the latest DMD compiler and just re-compiled a project and 
now I get two unresolved external errors:


widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m".
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol 
"_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m".


What is this about? That looks like some D internal stuff...

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Undescriptive linker error. (bug?)

2019-04-05 Thread Sjoerd Nijboer via Digitalmars-d-learn

On Friday, 5 April 2019 at 22:08:50 UTC, Adam D. Ruppe wrote:

Weird combination of cases that maybe should be illegal.


It errors with the highly descriptive errormessage:

app.obj(app)
 Error 42: Symbol Undefined __D8mymodule3BarFZ3fooMFZCQx3Foo
Error: linker exited with status 1


Re: Undescriptive linker error. (bug?)

2019-04-05 Thread Adam D. Ruppe via Digitalmars-d-learn

On Friday, 5 April 2019 at 21:59:35 UTC, Sjoerd Nijboer wrote:

Foo Bar()
{
Foo foo();


It looks like the compiler is treating that as a function 
prototype without a body (that just happens to be nested in 
another function).



return foo;


And then, this foo is given the optional parens treatment, as if 
it was a call to foo() of the given function, which is why the 
linker complains.


Weird combination of cases that maybe should be illegal.



Undescriptive linker error. (bug?)

2019-04-05 Thread Sjoerd Nijboer via Digitalmars-d-learn

module mymodule;

class Foo{}

Foo Bar()
{
Foo foo();

return foo;
}

int main()
{
auto foo = Bar();

return 0;
}

This code doesn't compile with a linker error that there's a 
missing symbol for `Foo Bar()` on windows.

After all, `Foo foo();` isn't legitimate D.
But why does it return a linker error?
shouldn't it give an error that is more descriptive about a class 
instance being wrong?

I feel like this would be a common thing people try to write.
Especially in templates this would become difficult to narrow 
down.


Re: Linker error

2019-01-21 Thread Steven Schveighoffer via Digitalmars-d-learn

On 1/21/19 5:28 PM, Jerry wrote:

On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer wrote:

On 1/21/19 3:37 PM, Jerry wrote:

[...]


I had a similar problem that I fixed myself actually last dconf:

https://issues.dlang.org/show_bug.cgi?id=17968

This looks almost identical as the issue was in the generated xtoHash 
function.


What version of the compiler are you using? My issue was fixed in 
2.080.1, and then a followup fix in 2.081.1.




Ok, I get the same linker error down to version 2.74. Below that my 
eventcore version does not compile. Atleast LDC can compile so I can 
move forward. I will try to dustmite this tomorrow.


This was a PITA for me when it happened (I used dustmite to go down to a 
pretty small version). I was essentially blocked on my work in iopipe 
until this was fixed.


The issue I ran starts with dmd generating a function xtoHash for 
structs where you don't define toHash. In certain cases (and these can 
be very weird indeed), dmd generates a function which, for each of its 
members, calls essentially typeid(x).toHash(&x).


In the case of a struct that contains a class reference, this all goes 
fine, but the compiler doesn't generate the TypeInfo for the class when 
it should in these certain cases (in particular, the TypeInfo_Const for 
that class reference).


The reason I feel like your error is very very similar, is because you 
show the missing symbol as being the InitZ, which is the TypeInfo 
initializer of something, and you see the symbol that requires it as 
being an xtoHash symbol.


Not knowing your code base, it's hard to know what exact situation 
you're in. But hopefully this helps you get an understanding as to why 
it might happen.


I think in my case, it was a template class in an auto function, within 
an import (hard now to remember the details). In fact, the root cause is 
still there, I just added a workaround in the xtoHash generation (that 
cheats and uses typeid(Object) instead of the real typeid, since it's a 
virtual function call anyway).


See the related bug report with the root cause: 
https://issues.dlang.org/show_bug.cgi?id=18833, maybe it helps you 
relate to what is happening.


-Steve


Re: Linker error

2019-01-21 Thread Jerry via Digitalmars-d-learn

On Monday, 21 January 2019 at 22:31:15 UTC, H. S. Teoh wrote:
On Mon, Jan 21, 2019 at 10:19:00PM +, Jerry via 
Digitalmars-d-learn wrote:

On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:

[...]

> Looks like a problem with stale cached object files.  Try:
> 
> 	rm dub.selections.json

>dub build --force
> 
> (Be sure to back up dub.selections.json before doing this, 
> if you

> have customized it by hand.)

[...]

Still same error, on both 2.78 and 2.84.


Hmm.  OK, then I've no idea what's wrong, sorry.


T


Thank you for all the effort!


Re: Linker error

2019-01-21 Thread H. S. Teoh via Digitalmars-d-learn
On Mon, Jan 21, 2019 at 10:19:00PM +, Jerry via Digitalmars-d-learn wrote:
> On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:
[...]
> > Looks like a problem with stale cached object files.  Try:
> > 
> > rm dub.selections.json
> > dub build --force
> > 
> > (Be sure to back up dub.selections.json before doing this, if you
> > have customized it by hand.)
[...]
> Still same error, on both 2.78 and 2.84.

Hmm.  OK, then I've no idea what's wrong, sorry.


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada


Re: Linker error

2019-01-21 Thread Jerry via Digitalmars-d-learn
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer 
wrote:

On 1/21/19 3:37 PM, Jerry wrote:

[...]


I had a similar problem that I fixed myself actually last dconf:

https://issues.dlang.org/show_bug.cgi?id=17968

This looks almost identical as the issue was in the generated 
xtoHash function.


What version of the compiler are you using? My issue was fixed 
in 2.080.1, and then a followup fix in 2.081.1.


-Steve


Ok, I get the same linker error down to version 2.74. Below that 
my eventcore version does not compile. Atleast LDC can compile so 
I can move forward. I will try to dustmite this tomorrow.


Re: Linker error

2019-01-21 Thread Jerry via Digitalmars-d-learn

On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:
On Mon, Jan 21, 2019 at 04:02:23PM -0500, Steven Schveighoffer 
via Digitalmars-d-learn wrote:

On 1/21/19 3:37 PM, Jerry wrote:
> [...]

[...]

> [...]

[...]

Looks like a problem with stale cached object files.  Try:

rm dub.selections.json
dub build --force

(Be sure to back up dub.selections.json before doing this, if 
you have

customized it by hand.)


T


Still same error, on both 2.78 and 2.84.


Re: Linker error

2019-01-21 Thread Jerry via Digitalmars-d-learn
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer 
wrote:
What version of the compiler are you using? My issue was fixed 
in 2.080.1, and then a followup fix in 2.081.1.


-Steve



Hello!
I am using 2.084.
Interestingly it works with LDC 1.9 (frontend 2.79) and that just 
works fine.


Bisecting dmd versions.

- Jerry


Re: Linker error

2019-01-21 Thread H. S. Teoh via Digitalmars-d-learn
On Mon, Jan 21, 2019 at 04:02:23PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 1/21/19 3:37 PM, Jerry wrote:
> > Hello, I am trying to compile a 1 year old project of mine which
> > uses htmld and vibed. But I get this weird linker error which does
> > not make any sense to me atleast. I am using Windows 7 and dub.
[...]
> > my_stuff.obj : error LNK2019: unresolved external symbol
> > _D60TypeInfo_xS4html3dom__T15ChildrenForwar
> > dTCQBfQBd4NodeVnnZQBi6__initZ referenced in function
> > _D8typecons__T11ThrowOnNullTS4html3dom__T15Chil
> > drenForwardTCQBfQBd4NodeVnnZQBiZQCn9__xtoHashFNbNeKxSQDu__TQDoTQDeZQDwZm
> > ..dub\build\updater-local-debug-windows-x86_64-dmd_2083-F0ADCB72FF986B7D6354817AF1E3A045\my_stuff.exe
> > 
> >   : fatal error LNK1120: 1 unresolved externals
> > Error: linker exited with status 1120
> > dmd failed with exit code 1.
[...]

Looks like a problem with stale cached object files.  Try:

rm dub.selections.json
dub build --force

(Be sure to back up dub.selections.json before doing this, if you have
customized it by hand.)


T

-- 
Music critic: "That's an imitation fugue!"


Re: Linker error

2019-01-21 Thread Steven Schveighoffer via Digitalmars-d-learn

On 1/21/19 3:37 PM, Jerry wrote:
Hello, I am trying to compile a 1 year old project of mine which uses 
htmld and vibed. But I get this weird linker error which does not make 
any sense to me atleast. I am using Windows 7 and dub.


htmld 0.3.6: target for configuration "library" is up to date.
taggedalgebraic 0.10.12: target for configuration "library" is up to date.
eventcore 0.8.40: target for configuration "winapi" is up to date.
stdx-allocator 2.77.5: target for configuration "library" is up to date.
vibe-core 1.5.0: target for configuration "winapi" is up to date.
vibe-d:utils 0.8.4: target for configuration "library" is up to date.
vibe-d:data 0.8.4: target for configuration "library" is up to date.
mir-linux-kernel 1.0.1: target for configuration "library" is up to date.
vibe-d:crypto 0.8.4: target for configuration "library" is up to date.
diet-ng 1.5.0: target for configuration "library" is up to date.
vibe-d:stream 0.8.4: target for configuration "library" is up to date.
vibe-d:textfilter 0.8.4: target for configuration "library" is up to date.
vibe-d:inet 0.8.4: target for configuration "library" is up to date.
vibe-d:tls 0.8.4: target for configuration "openssl-mscoff" is up to date.
vibe-d:http 0.8.4: target for configuration "library" is up to date.
vibe-d:mail 0.8.4: target for configuration "library" is up to date.
vibe-d:mongodb 0.8.4: target for configuration "library" is up to date.
vibe-d:redis 0.8.4: target for configuration "library" is up to date.
vibe-d:web 0.8.4: target for configuration "library" is up to date.
vibe-d 0.8.4: target for configuration "vibe-core" is up to date.
my_stuff ~master: building configuration "updater-local"...
Linking...
vibe-d_web.lib(common.obj) : warning LNK4255: library contain multiple 
objects of the same name; lin

king object as if no debug info
eventcore.lib(driver.obj) : warning LNK4255: library contain multiple 
objects of the same name; link

ing object as if no debug info
eventcore.lib(driver.obj) : warning LNK4255: library contain multiple 
objects of the same name; link

ing object as if no debug info
eventcore.lib(core.obj) : warning LNK4255: library contain multiple 
objects of the same name; linkin

g object as if no debug info
my_stuff.obj : error LNK2019: unresolved external symbol 
_D60TypeInfo_xS4html3dom__T15ChildrenForwar
dTCQBfQBd4NodeVnnZQBi6__initZ referenced in function 
_D8typecons__T11ThrowOnNullTS4html3dom__T15Chil

drenForwardTCQBfQBd4NodeVnnZQBiZQCn9__xtoHashFNbNeKxSQDu__TQDoTQDeZQDwZm
..dub\build\updater-local-debug-windows-x86_64-dmd_2083-F0ADCB72FF986B7D6354817AF1E3A045\my_stuff.exe 


  : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
dmd failed with exit code 1.

I tried to find the typecons.ThrowOnNull thing in the standard library 
but that one does not exist. So I am pretty confused about what is going 
on here.


Thank you.


I had a similar problem that I fixed myself actually last dconf:

https://issues.dlang.org/show_bug.cgi?id=17968

This looks almost identical as the issue was in the generated xtoHash 
function.


What version of the compiler are you using? My issue was fixed in 
2.080.1, and then a followup fix in 2.081.1.


-Steve


Linker error

2019-01-21 Thread Jerry via Digitalmars-d-learn
Hello, I am trying to compile a 1 year old project of mine which 
uses htmld and vibed. But I get this weird linker error which 
does not make any sense to me atleast. I am using Windows 7 and 
dub.


htmld 0.3.6: target for configuration "library" is up to date.
taggedalgebraic 0.10.12: target for configuration "library" is up 
to date.

eventcore 0.8.40: target for configuration "winapi" is up to date.
stdx-allocator 2.77.5: target for configuration "library" is up 
to date.

vibe-core 1.5.0: target for configuration "winapi" is up to date.
vibe-d:utils 0.8.4: target for configuration "library" is up to 
date.
vibe-d:data 0.8.4: target for configuration "library" is up to 
date.
mir-linux-kernel 1.0.1: target for configuration "library" is up 
to date.
vibe-d:crypto 0.8.4: target for configuration "library" is up to 
date.

diet-ng 1.5.0: target for configuration "library" is up to date.
vibe-d:stream 0.8.4: target for configuration "library" is up to 
date.
vibe-d:textfilter 0.8.4: target for configuration "library" is up 
to date.
vibe-d:inet 0.8.4: target for configuration "library" is up to 
date.
vibe-d:tls 0.8.4: target for configuration "openssl-mscoff" is up 
to date.
vibe-d:http 0.8.4: target for configuration "library" is up to 
date.
vibe-d:mail 0.8.4: target for configuration "library" is up to 
date.
vibe-d:mongodb 0.8.4: target for configuration "library" is up to 
date.
vibe-d:redis 0.8.4: target for configuration "library" is up to 
date.
vibe-d:web 0.8.4: target for configuration "library" is up to 
date.

vibe-d 0.8.4: target for configuration "vibe-core" is up to date.
my_stuff ~master: building configuration "updater-local"...
Linking...
vibe-d_web.lib(common.obj) : warning LNK4255: library contain 
multiple objects of the same name; lin

king object as if no debug info
eventcore.lib(driver.obj) : warning LNK4255: library contain 
multiple objects of the same name; link

ing object as if no debug info
eventcore.lib(driver.obj) : warning LNK4255: library contain 
multiple objects of the same name; link

ing object as if no debug info
eventcore.lib(core.obj) : warning LNK4255: library contain 
multiple objects of the same name; linkin

g object as if no debug info
my_stuff.obj : error LNK2019: unresolved external symbol 
_D60TypeInfo_xS4html3dom__T15ChildrenForwar
dTCQBfQBd4NodeVnnZQBi6__initZ referenced in function 
_D8typecons__T11ThrowOnNullTS4html3dom__T15Chil

drenForwardTCQBfQBd4NodeVnnZQBiZQCn9__xtoHashFNbNeKxSQDu__TQDoTQDeZQDwZm
.dub\build\updater-local-debug-windows-x86_64-dmd_2083-F0ADCB72FF986B7D6354817AF1E3A045\my_stuff.exe
 : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
dmd failed with exit code 1.

I tried to find the typecons.ThrowOnNull thing in the standard 
library but that one does not exist. So I am pretty confused 
about what is going on here.


Thank you.


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-09-01 Thread kinke via Digitalmars-d-learn

On Saturday, 1 September 2018 at 18:46:32 UTC, Nordlöw wrote:
Thanks! Is there usually only apps and not libs that are 
supposed to have linker flags like these?


In this specific case, I'm not sure it's a good idea to set the 
linker in the dub config. Does it absolutely require gold, i.e., 
not work properly with bfd? There used to be issues with 
`-flto=thin` and bfd on Linux, but LDC now defaults to 
`-linker=gold` in that case.


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-09-01 Thread Nordlöw via Digitalmars-d-learn

On Thursday, 30 August 2018 at 20:36:02 UTC, kinke wrote:

On Thursday, 30 August 2018 at 19:41:38 UTC, Nordlöw wrote:

I'm using the tar.xz for x64 Linux. Ok?


You're explicitly adding `-link-internally` in your top-level 
dub.sdl:


dflags "-link-internally" platform="linux-ldc" # use GNU gold 
linker


If you want to go with gold, as your comment suggests, you'd 
use `-linker=gold` instead. For more context wrt. 
`-link-internally` clumsiness on non-Windows, see 
https://github.com/ldc-developers/ldc/issues/2717.


Thanks! Is there usually only apps and not libs that are supposed 
to have linker flags like these?


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread kinke via Digitalmars-d-learn

On Thursday, 30 August 2018 at 19:41:38 UTC, Nordlöw wrote:

I'm using the tar.xz for x64 Linux. Ok?


You're explicitly adding `-link-internally` in your top-level 
dub.sdl:


dflags "-link-internally" platform="linux-ldc" # use GNU gold 
linker


If you want to go with gold, as your comment suggests, you'd use 
`-linker=gold` instead. For more context wrt. `-link-internally` 
clumsiness on non-Windows, see 
https://github.com/ldc-developers/ldc/issues/2717.


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 30 August 2018 at 16:12:24 UTC, kinke wrote:
Nope, I now think this is more likely an issue with the default 
config (etc/ldc2.conf). It contains a new section for 
WebAssembly, which specificies `-link-internally`, which seems 
to be wrongly used for non-WebAssembly too in your case.
I take it you're not using an official package, but a distro 
one?


My mistake, I was using dmd's dub (at /usr/bin/dub) instead of 
ldc's.


As I prefer to have both installed at the same time, does anybody 
have any good trick to prevent this from happening in the 
future...some clever bash alias for instance?


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread Nordlöw via Digitalmars-d-learn

On Thursday, 30 August 2018 at 16:12:24 UTC, kinke wrote:
Nope, I now think this is more likely an issue with the default 
config (etc/ldc2.conf). It contains a new section for 
WebAssembly, which specificies `-link-internally`, which seems 
to be wrongly used for non-WebAssembly too in your case.
I take it you're not using an official package, but a distro 
one?


I'm using the tar.xz for x64 Linux. Ok?


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread kinke via Digitalmars-d-learn
Nope, I now think this is more likely an issue with the default 
config (etc/ldc2.conf). It contains a new section for 
WebAssembly, which specificies `-link-internally`, which seems to 
be wrongly used for non-WebAssembly too in your case.

I take it you're not using an official package, but a distro one?


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread kinke via Digitalmars-d-learn

On Thursday, 30 August 2018 at 13:36:58 UTC, Per Nordlöw wrote:

[...]


LDC uses the C compiler as linker driver by default, exactly 
because the linker needs some setup (default lib dirs etc.). So 
this is almost certainly a dub issue.


Re: Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread Radu via Digitalmars-d-learn

On Thursday, 30 August 2018 at 13:36:58 UTC, Per Nordlöw wrote:

Recently the benchmark

https://github.com/nordlow/phobos-next/tree/master/benchmarks/containers/dub.sdl

[...]


There is a way to specify the linker to be used
```
-linker=   - Linker to use
```


Cannot make sense of LLD linker error with ldc 1.11.0

2018-08-30 Thread Per Nordlöw via Digitalmars-d-learn

Recently the benchmark

https://github.com/nordlow/phobos-next/tree/master/benchmarks/containers/dub.sdl

run as

dub run --compiler=ldc2 --build=release

has started to fail as

Performing "release" build using ldc2 for x86_64.
phobos-next ~master: target for configuration "library" is up to 
date.
benchmark-containers ~master: building configuration 
"application"...

lld: error: unknown argument: --no-warn-search-mismatch
lld: error: unable to find library -lzstd
lld: error: unable to find library -lz
lld: error: unable to find library -lbz2
lld: error: unable to find library -lrt
lld: error: unable to find library -ldl
lld: error: unable to find library -lpthread
lld: error: unable to find library -lm
Error: linking with LLD failed
ldc2 failed with exit code 1.
[

on latest stable ldc 1.11.0 on Ubuntu 18.04 x64.

Anybody got a clue what's wrong?

Is there a way to make use of the gold linker instead?


Re: Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-07-01 Thread Chris M. via Digitalmars-d-learn

On Sunday, 1 July 2018 at 01:16:59 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 00:42:30 spikespaz via 
Digitalmars-d-learn wrote:
Hey guys, I'm getting a linker error when compiling with DMD 
`-m63` that I don't get as 23 bit.


I'm importing `ShowWindow` from `core.sys.windows.winuser`, 
and I get the following:


C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: 
undefined

symbol: ShowWindow
error: link failed
Error: linker exited with status 1

My compiler command is `dmd main.d -m64 -i -O -release -inline
-boundscheck=off
`.

I don't think the source code would make a difference other 
than to say that I'm calling `ShowWindow`.


Any help would be much appreciated. Thanks!


Well, per the MSDN page, that symbol is in User32.lib, so make 
sure that you're linking against it - though why it would link 
against it with 32-bit and not 64-bit, I don't know.


- Jonathan M Davis


Check to make sure it's actually defined in user32.lib. I'm 
having a similar issue and would love to know why these functions 
are apparently not being defined


https://forum.dlang.org/thread/ncarbitntjeobljra...@forum.dlang.org


Re: Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-06-30 Thread Jonathan M Davis via Digitalmars-d-learn
On Sunday, July 01, 2018 00:42:30 spikespaz via Digitalmars-d-learn wrote:
> Hey guys, I'm getting a linker error when compiling with DMD
> `-m63` that I don't get as 23 bit.
>
> I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I
> get the following:
>
> C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined
> symbol: ShowWindow
> error: link failed
> Error: linker exited with status 1
>
> My compiler command is `dmd main.d -m64 -i -O -release -inline
> -boundscheck=off
> `.
>
> I don't think the source code would make a difference other than
> to say that I'm calling `ShowWindow`.
>
> Any help would be much appreciated. Thanks!

Well, per the MSDN page, that symbol is in User32.lib, so make sure that
you're linking against it - though why it would link against it with 32-bit
and not 64-bit, I don't know.

> Also, how does formatting work? Markdown doesn't seem to work, or
> HTML.

For the web forum you mean? It's just a web client for the newsgroups that
we use, and many folks interact with it as a newsgroup or via the mailing
list interface rather than through forum.dlang.org. So, it's expected that
everything will be in plain text.

- Jonathan M Davis



Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-06-30 Thread spikespaz via Digitalmars-d-learn
Hey guys, I'm getting a linker error when compiling with DMD 
`-m63` that I don't get as 23 bit.


I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I 
get the following:


C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined 
symbol: ShowWindow

error: link failed
Error: linker exited with status 1

My compiler command is `dmd main.d -m64 -i -O -release -inline 
-boundscheck=off

`.

I don't think the source code would make a difference other than 
to say that I'm calling `ShowWindow`.


Any help would be much appreciated. Thanks!

Also, how does formatting work? Markdown doesn't seem to work, or 
HTML.


Re: [vibe.d/dub] Linker error

2018-03-12 Thread Chris via Digitalmars-d-learn

On Friday, 9 March 2018 at 13:46:33 UTC, Chris wrote:

I got this error msg today (see below):

DUB version 1.8.0, built on Mar  3 2018
vibe.d version 0.8.3
dmd 2.078.3 (the same with 2.079.0 and 2.077.0)

.dub/build/server64_72_debug-debug-linux.posix-x86_64-dmd_2079-CAC4A12AC8FE4B4625A9511E4EFEB8F6/anscealai.o:
 In function 
`_D3std5range10primitives__T5doPutTSQBh6format__T11hasToStringTSQCj8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1STaZQDjFNaNbNiNfKQDpaZv':
/usr/include/dlang/dmd/std/range/primitives.d:269: undefined 
reference to 
`_D3std6format__T11hasToStringTSQBd8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1S3putMFNaNbNiNfaZv' [...and loads of other similar messages...]

collect2: error: ld returned 1 exit status
Error: linker exited with status 1
/usr/bin/dmd failed with exit code 1.

It is so massive that it must be something ridiculous.


Ok, I've solved it now with a fresh head on my. I had `dflags 
"-allinst"` in the dub.sdl file which was there due to an old bug 
in dmd, I think. Once I had removed it, the linking worked.


I knew it was something ridiculous.


[vibe.d/dub] Linker error

2018-03-09 Thread Chris via Digitalmars-d-learn

I got this error msg today (see below):

DUB version 1.8.0, built on Mar  3 2018
vibe.d version 0.8.3
dmd 2.078.3 (the same with 2.079.0 and 2.077.0)

.dub/build/server64_72_debug-debug-linux.posix-x86_64-dmd_2079-CAC4A12AC8FE4B4625A9511E4EFEB8F6/anscealai.o:
 In function 
`_D3std5range10primitives__T5doPutTSQBh6format__T11hasToStringTSQCj8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1STaZQDjFNaNbNiNfKQDpaZv':
/usr/include/dlang/dmd/std/range/primitives.d:269: undefined 
reference to 
`_D3std6format__T11hasToStringTSQBd8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1S3putMFNaNbNiNfaZv' [...and loads of other similar messages...]

collect2: error: ld returned 1 exit status
Error: linker exited with status 1
/usr/bin/dmd failed with exit code 1.

It is so massive that it must be something ridiculous.


Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 20:09:02 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter 
wrote:

On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter

[snip]

LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe


First one is BS, of course it must be:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x64\link.exe


Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=18098



Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter 
wrote:

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini 
and VCINSTALLDIR is properly detected. Any idea what still 
might go wrong?


Think I figured it out. For me it works when changing that 
particular line to:


LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe


First one is BS, of course it must be:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x64\link.exe




Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter wrote:

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini 
and VCINSTALLDIR is properly detected. Any idea what still 
might go wrong?


Think I figured it out. For me it works when changing that 
particular line to:


LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe


Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini and 
VCINSTALLDIR is properly detected. Any idea what still might go 
wrong?





Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread John via Digitalmars-d-learn

On Sunday, 17 December 2017 at 17:15:57 UTC, ParticlePeter wrote:

On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:

Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe


Thanks! Is this a known, reported bug?


I don't think so, all that would need to be changed is this line:

https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:

Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe


Thanks! Is this a known, reported bug?


Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread John via Digitalmars-d-learn

On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile 
a mixed c++/d project (DMD links to one c++ lib). Here is the 
full error message:


fatal error C1905: Front end and back end not compatible (must 
target same processor).

LINK : fatal error LNK1257: code generation failed
Error: linker exited with status 1257
dmd failed with exit code 1257.

No such problems with my previous DMD version.

What has changed with linking since then? (Skimmed through 
changelogs but found nothing).


I found a workaround with specifying LINKCMD64 to my VS 2017 
linker, but this is not a viable solution. The project must 
build with DMD on any system with VS installed without me 
knowing its exact location.


What can I do to make it run out of the box and without the 
link command specified?


Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe


Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn

On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile 
a mixed c++/d project (DMD links to one c++ lib). Here is the 
full error message:


Forgot most important info, ita an x64 project those used VS 
linker by default afaik.


Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

2017-12-17 Thread ParticlePeter via Digitalmars-d-learn
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile a 
mixed c++/d project (DMD links to one c++ lib). Here is the full 
error message:


fatal error C1905: Front end and back end not compatible (must 
target same processor).

LINK : fatal error LNK1257: code generation failed
Error: linker exited with status 1257
dmd failed with exit code 1257.

No such problems with my previous DMD version.

What has changed with linking since then? (Skimmed through 
changelogs but found nothing).


I found a workaround with specifying LINKCMD64 to my VS 2017 
linker, but this is not a viable solution. The project must build 
with DMD on any system with VS installed without me knowing its 
exact location.


What can I do to make it run out of the box and without the link 
command specified?





Re: My DMD ~master build gives linker error and IDK why

2017-06-07 Thread Basile B. via Digitalmars-d-learn

On Wednesday, 7 June 2017 at 09:55:24 UTC, Basile B. wrote:

On Wednesday, 7 June 2017 at 09:50:41 UTC, Basile B. wrote:

bla bla bla


Actually it's this code:

void main(string[] args)
{
import std.stdio;
import std.compiler;
writeln(vendor);
}

that gives the error. I suspect a regression.


Pass your way, you cannot help. Eventually you can verify that 
you're also affected.


https://issues.dlang.org/show_bug.cgi?id=17475




Re: My DMD ~master build gives linker error and IDK why

2017-06-07 Thread Basile B. via Digitalmars-d-learn

On Wednesday, 7 June 2017 at 09:50:41 UTC, Basile B. wrote:

bla bla bla


Actually it's this code:

void main(string[] args)
{
import std.stdio;
import std.compiler;
writeln(vendor);
}

that gives the error. I suspect a regression.


My DMD ~master build gives linker error and IDK why

2017-06-07 Thread Basile B. via Digitalmars-d-learn

This is my script:


HOST_DMD=dmd
MODEL=64
cd dmd
make -fposix.mak MODEL=64 clean
make -fposix.mak ENABLE_RELEASE=1 MODEL=64 DMD=../dmd/src/dmd -j 5
cd ../druntime
make -fposix.mak MODEL=64 clean
make -fposix.mak MODEL=64 DMD=../dmd/src/dmd -j 5
cd ../phobos
make -fposix.mak MODEL=64 clean
make -fposix.mak MODEL=64 DMD=../dmd/src/dmd -j 5

cd ..
cp dmd/generated/linux/release/64/dmd bin-master/
cp phobos/generated/linux/release/64/libphobos2.a bin-master/libs/


When i compile a simple module with a main function and std.stdio 
as import i get:



/tmp/temp_7F12E3A4FF10.o : Dans la fonction « @safe void 
std.format.formatUnsigned!(std.stdio.File.LockingTextWriter, 
ulong, char).formatUnsigned(std.stdio.File.LockingTextWriter, 
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, 
bool) » :
/tmp/temp_7F12E3A4FF10.d:(.text.@safe void 
std.format.formatUnsigned!(std.stdio.File.LockingTextWriter, 
ulong, char).formatUnsigned(std.stdio.File.LockingTextWriter, 
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, 
bool)[@safe void 
std.format.formatUnsigned!(std.stdio.File.LockingTextWriter, 
ulong, char).formatUnsigned(std.stdio.File.LockingTextWriter, 
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, 
bool)]+0x312) : référence indéfinie vers « const(pure 
nothrow @property @nogc @safe bool function()) 
std.format.FormatSpec!(char).FormatSpec.flSeparator »
/tmp/temp_7F12E3A4FF10.d:(.text.@safe void 
std.format.formatUnsigned!(std.stdio.File.LockingTextWriter, 
ulong, char).formatUnsigned(std.stdio.File.LockingTextWriter, 
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, 
bool)[@safe void 
std.format.formatUnsigned!(std.stdio.File.LockingTextWriter, 
ulong, char).formatUnsigned(std.stdio.File.LockingTextWriter, 
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, 
bool)]+0x436) : référence indéfinie vers « const(pure 
nothrow @property @nogc @safe bool function()) 
std.format.FormatSpec!(char).FormatSpec.flSeparator »
/tmp/temp_7F12E3A4FF10.o : Dans la fonction « pure @safe void 
std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool) » :
/tmp/temp_7F12E3A4FF10.d:(.text.pure @safe void 
std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool)[pure @safe void std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool)]+0x316) : référence indéfinie vers « const(pure nothrow @property @nogc @safe bool function()) std.format.FormatSpec!(char).FormatSpec.flSeparator »
/tmp/temp_7F12E3A4FF10.d:(.text.pure @safe void 
std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool)[pure @safe void std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool)]+0x43a) : référence indéfinie vers « const(pure nothrow @property @nogc @safe bool function()) std.format.FormatSpec!(char).FormatSpec.flSeparator »

collect2: error: ld returned 1 exit status
Error: linker exited with status 1


But this used to work fine, this for months and months even 
recently i've cast a session where i build DMD master to show 
something about my IDE.


Re: ModuleInfo linker error when importing std.stdio and using package.d

2016-11-08 Thread Daniel Kozak via Digitalmars-d-learn

Dne 8.11.2016 v 21:16 Bryce Kellogg via Digitalmars-d-learn napsal(a):


...
Finally, a one line package.d:

public import my_package.my_module;


Change it to:

module my_package;
public import my_package.my_module;

Btw, having class name same as module name is not best way, there could 
be some issues with that


ModuleInfo linker error when importing std.stdio and using package.d

2016-11-08 Thread Bryce Kellogg via Digitalmars-d-learn
Hi everyone, I'm new to D, and I'm trying to get a handle on the 
correct way to use packages, modules, and importing things. I 
created a simple example, but I'm getting linker errors in weird 
situations. I'm hoping to get some insight into why the error is 
happening and best practices in these sorts of situations.


I've got a simple project set up as follows:
.
├── dub.json
└── source/
├── app.d
└── my_package/
├── my_module.d
└── package.d


The contents of dub.json are pretty simple:


{
"name": "my_package_test",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, kellogg",
"authors": ["kellogg"],
"dependencies": {
}
}


In app.d, all I do is import my package and instantiate my class.

import my_package;
void main() {
my_module m = new my_module();
}


And here's my_module.d

module my_package.my_module;
import std.stdio;
class my_module {
this() {
writeln("Hello World!");
}
}



Finally, a one line package.d:

public import my_package.my_module;


Building this via dub results in the error:

.dub/obj/app.o:(.data._D3app12__ModuleInfoZ[_D3app12__ModuleInfoZ]+0x10): 
undefined reference to `_D10my_package12__ModuleInfoZ'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
ldc2 failed with exit code 1.


Interestingly, if I remove the 'import std.stdio;' and writeln() 
from my_module.d, it compiles fine. It also works if I move the 
import down to inside the constructor, or replace the import in 
app.d with 'import my_package.my_module;' (side stepping the 
package.d).



To summarize: importing my package via package.d results in a 
linker error if I import std.stdio at the top level in my module. 
I'm wondering: what does this error mean, what does it have to do 
with std.stdio, and am I even using package.d correctly?


Thanks!


Re: Linker error

2016-06-10 Thread Chris via Digitalmars-d-learn
On Friday, 10 June 2016 at 13:17:32 UTC, Steven Schveighoffer 
wrote:

On 6/10/16 8:04 AM, Chris wrote:

I get the error below with code like this:

auto res = ['1', '2'].map!(a => a.to!string);

dmd 2.071.0

What's wrong here? I import std.algorithm, std.range, 
std.array,

std.conv in the module.

(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
undefined reference to
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'

collect2: error: ld returned 1 exit status


This linker error is saying it can't find a required typeinfo 
initializer for std.range.interfaces.InputRange (of some type, 
not an expert in demangling D symbols).


Generally this happens when you compile against a third-party 
library file but don't link to it (I think that type of symbol 
is stored in the module info).


Your posted code has nothing to do with this, so I'm not sure 
this is the exact line you are having trouble with. Your posted 
map line should not be invoking this error at all.


Have you tried Vladimir's DustMite tool? It can automatically 
whittle down your code into a minimal test case.


https://github.com/CyberShadow/DustMite/wiki

-Steve


I've got it now. I remembered that it is to do with passing 
-allinst to the compiler.


You're right, it's not `map!` as such. It's the template 
instantiation. However, the problem only appeared when I started 
to use `map!`


Re: Linker error

2016-06-10 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/10/16 8:04 AM, Chris wrote:

I get the error below with code like this:

auto res = ['1', '2'].map!(a => a.to!string);

dmd 2.071.0

What's wrong here? I import std.algorithm, std.range, std.array,
std.conv in the module.

(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
undefined reference to
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'

collect2: error: ld returned 1 exit status


This linker error is saying it can't find a required typeinfo 
initializer for std.range.interfaces.InputRange (of some type, not an 
expert in demangling D symbols).


Generally this happens when you compile against a third-party library 
file but don't link to it (I think that type of symbol is stored in the 
module info).


Your posted code has nothing to do with this, so I'm not sure this is 
the exact line you are having trouble with. Your posted map line should 
not be invoking this error at all.


Have you tried Vladimir's DustMite tool? It can automatically whittle 
down your code into a minimal test case.


https://github.com/CyberShadow/DustMite/wiki

-Steve


Re: Linker error

2016-06-10 Thread ketmar via Digitalmars-d-learn

On Friday, 10 June 2016 at 13:04:32 UTC, Chris wrote:

It doesn't compile with

`dmd file1.d file2.d`

either. I'll have to look into this. Weird.


looks like a clear sign of dmd versions conflict. most of the 
time things like that caused by some leftover from previous dmd — 
like old libphobos.a lying somewhere in link path, or alike. try 
to get link command from "dmd -v", and supply it with explicit 
path to correct libphobos to check if there is really something 
interferring.


Re: Linker error

2016-06-10 Thread ketmar via Digitalmars-d-learn

On Friday, 10 June 2016 at 12:52:05 UTC, Chris wrote:

I use dub and `dvm use 2.071.0`.


hm. sorry, i can't help you with this. straight "dmd test.d" is 
ok, so it's probably something with dub/dvm interaction...


Re: Linker error

2016-06-10 Thread Chris via Digitalmars-d-learn

On Friday, 10 June 2016 at 13:00:23 UTC, ketmar wrote:

On Friday, 10 June 2016 at 12:52:05 UTC, Chris wrote:

I use dub and `dvm use 2.071.0`.


hm. sorry, i can't help you with this. straight "dmd test.d" is 
ok, so it's probably something with dub/dvm interaction...


It doesn't compile with

`dmd file1.d file2.d`

either. I'll have to look into this. Weird.


Re: Linker error

2016-06-10 Thread Chris via Digitalmars-d-learn

On Friday, 10 June 2016 at 12:12:17 UTC, ketmar wrote:

On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote:

I get the error below with code like this:

auto res = ['1', '2'].map!(a => a.to!string);

dmd 2.071.0

What's wrong here? I import std.algorithm, std.range, 
std.array, std.conv in the module.


(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status


post the whole code and command line, please.

it looks like you doing separate compilation, and forgot to put 
something to command line, or there is some conflict between 
installed compiler versions (for example, dmd and ldc, and one 
somehow is trying to use libphobos from another).


The whole code would be too much.

This, however compiles and links perfectly well:
`
import std.algorithm;
import std.conv : to;

void main()
{
  auto res = [1, 2, 3].map!(a => a.to!string);
}
`

I use dub and `dvm use 2.071.0`. The code compiled perfectly well 
until I used `map!` I have no clue what causes it. I even used 
`dub clean`


Re: Linker error

2016-06-10 Thread ketmar via Digitalmars-d-learn

On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote:

I get the error below with code like this:

auto res = ['1', '2'].map!(a => a.to!string);

dmd 2.071.0

What's wrong here? I import std.algorithm, std.range, 
std.array, std.conv in the module.


(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status


post the whole code and command line, please.

it looks like you doing separate compilation, and forgot to put 
something to command line, or there is some conflict between 
installed compiler versions (for example, dmd and ldc, and one 
somehow is trying to use libphobos from another).


Linker error

2016-06-10 Thread Chris via Digitalmars-d-learn

I get the error below with code like this:

auto res = ['1', '2'].map!(a => a.to!string);

dmd 2.071.0

What's wrong here? I import std.algorithm, std.range, std.array, 
std.conv in the module.


(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Monday, 6 June 2016 at 02:21:03 UTC, docandrew wrote:

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:

[...]


You can report it here: https://issues.dlang.org


[...]


null is simpler from a reader's perspective. :)


[...]


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it 
should definitely be reported as a bug.


-Jon


https://issues.dlang.org/show_bug.cgi?id=16129


Re: Linker error

2016-06-05 Thread docandrew via Digitalmars-d-learn

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it should 
definitely be reported as a bug.


-Jon


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


Re: Linker error

2016-06-05 Thread Andrej Mitrovic via Digitalmars-d-learn
On 6/5/16, Anonymous via Digitalmars-d-learn
 wrote:
> Should I report this as a dmd bug then? Not sure where / how to
> do that.

You can report it here: https://issues.dlang.org

> I think I'll just let it go; I was able to work passed it anyway
> using "static Note[] empty;", and `null` works too. Is either one
> better?

null is simpler from a reader's perspective. :)

> By the way, this is from an example I found in "D Web
> Development" by Kai Nacke.

Interesting that they would use such code in the book. Which chapter is it?


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 20:16:54 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}


It's likely an accepts-invalid bug, meaning it should be a 
compiler error instead. I don't think it makes sense that the 
compiler tries to slice a fixed-length array of length zero.. 
tho perhaps it should just equate that to returning null.


In any case you can return `null` instead of "empty". 
Fixed-length arrays of length zero aren't really all that 
well-defined. Some would say they make no sense, but there is a 
weird benefit to them when used with the built-in hashmaps (a 
void[0] value type wouldn't allocate memory, AFAIR and if that 
is still true).


Should I report this as a dmd bug then? Not sure where / how to 
do that.


I think I'll just let it go; I was able to work passed it anyway 
using "static Note[] empty;", and `null` works too. Is either one 
better?


By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Re: Linker error

2016-06-05 Thread Andrej Mitrovic via Digitalmars-d-learn
On 6/5/16, Anonymous via Digitalmars-d-learn
 wrote:
>   static Note[0] empty;
>   
>   Note[] getNotes(string id)
>   {
>   return (id in store) ? store[id] : empty;
>   }   

It's likely an accepts-invalid bug, meaning it should be a compiler
error instead. I don't think it makes sense that the compiler tries to
slice a fixed-length array of length zero.. tho perhaps it should just
equate that to returning null.

In any case you can return `null` instead of "empty". Fixed-length
arrays of length zero aren't really all that well-defined. Some would
say they make no sense, but there is a weird benefit to them when used
with the built-in hashmaps (a void[0] value type wouldn't allocate
memory, AFAIR and if that is still true).


  1   2   3   >