On Sunday, 3 January 2021 at 15:49:03 UTC, Imperatorn wrote:
On Saturday, 2 January 2021 at 22:08:34 UTC, WhatMeWorry wrote:
On Saturday, 2 January 2021 at 22:04:28 UTC, WhatMeWorry wrote:
I'm stepping through the windows static library tutorial at
http://prowiki.org/wiki4d/wiki.cgi?D__Tutoria
On Saturday, 2 January 2021 at 22:08:34 UTC, WhatMeWorry wrote:
On Saturday, 2 January 2021 at 22:04:28 UTC, WhatMeWorry wrote:
I'm stepping through the windows static library tutorial at
http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#Linkingmanually
[...]
Oops. used the ma
On Saturday, 2 January 2021 at 22:04:28 UTC, WhatMeWorry wrote:
I'm stepping through the windows static library tutorial at
http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#Linkingmanually
[...]
Oops. used the manual example. Should be
/LIBPATH:c:\dev\LibraryStudy\StaticLibr
I'm stepping through the windows static library tutorial at
http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#Linkingmanually
```
The fix is to specify the prebuilt .lib file on the command line:
dmd driver.d %cd%\libs\libfoo\libfoo.lib
```
The tutorial is for 32 bit so it u
On Saturday, 26 December 2020 at 14:10:46 UTC, Basile B. wrote:
On Saturday, 26 December 2020 at 11:55:58 UTC, Виталий Фадеев
wrote:
We have:
[...]
Problem is:
$ gdb ./app.exe
GNU gdb (GDB) 9.2
...
(No debugging symbols found in ./app.exe)
What is a right way to build .exe and d
On Saturday, 26 December 2020 at 11:55:58 UTC, Виталий Фадеев
wrote:
We have:
[...]
Problem is:
$ gdb ./app.exe
GNU gdb (GDB) 9.2
...
(No debugging symbols found in ./app.exe)
What is a right way to build .exe and debug with gdb ?
Try to build with latest version of LDC and use
On Saturday, 26 December 2020 at 11:55:58 UTC, Виталий Фадеев
wrote:
Problem is:
$ gdb ./app.exe
GNU gdb (GDB) 9.2
...
(No debugging symbols found in ./app.exe)
What is a right way to build .exe and debug with gdb ?
The version of gdb that ships with MSYS is probably going t
We have:
// app.d
import std.stdio;
void main()
{
writeln( "OK" );
}
Build:
dmd -m64 -g app.d
OS:
Windows 10, x86_64
MSYS2: gdb
Goal:
gdb app.exe
Problem is:
$ gdb ./app.exe
GNU gdb (GDB) 9.2
...
(No debugging symbols found in ./ap
On Friday, 20 July 2018 at 12:03:20 UTC, evilrat wrote:
On Friday, 20 July 2018 at 04:31:38 UTC, Jordan Wilson wrote:
On Friday, 20 July 2018 at 01:34:39 UTC, Mike Parker wrote:
On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson
wrote:
Is there any way I can generate the appropriate
On Friday, 20 July 2018 at 05:12:05 UTC, Mike Parker wrote:
On Friday, 20 July 2018 at 04:31:38 UTC, Jordan Wilson wrote:
I don't have MSVC, so I built it using mingw, which generated
a .a lib.
I shall google some more, as I understand it DMD -m64 uses
Mingw libs as a fall back when MSVC not f
On Friday, 20 July 2018 at 04:31:38 UTC, Jordan Wilson wrote:
On Friday, 20 July 2018 at 01:34:39 UTC, Mike Parker wrote:
On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson wrote:
Is there any way I can generate the appropriate lib?
Else I think I'll need to get hold of the proper imp
On Friday, 20 July 2018 at 04:31:38 UTC, Jordan Wilson wrote:
I don't have MSVC, so I built it using mingw, which generated a
.a lib.
I shall google some more, as I understand it DMD -m64 uses
Mingw libs as a fall back when MSVC not found, I compiled Lua
using mingw, I can't be too much furthe
On Friday, 20 July 2018 at 01:34:39 UTC, Mike Parker wrote:
On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson wrote:
Is there any way I can generate the appropriate lib?
Else I think I'll need to get hold of the proper import libs
that come with the Lua distribution.
Lua is extreme
On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson wrote:
Is there any way I can generate the appropriate lib?
Else I think I'll need to get hold of the proper import libs
that come with the Lua distribution.
Lua is extremely easy to build. That will generate the import lib
for you.
I'm trying to create an import library from a dll (in this case,
a Lua dll).
Using dumpbin, I end up with a .def file:
EXPORTS
luaL_addlstring
luaL_addstring
luaL_addvalue
luaL_argerror
luaL_buffinit
...
I then use MS lib tool to generate a lib file:
lib /def:lua53.def /out:lua53.lib /machine
http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com
Got a working build at 64 bits using the 2.067 beta 3.
Delighted.
IIRC there are some fixes to the Win64 context switching code
in the 2.067 or master druntime. You might want to try those
first before spending more time tracking this down.
Great, and thanks.
On Monday, 9 March 2015 at 17:00:38 UTC, Jacques Müller wrote:
With the newest beta everything seems to work fine.
http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com
That's great news! Thank you.
With the newest beta everything seems to work fine.
http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com
On Sunday, 8 March 2015 at 18:18:49 UTC, Carl Sturtivant wrote:
Should I be doing something special with linkage so this works?
What is going on?
IIRC there are some fixes to the Win64 context switching code in
the 2.067 or master druntime. You might want to try those first
before spending mo
I can reproduce this issue with dmd 2.066.1,
please go forward and open a issue on https://issues.dlang.org/
Kind Regards
Benjamin Thaut
Thank you; will do.
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote:
Please confirm or deny that this is a real bug, as its getting
in the way of a genuine project. How should I proceed?
I'm working on a 64-bit Windows port of the following.
http://www.cs.arizona.edu/icon/
Here's the 32-bit Windows
Please confirm or deny that this is a real bug, as its getting in
the way of a genuine project. How should I proceed?
I'm working on a 64-bit Windows port of the following.
http://www.cs.arizona.edu/icon/
Here's the 32-bit Windows port.
http://www.cs.arizona.edu/icon/v95w.htm
Among other things
The following crashes on Windows 7 sp1 64-bit edition when build
at 64 bits with dmd and the Microsoft linker that comes with
Windows SDK 7.1 (i.e. MSVC 2010 linker). I've had no trouble with
other D code when using that arrangement, though I have not used
threads. When built at 32 bits with
On 08.10.2013 01:26, "Casper Færgemand" " wrote:
And I'm done. The problem was this:
LIB=%@P%\..\lib;%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\x64
The lib folder linked first contains kernel32.lib and shell32.lib.
Removing both made -m64 possible, but killed -m32. Changing it to this:
LIB=%V
And I'm done. The problem was this:
LIB=%@P%\..\lib;%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\x64
The lib folder linked first contains kernel32.lib and
shell32.lib. Removing both made -m64 possible, but killed -m32.
Changing it to this:
LIB=%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\x64;%@
Okay, it's definitely a problem with dmd passing something bad to
link. I was able to link it manually and the program was working
fine.
import std.stdio;
void main() {
writeln("Hello Linker!");
}
I ran "dmd -m64 test.d". The usual errors were dumped in the
terminal. I then ran "link
More searching suggests all the unresolved external symbols are
found in the lib files in v7.1\Lib\x64\
I'm guessing the linker doesn't know this. Any easy way to tell
it where to look? Does the linker have an include folder? I tried
with -LPATH"%WindowsSdkDir%\Lib\x64" as well as -L+"C:\Program
A lot of deleted posts and a lot of stupid later, v7.1 SDK is
apparently installed in Program Files and not Program Files
(x86). Kinda obvious given the names of said folders, but
whatever. x.x
The x64 version does indeed have an x64 folder in the Lib folder.
However, all that aside, still th
I have four folders in the SDK folder: v7.0A, v7.1, v8.0 and
v8.0A. The latter three contain nothing but a few files,
presumably installed by VS 11 or something else. I'm currently
trying to install v7.1.
On Monday, 7 October 2013 at 17:48:13 UTC, Rainer Schuetze wrote:
Maybe the WindowsSdkDir environment variable is not set in your
console. For the Windows 8 SDK, the standard location of the
x64 libraries is
"c:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64"
for the Windows 7 SDK or pr
On 07.10.2013 12:21, "Casper Færgemand" " wrote:
On Monday, 7 October 2013 at 07:03:39 UTC, Rainer Schuetze wrote:
The linker does not find the import libraries from the Windows SDK, so
it hits the 32-bit libraries that come with dmd.
The released sc.ini does not work with VS2012+ or a Window
On Monday, 7 October 2013 at 07:03:39 UTC, Rainer Schuetze wrote:
The linker does not find the import libraries from the Windows
SDK, so it hits the 32-bit libraries that come with dmd.
The released sc.ini does not work with VS2012+ or a Windows SDK
8, you should add the following lines to it:
On 07.10.2013 03:31, "Casper Færgemand" " wrote:
Hey, I've been trying for a while to compile 64 bit programs on a
Windows 7 platform. The setup is the following:
Version: 2.063.2
OS: Windows 7 64
Linked: VS 11 64 bit linker
sc.ini:
[Version]
version=7.51 Build 020
[Environment]
LIB="%@P%\.
Hey, I've been trying for a while to compile 64 bit programs on a
Windows 7 platform. The setup is the following:
Version: 2.063.2
OS: Windows 7 64
Linked: VS 11 64 bit linker
sc.ini:
[Version]
version=7.51 Build 020
[Environment]
LIB="%@P%\..\lib";\dm\lib
DFLAGS="-I%@P%\..\..\src\phobos"
"-
35 matches
Mail list logo
