digitalmars / optlink Goto Github PK

Transferred from: https://issues.dlang.org/show_bug.cgi?id=1327
Platform: x86 Windows

User Bruce Adams reported (2007-07-09 20:30:06 CEST):

Hi
I had some problems getting DMD to play nicely with cygwin. It turns out the problem was down to a long environment variable value. As a newcomer to D I was very confused. It was not at all obvious what was happening.

Regards,

Bruce.

F:\projects\Agenda>c:\cygwin\bin\make dtest2
dmc hello.d -o hello
c:\dmd\bin\..\..\dm\bin\link.exe hello,,,user32+kernel32/noi;
c:\dmd\bin\..\..\dm\bin\link.exe hello,,,user32+kernel32/noi;
hello.d:
hello.d:
link hello+hello,,,user32+kernel32/noi;

F:\projects\Agenda>set GCCINCDIR="C:\cygwin\usr\include;C:\cygwin\usr\include\sys;C:\cygwin\usr\include\w32api;C:\cygwin\usr\local\i686-pc-cygwin\include;C:\cygwin\usr\local\i686-pc-cygwin\include\sys;C:\cygwin\usr\include\c++\3.4.4;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin\bits;C:\cygwin\lib\gcc-lib\i686-pc-cygwin\3.4.4\include;C:\cygwin\usr\include;C:\cygwin\usr\include\sys;C:\cygwin\usr\include\w32api;C:\cygwin\usr\local\i686-pc-cygwin\include;C:\cygwin\usr\local\i686-pc-cygwin\include\sys;C:\cygwin\usr\include\c++\3.4.4;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin\bits;C:\cygwin\lib\gcc\i686-pc-cygwin\C:\cygwin\usr\include;C:\cygwin\usr\include\sys;C:\cygwin\usr\include\w32api;C:\cygwin\usr\local\i686-pc-cygwin\include;C:\cygwin\usr\local\i686-pc-cygwin\include\sys;C:\cygwin\usr\include\c++\3.4.4;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin\bits;C:\cygwin\lib\gcc-lib\i686-pc-cygwin\3.4.4\include;C:\cygwin\usr\include;C:\cygwin\usr\include\sys;C:\cygwin\usr\include\w32api;C:\cygwin\usr\local\i686-pc-cygwin\include;C:\cygwin\usr\local\i686-pc-cygwin\include\sys;C:\cygwin\usr\include\c++\3.4.4;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin;C:\cygwin\usr\include\c++\3.4.4\i686-pc-cygwin\bits\include;C:\cygwin\lib\gcc\i686-pc-cygwin\3.4.4\include\c++;;C:\cygwin\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\i686-pc-cygwin;C:\cygwin\lib\gcc\i686-pc-cygwin\3.4.4\include"

F:\projects\Agenda>c:\cygwin\bin\make dtest2
dmc hello.d -o hello
c:\dmd\bin\..\..\dm\bin\link.exe hello,,,user32+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

phobos.lib
 Warning 2: File Not Found phobos.lib
OPTLINK : Warning 23: No Stack
hello.obj(hello)
 Error 42: Symbol Undefined _main
hello.obj(hello)
 Error 42: Symbol Undefined __acrtused_con
OPTLINK : Warning 134: No Start Address
--- errorlevel 2
hello.d:
--- errorlevel 2
make: *** [dtest2] Error 2

User Bruce Adams responded (2007-07-09 20:51:24 CEST):

I can confirm this also happens on the latest version (v2.002)

User @baxissimo responded (2007-07-09 21:10:01 CEST):

Ouch. That must have taken ages to figure out.

Actually it seems to be related to both the variable name and its value. For instance "XCCINCDIR" worked ok, and many values of GCCINCDIR are ok for me. But other variables caused the problem too, like "FOOINCDIR". I can't really determine a pattern.

In any event you should probably use 'dmd' to compile D code and not 'dmc' (which is a C++ compiler) ;-)

User @Deewiant responded (2007-07-10 05:49:29 CEST):

Keep the version at the oldest, not the newest, relevant value, please.

User @CyberShadow responded (2014-10-02 15:34:22 CEST):

OPTLINK doesn't see the LIB variable if the environment is too big. In my case it starts to misbehave if the environment is longer than about 8K, but I guess the exact size varies depending on where LIB is in the environment. This affects D2 as well.

Transferred from: https://issues.dlang.org/show_bug.cgi?id=10780

User @jacob-carlborg reported (2013-08-08 10:10:38 CEST):

I have a VirtualBox machine running Windows XP. I have setup a shared folder, with full access. Anything I compile in that shared folder, in the virtual machine, will fail with the following error from Optlink:

Error 62: Critical Write

Transferred from: https://issues.dlang.org/show_bug.cgi?id=13984

User @CyberShadow reported (2015-01-15 13:59:20 CET):

///////////// test.d ////////////
extern(System) uint GetVersion();

void main()
{
//    GetVersion();
}
/////////////////////////////////

This program compiles and links fine with the command:

$ dmd -L/ENTRY:_mainCRTStartup test.d 

However, if you uncomment the GetVersion line, linking breaks:

OPTLINK (R) for Win32  Release 8.00.15
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 180: No Match Found for Export/ENTRY -  : _mainCRTStartup
--- errorlevel 1

To fix linking, the leading underscore needs to be removed from the command line:

$ dmd -L/ENTRY:mainCRTStartup test.d

Issue.7960.attachement.1.repro.zip
Transferred from: https://issues.dlang.org/show_bug.cgi?id=7960

User @Ingrater reported (2012-Apr-21 02:31:52):

Created attachment 1098
repro case

This crash might have multiple causes. I compile my project with:

$ dmd -g -unittest -debug -X -Xf"Debug\thBase.json"
-IC:\Users\Benjamin\Documents\d-projects\druntime\import
-IC:\Users\Benjamin\Documents\d-projects\phobos -version=NOGCSAFE
-version=thBase_test -deps="Debug\thBase.dep" -of"Debug\thBase.exe_cv" -map
"Debug\thBase.map" -L/NOMAP -defaultlib=phobosnogc -debuglib=phobosnogc
gcstub.obj -v @Debug\thBase.build.rsp

Dmd launches optlink with:

$ link.exe
gcstub+"Debug\thBase","Debug\thBase.exe_cv","Debug\thBase.map",user32+kernel32/m/co/noi/NOMAP;

Which causes optlink to crash with EIP=00000000

The first thing which might be a bug in dmd is, that the phobosnogc library is
missing in the link command which I specified both with defaultlib and
debuglib.

If I manually specifiy the phobosnogc.lib in the build command dmd generates
the following link command:

link.exe
gcstub+"Debug\thBase","Debug\thBase.exe_cv","Debug\thBase.map","phobosnogc.lib"+user32+kernel32/m/co/noi/NOMAP;

Which still causes optlink to crash with EIP=00000000.

If I however let dmd only compile and then manually link with:

link.exe
"phobosnogc"+gcstub+"Debug\thBase","Debug\thBase.exe_cv","Debug\thBase.map",user32+kernel32/m/co/noi/NOMAP;

Optlink links everything fine and the executable works just as it should.

So there seem to be 3 different issues here:

1. dmd does not pass the library specified with debuglib defaultlib to optlink
2. Optlink crashes with EIP=00000000
3. The order in which you pass the library files to optlink changes optlink
   behaviour.

This issue exists with dmd 2.058 and optlink 8.00.12. See attached repro case.

User @Ingrater responded (2012-Apr-21 02:34:34):

I'm going to try adding a reduced source to reproduce the issue.

User @rainers responded (2013-Nov-23 02:35:25):

Maybe related: #11

Even though github does specify that projects without a license belong to the author, it might be a good idea to include a license anyway.

Transferred from: https://issues.dlang.org/show_bug.cgi?id=15418
Originally reported in Gtkd: gtkd-developers/GtkD#133

User @MikeWey reported (2015-12-07 23:28:53 CET):

When GtkD is compiled with debug information, which is the default for dub.

linking executables results in the following warning:

Warning 178: .LIB pagesize exceeds 512

after that optlink either hangs or terminates.

The GtkD library was compiled with the dmd -lib switch.
or dub build gtk-d:gtkd

The executable with the following command:

dmd HelloWorld.d -I..\..\src ..\..\gtkd.lib

[Stripped other comments as redundant or pings]

This follows the following thread:

dlang/dub#307 (comment)

You forgot to initialize CV_4_TYPE correctly, I'm not sure how I would do it. Could you look into this?

Thanks!

edit: I factored a bundle of modifications and those in cvindex.asm were not necessary, so I found that CV_4_TYPE is not to blame. The problem lies with qsortlin.asm only

Transferred from: https://issues.dlang.org/show_bug.cgi?id=8263

User @MartinNowak reported (2012-06-18 22:43:44 CEST):

While tracking down an issue with dbghelp.dll I found that the AddressOfRawData offset in the IMAGE_DEBUG_DIRECTORY header is 4 bytes to small.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680307(v=vs.85).aspx

Either we need to add 4 to AddressOfRawData or we need to shift the CodeView information and reduce PointerToRawData accordingly.

User @rainers responded (2019-08-24 08:42:33 CEST):

still valid, but an optlink issue

But would it be possible to have the source code for the DMC IDDE added to a repository, asking because it
displays wrongly on any OS from vista and up. Also it no longer seems to work on windows 10.

Transferred from: https://issues.dlang.org/show_bug.cgi?id=11302

User @braddr reported (2013-10-19 20:55:28 CEST):

Right now it only reads LIB from the Environment section.

Transferred from: https://issues.dlang.org/show_bug.cgi?id=5215
Original title: Crash with empty program

@bearophile reported (2010-11-13 15:46:08 CET):

This simple wrong D2 program generates expected linker errors and then an unexpected crash on Windows:

void main();

@donc responded (2010-11-13 19:01:25 CET):

What do you mean, 'unexpected'? It complains that there's no main(). Passing an empty file does exactly the same thing.
(The annoying thing is that it makes an exe anyway, even though the exe is corrupt).

@bearophile responded (2010-11-13 19:46:45 CET):

You are right, sorry. The crash is not caused by the compiler/linker, but by the corrupt exe.

@WalterBright responded (2012-01-20 03:12:34 CET):

The linker is supposed to create an exe file, even if there are errors. This is handy for some special purposes.

@braddr responded (2012-01-20 11:19:27 CET):

What circumstances? I don't have a lot of experience with windows, but binutils ld doesn't leave broken turds when linking fails like that. I can see having a linker option to force it to leave the output alone on error, but not having that as the default behavior. Would you treat dmd leaving a .obj file around if there are syntax errors in the .d being built?

@AndrejMitrovic responded (2012-01-20 11:31:54 CET):

Optlink has a /DELEXECUTABLE flag for deleting the exe if there are linker errors, but it doesn't work (I assume because optlink creates warnings instead of errors for OPs code).

Additionally optlink creates executables even if you don't pass anything to it, e.g.:

$ link.exe
creates .exe

The linker gives you warnings and creates a .exe file. Pretty stupid behavior if you ask me. Every modern console app would display a list of arguments you can pass to it, or a sane warning instead of "OPTLINK : Warning 134: No Start Address" when you didn't pass a single file to it.

@WalterBright responded (2012-01-20 13:47:06 CET):

The special purposes are when parts of your program are missing, but you want to link and run the rest of it.

I'm not sure why /delexecutable is not working, though.

I'm getting this error in a mid-sized application (using vibe-d and another internal library of similar size). It appears that this limit is quite easy to reach with moderate template use. The question is if anything can be done about this in the linker, or if this is a fundamental limitation rooted in the object file format.

Message:

The current behavior to show a modal dialog box on fatal errors is extremely inconvenient for CI setups, which will, in absence of a user that dismisses the dialog box, simply hang indefinitely. Simply outputting the error message to stderr is just as visible and avoids this issue.

Transferred from: https://issues.dlang.org/show_bug.cgi?id=17508

User @MartinNowak reported (2017-Jun-15 14:05:05):

Happens with debug builds of scod v0.3.1.

MartinNowak/scod#4

Unexpected OPTLINK Termination at EIP=0040F60A

EAX=051E0000 EBX=00438C70 ECX=0000048D EDX=0000033D
ESI=00006400 EDI=051E2DCC EBP=0019FF38 ESP=0019FEF0
First=00402000

User @Computermatronic responded (2018-Jan-01 12:24:27):

Also happens when trying to build seemingly any dub project dependent on vibe.d 0.8.2

User @MartinNowak responded (2018-Mar-03 13:25:57):

*** Issue 18207 has been marked as a duplicate of this issue. ***

User @MartinNowak responded (2018-Mar-03 13:27:20):

*** Issue 18353 has been marked as a duplicate of this issue. ***

User @RazvanN7 responded (2018-Apr-25 14:28:58):

*** Issue 18799 has been marked as a duplicate of this issue. ***

User @veelo responded (2018-Sep-09 11:36:56):

While we are waiting for a fix to optlink, is there a way to force ddox / scod to be linked with a different linker? Using --arch as in dub build -b ddox --arch=x86_mscoff for building the documentation of a library has no effect on building the ddox application, it is still linked using optlink.

Maybe dub can be changed to avoid optlink on Windows for ddox builds?

Transferred from: https://issues.dlang.org/show_bug.cgi?id=8606

User @erisco reported (2012-09-01 15:22:37 CEST):

Unfortunately, I haven't narrowed the problem down. Here are the DirectX bindings that I am using that reproduce the error:
http://www.dsource.org/projects/bindings/browser/branches/erisco_directx/d?rev=401
(also included in the attachment)

Particularly, the import std.string in d3d11.d seems to be causing the error (when removed, no error).

To reproduce: build these DirectX bindings into a lib (the DirectX bindings depend on part of win32 ... working project and build attached). Then, write any program that imports windows.directx.d3d11 and compile it (of course, linking to the lib). Optlink will crash with this output:

OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html

dxgi.lib
 Warning 2: File Not Found dxgi.lib
d3d11.lib
 Warning 2: File Not Found d3d11.lib
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA
..\lib\dmd_win32_x32.lib(d3d11) 
 Error 32: Data Outside Segment Bounds : _DATA

Sorry that this test case is so large; it may be useless, but I felt it was better to report it than do nothing.

User @erisco responded (2012-09-01 15:25:51 CEST):

Attachment was too large, so I uploaded it here

User @NeilBryant responded (2012-11-09 14:19:36 CET):

I was just having pretty much the exact same issue with 2.059.

I fixed it by deleting %temp%.rdmd

When compiling with dmd, I'm getting the following error:

checkpoint(256)
--- errorlevel 1

What exactly does this mean?

Popup details:

Unexpected OPTLINK Termination at EIP=0040347E

EAX=00000010 EBX=000000A0 ECX=00000000 EDX=004337CF 
ESI=0044AAE8 EDI=00000100 EBP=0018FF4C ESP=0018FDE4 
First=00402000

Transferred from: https://issues.dlang.org/show_bug.cgi?id=15183

User Felix Hufnagel reported (2015-Oct-09 19:03:56):

error messagebox:
http://pasteboard.co/1fJcLAUI.png

code:
http://www.filedropper.com/frayoptlinkreduced

my system: dub+dmd_v2.068.0 on windows10 x64

if you need more contact me:
[email protected]

User Felix Hufnagel responded (2015-Oct-09 19:04:37):

Created attachment 1557

code attached

Tags: ["Type.Enhancement", "OS.Windows", "Arch.x86", "Optlink"]