On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
> Please post bug reports to bugzilla.

Here you go: https://issues.dlang.org/show_bug.cgi?id=17077

On Sunday, 8 January 2017 at 20:36:38 UTC, jkpl wrote:
> On Sunday, 8 January 2017 at 19:15:49 UTC, Jerry wrote:
>> On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
>>> P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?
>>
>> A bit more maddening that D is still trying to support optlink, a linker that hasn't seen a commit in 2 years when it is hardly bug free.
>
> Your comment is not pertinent. The object format doesn't change so the linker doesn't need to be updated. The problem here seems to be a bug. Until someone finds it, it can't be fixed.

We are discussing Optlink and a bug related to it. The fact it's 20 years old, written in assembly, and hasn't had a bug fix in years even though they have been reported is very very very much relevant. It's legacy software that shouldn't be relied on unless you also consider D to be legacy (I think most probably won't).

On 1/8/2017 10:56 AM, jkpl wrote:
> On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
>> P.S. Isn't it maddening that Windows doesn't allow copying the data from a
>> message window?
>
> Not really, because you can, Ctrl+C...

That frequently does not work. For example, take the "Help" window of Thunderbird, which is my email program. You cannot copy data from it.

On Sunday, 8 January 2017 at 19:15:49 UTC, Jerry wrote:
> A bit more maddening that D is still trying to support optlink, a linker that
> hasn't seen a commit in 2 years when it is hardly bug free.


Optlink has had many bugs fixed in it. There are currently 7 open issues with it on bugzilla:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=dmd&list_id=212971&query_format=advanced&short_desc=optlink&short_desc_type=allwordssubstr

This includes the issue in this thread. Only 1 of the other issues looks like a bug in Optlink.

If you know of unreported issues with Optlink, please report them to bugzilla.

On 1/8/2017 12:58 PM, pineapple wrote:
> On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
>> Please post bug reports to bugzilla.
>
> Here you go: https://issues.dlang.org/show_bug.cgi?id=17077

Thank you.

On Monday, 9 January 2017 at 01:26:48 UTC, Walter Bright wrote:
> On Sunday, 8 January 2017 at 19:15:49 UTC, Jerry wrote:
>> A bit more maddening that D is still trying to support optlink, a linker that
>> hasn't seen a commit in 2 years when it is hardly bug free.
>
>
> Optlink has had many bugs fixed in it. There are currently 7 open issues with it on bugzilla:
>
> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=dmd&list_id=212971&query_format=advanced&short_desc=optlink&short_desc_type=allwordssubstr
>
> This includes the issue in this thread. Only 1 of the other issues looks like a bug in Optlink.

There's more, just the bugs are so obscure the people filing the bugs don't know that the problem lies with Optlink. There's problems with shared libraries not being loaded and unloaded properly. Random crashes during runtime, more often crashes when a debugger is attached. Some more that I ran into as well before I switched away from optlink. What point is there to report these bugs though, Microsoft's linker works with fewer bugs and actually supports the format of the platform. So no need to convert .lib files with it. This is my point, it's just one more thing that has to be maintained, but it's not even being maintained. Supporting MinGW would be a better option as then you don't have to maintain the linker and not have it degrade over time.

> If you know of unreported issues with Optlink, please report them to bugzilla.

To what end? There isn't even an Optlink specific bug list. Look at the bug with Optlink related to data that has more than 16 MB. What happened with that? Was that known bug fixed? No, a limitation was introduced into DMD to accommodate Optlink's bug. Rather than doing the sane decision to fix the bug in Optlink. Why? Probably because no one wants to deal with assembly.

On Monday, 9 January 2017 at 02:34:31 UTC, Jerry wrote:
> before I switched away from optlink. What point is there to report these bugs though, Microsoft's linker works with fewer bugs and actually supports the format of the platform. So no need to convert .lib files with it. This is my point, it's just one more thing that has to be maintained, but it's not even being maintained. Supporting MinGW would be a better option as then you don't have to maintain the linker and not have it degrade over time.

On this subject, I spent a good chunk of my day trying to compile my code using the -m32mscoff switch and was never able to get it to work. (My most recent obstacle is this error, occurring even for a very simple test program importing no dependencies, if anyone cares to take a look: https://hastebin.com/vezojehaxo.txt)

On Monday, 9 January 2017 at 01:27:27 UTC, Walter Bright wrote:
> On 1/8/2017 12:58 PM, pineapple wrote:
>> On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
>>> Please post bug reports to bugzilla.
>>
>> Here you go: https://issues.dlang.org/show_bug.cgi?id=17077
>
> Thank you.

Regarding the above: Because I have not managed to get an alternative to optlink working, I currently am unable to work on mach on my Windows desktop. In order to keep up progress I've been having to write and compile code on OSX on a laptop; it is nowhere near an ideal workflow. I understand you likely have a lot on your plate, but please prioritize solving this problem. It's causing me a great deal of irritation and inconvenience, and it's embarrassing that my library now simply won't compile on Windows.

On 1/8/2017 6:34 PM, Jerry wrote:
> There's more, just the bugs are so obscure the people filing the bugs don't know
> that the problem lies with Optlink. There's problems with shared libraries not
> being loaded and unloaded properly. Random crashes during runtime, more often
> crashes when a debugger is attached. Some more that I ran into as well before I
> switched away from optlink. What point is there to report these bugs though,

If you don't report bugs, they are guaranteed to not get fixed. There's nothing anyone can do with the statement you made.


>> If you know of unreported issues with Optlink, please report them to bugzilla.
> To what end?

Complaining that somebody didn't fix problems neither you nor anyone else reported is not very sporting.


> There isn't even an Optlink specific bug list.

I found the list I posted by searching bugzilla for "optlink". If there are any I missed, please let me know.

On 1/8/2017 8:24 PM, pineapple wrote:
> On this subject, I spent a good chunk of my day trying to compile my code using
> the -m32mscoff switch and was never able to get it to work. (My most recent
> obstacle is this error, occurring even for a very simple test program importing
> no dependencies, if anyone cares to take a look:
> https://hastebin.com/vezojehaxo.txt)

Please post bug reports to bugzilla, not pastebins.


> Regarding the above: Because I have not managed to get an alternative to optlink
> working, I currently am unable to work on mach on my Windows desktop. In order
> to keep up progress I've been having to write and compile code on OSX on a
> laptop; it is nowhere near an ideal workflow. I understand you likely have a lot
> on your plate, but please prioritize solving this problem. It's causing me a
> great deal of irritation and inconvenience, and it's embarrassing that my
> library now simply won't compile on Windows.

You could try compiling it with -m64.

On 01/09/2017 08:05 AM, Walter Bright wrote:
> I found the list I posted by searching bugzilla for "optlink". If there
> are any I missed, please let me know.

snn.lib is closely related to optlink, because COFF tools have no business with snn.lib.

https://issues.dlang.org/buglist.cgi?quicksearch=snn