www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - OPTLINK : Warning 9: Unknown Option : OUT

reply Anonymouse <zorael gmail.com> writes:
I wanted to try out druntime + a specific pull request with 
digger on Windows, and dmd and everything builds, except my 
program itself fails to link when compiled with it.

$ dub test 
--compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe
[...]
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
.dub\build\unittest-unittest-windows-x86_64-dmd_2087-54F51FF76286807F6977B498D
D6593D\kameloso.obj Offset 00000H Record Type 0064
  Error 138: Module or Dictionary corrupt
Error: linker exited with status 1
C:/cygwin/home/zorael/work/result/bin/dmd.exe failed with exit 
code 1.

If I run it from a Cygwin terminal and I comment the LINKCMD 
entry from the sc.ini by the digger dmd.exe, it defaults to its 
/usr/bin/link, which throws a similar error.

[...]
Linking...
/usr/bin/link: extra operand 
‘/OUT:.dub\\build\\unittest-unittest-windows-x86_64-dmd_2087-54F51FF76286807F6977B498DED6593D\\kameloso.exe’
Try '/usr/bin/link --help' for more information.
Error: linker exited with status 1
C:/cygwin/home/zorael/work/result/bin/dmd.exe failed with exit 
code 1.

The normally-installed dmd 2.087 works fine. What am I missing?
Jul 15 2019
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 15 July 2019 at 10:27:49 UTC, Anonymouse wrote:

 OPTLINK : Warning 9: Unknown Option : OUT


It looks like it's trying to use MS link command-line syntax with 
DM OPTLINK.

I'm not sure why that would happen, as Digger creates a complete 
sc.ini file containing full paths to all relevant linkers 
(OPTLINK, and 32-bit / 64-bit MS link). Perhaps Dub or the CygWin 
environment is interfering somehow?

Could you please post the following:

- The Digger command-line and digger.ini you used to build D
- The contents of ...\Digger\work\result\bin\sc.ini
- Also if you could please run the Dub command with -v, and post 
the full dmd.exe command line that Dub generates and runs.
Jul 15 2019
parent reply Anonymouse <zorael gmail.com> writes:
On Monday, 15 July 2019 at 11:12:41 UTC, Vladimir Panteleev wrote:

 On Monday, 15 July 2019 at 10:27:49 UTC, Anonymouse wrote:

 OPTLINK : Warning 9: Unknown Option : OUT


 It looks like it's trying to use MS link command-line syntax 
 with DM OPTLINK.

 I'm not sure why that would happen, as Digger creates a 
 complete sc.ini file containing full paths to all relevant 
 linkers (OPTLINK, and 32-bit / 64-bit MS link). Perhaps Dub or 
 the CygWin environment is interfering somehow?

 Could you please post the following:

 - The Digger command-line and digger.ini you used to build D
 - The contents of ...\Digger\work\result\bin\sc.ini
 - Also if you could please run the Dub command with -v, and 
 post the full dmd.exe command line that Dub generates and runs.


I built it with:

 dub fetch digger



I have not touched any digger.ini. The only one I can find is 
digger.ini.sample.

sc.ini and dub output at:

 https://pastebin.com/jPnh4yEA


dub test was invoked with:

 dub test 
 --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v


I seem to get the same errors from a Cygwin terminal as from a 
cmd one.
Jul 15 2019
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:




 sc.ini and dub output at:

 https://pastebin.com/jPnh4yEA




By default Digger builds D for 32-bit only. However, it looks 
like Dub is trying to build your code targeting the 64-bit model, 
whether due to a setting in your project's dub.json, or something 
else like dub.exe being a 64-bit executable.

If you'd like to build 64-bit versions of your project, then 
specify `--model=64` (or `--model=32,64`, or even 
`--model=32,64,32mscoff`) when building D with Digger. Otherwise, 
you should tell Dub to target the 32-bit model, or figure out why 
Dub is configured to or defaults to targeting 64-bit.
Jul 15 2019
parent Seb <seb wilzba.ch> writes:
On Monday, 15 July 2019 at 11:56:38 UTC, Vladimir Panteleev wrote:

 On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:




 sc.ini and dub output at:

 https://pastebin.com/jPnh4yEA




 By default Digger builds D for 32-bit only. However, it looks 
 like Dub is trying to build your code targeting the 64-bit 
 model, whether due to a setting in your project's dub.json, or 
 something else like dub.exe being a 64-bit executable.



Yes, dub defaults to 64-bit on 64-bit since 2.085 IIRC. It will 
also never use optlink by default anymore.
Jul 15 2019
prev sibling parent reply Boris Carvajal <boris2.9 gmail.com> writes:
On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:

 I built it with:

 dub fetch digger



 I have not touched any digger.ini. The only one I can find is 
 digger.ini.sample.

 sc.ini and dub output at:

 https://pastebin.com/jPnh4yEA


 dub test was invoked with:

 dub test 
 --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v


 I seem to get the same errors from a Cygwin terminal as from a 
 cmd one.


I'll give you another option if you just need that fix.
Patch your phobos64.lib in the original dmd install directory 
using cygwin and sed, just run this exact command on cygwin 
prompt, editing the path to your case:

sed -bi 's/%zu): /%llu):/' /c/d/dmd2/windows/lib64/phobos64.lib

you can patch the 32bit libs if you need them.
Then just run dub without "--compiler=" option to use your 
original dmd.
Jul 15 2019
parent reply Anonymouse <zorael gmail.com> writes:
On Monday, 15 July 2019 at 12:40:57 UTC, Boris Carvajal wrote:

 On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:

 I built it with:

 dub fetch digger



 I have not touched any digger.ini. The only one I can find is 
 digger.ini.sample.

 sc.ini and dub output at:

 https://pastebin.com/jPnh4yEA


 dub test was invoked with:

 dub test 
 --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v


 I seem to get the same errors from a Cygwin terminal as from a 
 cmd one.


 I'll give you another option if you just need that fix.
 Patch your phobos64.lib in the original dmd install directory 
 using cygwin and sed, just run this exact command on cygwin 
 prompt, editing the path to your case:

 sed -bi 's/%zu): /%llu):/' /c/d/dmd2/windows/lib64/phobos64.lib

 you can patch the 32bit libs if you need them.
 Then just run dub without "--compiler=" option to use your 
 original dmd.


This works for the reduced test program but not for my whole 
project. If you wouldn't mind trying it:


 git clone https://github.com/zorael/kameloso.git && cd kameloso 
 && dub test


(Windows 10, dmd 2.087 with your sed substitution)

I'll try dustmiting it later tonight.
Jul 16 2019
parent reply Boris Carvajal <boris2.9 gmail.com> writes:
On Tuesday, 16 July 2019 at 09:07:03 UTC, Anonymouse wrote:

 This works for the reduced test program but not for my whole 
 project. If you wouldn't mind trying it:


 git clone https://github.com/zorael/kameloso.git && cd 
 kameloso && dub test


 (Windows 10, dmd 2.087 with your sed substitution)

 I'll try dustmiting it later tonight.


The debugger exposes a crash in memchr from C runtime.

In file messaging.d line 216 called from the unittest just below


 if (emoteTarget.beginsWithOneOf(state.client.server.chantypes))


chantypes.ptr is null. However chantypes.length is 1 so you are 
assigning something invalid to it.


 grep -nr "chantypes = " kameloso/


shows this place as something to care about
kameloso/source/kameloso/irc/parsing.d:1983:   chantypes = value;
Jul 16 2019
parent reply Anonymouse <zorael gmail.com> writes:
On Tuesday, 16 July 2019 at 11:20:49 UTC, Boris Carvajal wrote:

 The debugger exposes a crash in memchr from C runtime.

 In file messaging.d line 216 called from the unittest just below


 if (emoteTarget.beginsWithOneOf(state.client.server.chantypes))


 chantypes.ptr is null. However chantypes.length is 1 so you are 
 assigning something invalid to it.


 grep -nr "chantypes = " kameloso/


 shows this place as something to care about
 kameloso/source/kameloso/irc/parsing.d:1983:   chantypes = 
 value;


Again, thank you for your immense help!

This is weird, chantypes should refer to a slice of immutables (a 
string). Simplified:

void onISUPPORT(ref IRCParser parser, ref string slice)
{
     import std.algorithm.iteration : splitter;

     foreach (string value; slice.splitter(' '))
     {
         // ...
         parser.client.server.chantypes = value;
     }
}



I get the same error even if I try to work around it with .idup. 
The only thing that does seem to help is checking for .ptr !is 
null at the unittest location you mention.


 if (state.client.server.chantypes.ptr && 
 emoteTarget.beginsWithOneOf(state.client.server.chantypes))


I started a dustmite process, with some luck it should produce 
something smaller by tonight or tomorrow.
Jul 16 2019
next sibling parent Anonymouse <zorael gmail.com> writes:
On Tuesday, 16 July 2019 at 13:33:01 UTC, Anonymouse wrote:




IRCParser.init.client.server.chantypes.
Jul 16 2019
prev sibling parent reply Anonymouse <zorael gmail.com> writes:
On Tuesday, 16 July 2019 at 13:33:01 UTC, Anonymouse wrote:

 I started a dustmite process, with some luck it should produce 
 something smaller by tonight or tomorrow.


Reduced:

import std.experimental.logger : Logger;

void main()
{
     Logger logger;
     logger.error();
}


 git clone https://github.com/zorael/tests -b loggererror


$ dub run
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for 
x86_64.
tests ~loggererror: building configuration "application"...
Linking...
Running .\tests.exe
Program exited with code -1073741819

$ dmd -oftests.exe source/app.d && ./tests.exe

object.Error (0): Access Violation
----------------
0x00402381
0x00402357
0x00409055
0x00408EF0
0x004075A7
0x76358494 in BaseThreadInitThunk
0x775341C8 in RtlAreBitsSet
0x77534198 in RtlAreBitsSet
Jul 17 2019
parent Anonymouse <zorael gmail.com> writes:
On Wednesday, 17 July 2019 at 17:43:53 UTC, Anonymouse wrote:

 [...]


Ignore this, Logger is a class and the error is to be expected. 
Will retry dustmite.
Jul 17 2019