It would be nice if, when symbols are missing, they are unmangled!

Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go()

I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living.

On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote:
> It would be nice if, when symbols are missing, they are unmangled!
>
> Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go()

Since that's a linker error and there are a multitude of linkers that a person could want to use after a D compiler this is a non-trivial issue in general.
Options to tackle this include:
1) Have a D compiler capture the linker output and demangle it
2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.)
3) Integrate a (FLOSS) cross platform linker into dmd's backend at the source code level, with support for such demangling (and drop OPTLINK)
4) Fork a (FLOSS) cross platform linker for use with D, add such support, and distribute a binary of it with dmd's binary distribution (and drop OPTLINK)

I'm not proposing any of these are what should be done, I've listed them more as an example that something like this would require extensive discussion.

[1] https://github.com/ldc-developers/ldc/releases/tag/v1.3.0

On Wednesday, 30 August 2017 at 21:51:51 UTC, Moritz Maxeiner wrote:
> On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote:
>> It would be nice if, when symbols are missing, they are unmangled!
>>
>> Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go()
>
> Since that's a linker error and there are a multitude of linkers that a person could want to use after a D compiler this is a non-trivial issue in general.
> Options to tackle this include:
> 1) Have a D compiler capture the linker output and demangle it
> 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.)
> 3) Integrate a (FLOSS) cross platform linker into dmd's backend at the source code level, with support for such demangling (and drop OPTLINK)
> 4) Fork a (FLOSS) cross platform linker for use with D, add such support, and distribute a binary of it with dmd's binary distribution (and drop OPTLINK)
>
> I'm not proposing any of these are what should be done, I've listed them more as an example that something like this would require extensive discussion.
>
> [1] https://github.com/ldc-developers/ldc/releases/tag/v1.3.0


A simple wrapper around optilink could possible do this? Not well, but it might be enough?

Obviously optilink is the source of the problem.

How hard is it to take a string like the above and demangle it in to a readable format? If there is such a funciton in the D compiler, a simple wrapper could be used to parse the output, capture symbol errors, and demangle them.

My feeling is that optilink needs to be put to rest. Things die, let them... move on to greener pastures.

On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote:
> It would be nice if, when symbols are missing, they are unmangled!
>
> Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go()
>
> I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living.

Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()"

Is this not the missing symbol?

I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd.

bye,
lobo

On Wednesday, 30 August 2017 at 22:07:29 UTC, lobo wrote:
> On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote:
>> It would be nice if, when symbols are missing, they are unmangled!
>>
>> Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go()
>>
>> I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living.
>
> Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()"
>
> Is this not the missing symbol?
>
> I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd.
>
> bye,
> lobo

It might be the same. If that is the case then it would be nice if it didn't display the junk that gets in the way(e.g., add a switch).

I don't want to have to hunk and peck for stuff(even if it's nearly obvious in some cases). In VisualD, the mangled crap is on a long line that I have to scroll, which is time consuming. Even if wrap is on it still isn't pretty. I mean, if the logic is "It shows the information" then why not just display it directly in binary and let the end user convert it in their head. If they are too stupid to do so then create an online demangler site and a few college classes to teach them how. At some point it becomes ridiculous. Technology is suppose to make our lives easier, not harder. Usually these things are left the way they are until someone gets tired of it and fixes it, it's not that it can't be done, it's that no one seems to care(or it would have been done or the time is now).

On Wednesday, 30 August 2017 at 22:21:52 UTC, Johnson wrote:
> On Wednesday, 30 August 2017 at 22:07:29 UTC, lobo wrote:
>> On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote:
>>> [...]
>>
>> Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()"
>>
>> Is this not the missing symbol?
>>
>> I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd.
>>
>> bye,
>> lobo
>
> It might be the same. If that is the case then it would be nice if it didn't display the junk that gets in the way(e.g., add a switch).
>
> I don't want to have to hunk and peck for stuff(even if it's nearly obvious in some cases). In VisualD, the mangled crap is on a long line that I have to scroll, which is time consuming. Even if wrap is on it still isn't pretty. I mean, if the logic is "It shows the information" then why not just display it directly in binary and let the end user convert it in their head. If they are too stupid to do so then create an online demangler site and a few college classes to teach them how. At some point it becomes ridiculous. Technology is suppose to make our lives easier, not harder. Usually these things are left the way they are until someone gets tired of it and fixes it, it's not that it can't be done, it's that no one seems to care(or it would have been done or the time is now).

Dunno about VisualD, never used it. I'm using Vim and have it piping the output through ddemangle automatically so mangled names are not an issue. I'd assume VisualD can do the same.

Sounds like you might be that someone who got tired of it and cares enough to implement the necessary pull request.

On 30-08-17 23:51, Moritz Maxeiner wrote:
> 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.)

The GNU linker and gold support demangling D symbols, so if you are on linux try adding `-L--demangle=dlang` to the dmd commandline.

-- 
Mike Wey

On Thursday, 31 August 2017 at 14:51:59 UTC, Mike Wey wrote:
> On 30-08-17 23:51, Moritz Maxeiner wrote:
>> 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.)
>
> The GNU linker and gold support demangling D symbols, so if you are on linux try adding `-L--demangle=dlang` to the dmd commandline.

Neat, thanks!