Comment #0 by john.loughran.colvin — 2015-09-16T09:51:26Z
by default, OS X uses case-insensitive-but-case-preserving HFS+ and this is what almost all OS X users will have.
consider the following (incorrect) code:
% cat chirplet.d
import mathutil;
auto chirplet()
{
exp(0);
}
% cat mathUtil.d
auto expi(double )
{
}
auto exp(T)(T c)
{
expi(c);
}
% dmd chirplet.d mathUtil.d -main
Undefined symbols for architecture x86_64:
"_D8mathutil4expiFNaNbNiNfdZv", referenced from:
_D8mathutil10__T3expTiZ3expFNaNbNiNfiZv in chirplet.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--- errorlevel 1
What I think is happening:
While compiling chirplet.d, dmd sees `import mathutil;` and asks the filesystem for a file called `mathutil.d` in the current directory. HFS+ provides `mathUtil.d` because it doesn't know any better. dmd continues compiling and emits references to `mathutil` symbols. dmd compiles `mathUtil.d` and emits `mathUtil` symbols. Linker sees the case mismatch and fails.
Comment #1 by dfj1esp02 — 2015-09-16T12:58:28Z
From spec:
---
By convention, package and module names are all lower case. This is because those names can have a one-to-one correspondence with the operating system's directory and file names, and many file systems are not case sensitive. All lower case package and module names will minimize problems moving projects between dissimilar file systems.
---
Also D is case sensitive, so you can't change identifier case and expect it to work.
Comment #2 by john.loughran.colvin — 2015-09-16T13:00:23Z
(In reply to Sobirari Muhomori from comment #1)
> From spec:
> ---
> By convention, package and module names are all lower case. This is because
> those names can have a one-to-one correspondence with the operating system's
> directory and file names, and many file systems are not case sensitive. All
> lower case package and module names will minimize problems moving projects
> between dissimilar file systems.
> ---
>
> Also D is case sensitive, so you can't change identifier case and expect it
> to work.
I don't expect it to work, but I do expect it to fail with a clear error message before link-time.
Comment #3 by dfj1esp02 — 2015-09-17T12:04:19Z
dmd chirplet.d mathutil.d -main
Does this work (lower case)?
Comment #4 by john.loughran.colvin — 2015-09-17T12:24:57Z
(In reply to Sobirari Muhomori from comment #3)
> dmd chirplet.d mathutil.d -main
>
> Does this work (lower case)?
Yes.
Comment #5 by dfj1esp02 — 2015-09-18T08:46:24Z
So whether it works or not depends on how you invoke the compiler and not on the file name.
Comment #6 by ag0aep6g — 2015-09-18T19:17:19Z
(In reply to John Colvin from comment #2)
> I don't expect it to work, but I do expect it to fail with a clear error
> message before link-time.
Do you have a suggestion on how that should be realized?
Module chirplet asks for module mathutil, so the compiler gets it. Then a different module mathUtil is compiled as is requested on the command line. Module mathutil has never been compiled and is missing when linking.
I see one way to catch this earlier: dmd could require lower-case file names and/or module names. But I'm not sure if this issue is worth the disruption that would cause. Personally, I wouldn't mind it, though.
Comment #7 by steve.biedermann.privat — 2016-09-12T07:34:36Z
The same issue occurs on windows.
If you misstype the import, you get link errors instead of dmd import errors.
e.g.:
main.d:
import Bug;
void main()
{
Bug b = new Bug();
b.print("test");
}
bug.d:
import std.stdio;
public class Bug {
void print(string str) {
writeln(str);
}
}
compiled with:
dmd main.d
output:
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
main.obj(main)
Error 42: Symbol Undefined _D3Bug3Bug7__ClassZ
main.obj(main)
Error 42: Symbol Undefined _D3Bug12__ModuleInfoZ
--- errorlevel 2
Comment #8 by ag0aep6g — 2016-09-12T07:44:49Z
(In reply to Steve Biedermann from comment #7)
> main.d:
> import Bug;
[...]
> bug.d:
[...]
> compiled with:
> dmd main.d
You have to compile with `dmd main.d bug.d` to see the issue. With just `dmd main.d`, you get a linker error regardless of case sensitivity.
Comment #9 by steve.biedermann.privat — 2016-09-12T08:09:24Z
I see.
Thanks for the clarification.
But then maybe there is something wrong with the file lookup from dub. (Wrong case = link error, correct case = success)
I just tried to compile with rdmd and it seems that rdmd also correctly resolves the file, regardless of the case.
I also tried to specify the -I command line switch for dmd, but it's the same as without (link errors).
Comment #10 by ag0aep6g — 2016-09-12T08:21:46Z
(In reply to Steve Biedermann from comment #9)
> But then maybe there is something wrong with the file lookup from dub.
> (Wrong case = link error, correct case = success)
I don't know how dub works exactly, but if it fails, it probably generates the command line from file names. I.e., it runs `dmd main.d bug.d` and then it hits the issue at hand.
> I just tried to compile with rdmd and it seems that rdmd also correctly
> resolves the file, regardless of the case.
rdmd generates the command line arguments from the imports. So from main.d and the `import Bug;` in there, rdmd makes `dmd main.d Bug.d`. Case of the import matches case on the command line, so it works.
> I also tried to specify the -I command line switch for dmd, but it's the
> same as without (link errors).
-I isn't related to this. There's always an implicit `-I.`. dmd needs all source files (or object files) on the command line. It doesn't automatically compile imported modules.
If you need further clarification, please make a thread in the Learn group. Let's not hijack this issue discussion. http://forum.dlang.org/group/learn
Comment #11 by robert.schadek — 2024-12-13T18:44:46Z