On 15/05/2021 9:42 AM, DLearner wrote:
I am getting 'Error 42: Symbol Undefined' while testing some (fairly)
complex imports.
There was a reference in January to an Optlink bug that seemed like it
could be responsible.
If rdmd can use another linker (and one was recommended),
I am getting 'Error 42: Symbol Undefined' while testing some
(fairly) complex imports.
There was a reference in January to an Optlink bug that seemed
like it could be responsible.
If rdmd can use another linker (and one was recommended), I might
be able to test things furth
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.
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://git
On Tuesday, 16 July 2019 at 13:33:01 UTC, Anonymouse wrote:
IRCParser.init.chantypes even has a default value of "#".
IRCParser.init.client.server.chantypes.
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.le
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'
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
dub run digger -- build "stable + druntime#2675"
I have not touched any digger.ini. The only one I can find is
digger.ini.sample.
sc.i
owever, 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.
On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
I built it with:
dub fetch digger
dub run digger -- build "stable + druntime#2675"
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
On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
dub run digger -- build "stable + druntime#2675"
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,
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
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 pa
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
On Friday, 3 May 2019 at 06:20:37 UTC, Mike Parker wrote:
If you compile with -m32mscoff for 32-bit or -m64, DMD will use
the Microsoft linker and import libraries if you have Visual
Studio or the MS Build tools installed, and the LDC linker with
some import libraries from MinGW if you don’t.
.
Wondering if I've missed something here, or possibly identified
a bug with dmd?
Thanks
By default, DMD uses the Optlink linker and some quite old system
import libraries in the OMF format. They’re missing a number of
functions. If you compile with -m32mscoff for 32-bit or -m64, DMD
wil
Hi everyone,
I am getting a linker error when compiling with dmd (v2.085.1)
when using StrechDIBits from the win32 api.
Error 42: Symbol Undefined _StretchDIBits@52
However with ldc (v1.15.0) the program compiles correctly.
Wondering if I've missed something here, or possibly identified a
b
On Tuesday, 9 April 2019 at 06:50:36 UTC, Michal Minich wrote:
On Monday, 8 April 2019 at 14:49:02 UTC, Radu wrote:
[...]
Thank you Radu!
Your answer helped and hello word is now running :)
After using --verbose I found that I do not have libcmt.lib on
my computer at all. Though I have Vis
On Monday, 8 April 2019 at 14:49:02 UTC, Radu wrote:
Hi there,
Compiling with 2.085.1 on Windows 10 works with `dub
--arch=x86_mscoff`
LDC 1.15.0 works for x86/x86_64. Tested also on a fresh VMWare
instance running Windows 7.
You can try running it with `dub --arch=x86_mscoff --verbose`
in
ompilation finishes ok. then it prints "Linking..." and I get
window message box:
-------
Unexpected OPTLINK Termination at EIP=0040F60A
---
EAX=073D EBX=00438C70 ECX=0B2F EDX=038A
ESI=008F EDI=073D1344 EBP=0019FF28 ESP=001
t; and I get
window message box:
-------
Unexpected OPTLINK Termination at EIP=0040F60A
---
EAX=073D EBX=00438C70 ECX=0B2F EDX=038A
ESI=008F EDI=073D1344 EBP=0019FF28 ESP=0019FEE0
First=00402000
---
OK
---
On Thursday, 4 January 2018 at 21:33:58 UTC, Dukc wrote:
On Saturday, 30 December 2017 at 00:49:48 UTC, user1234 wrote:
The deps have to be rebuild too.
After downloading dmd 78, it started to work. It's likely you
were right about the issue, DUB rebuilt everything after
detecting new compi
On Saturday, 30 December 2017 at 00:49:48 UTC, user1234 wrote:
The deps have to be rebuild too.
After downloading dmd 78, it started to work. It's likely you
were right about the issue, DUB rebuilt everything after
detecting new compiler version.
Sorry for my late reply.
On Friday, 29 December 2017 at 16:11:20 UTC, Dukc wrote:
I was building one example of DLangUi (dub build
--build-mode=allAtOnce --build=debuglinker) and it did compile
but the linker started to complain. I did notice it seemed to
be related to the standard library, so I updated it and
DRuntim
I was building one example of DLangUi (dub build
--build-mode=allAtOnce --build=debuglinker) and it did compile
but the linker started to complain. I did notice it seemed to be
related to the standard library, so I updated it and DRuntime to
the lastest master, rebuilt them and replaced phobos.
On 19.09.2017 13:47, Timothy Foster wrote:
I'm trying to compile my project as a Win64 application but this is
happening:
Building C:\Users\me\test\test.exe...
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.co
\Users\me\test\test.exe...
> 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 183: Extension not .RES : obj\debug\dummy\test\..\source
> \c.obj
> obj\debug\dummy
On Tuesday, 19 September 2017 at 11:47:00 UTC, Timothy Foster
wrote:
I'm trying to compile my project as a Win64 application but
this is happening:
Building C:\Users\me\test\test.exe...
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
I'm trying to compile my project as a Win64 application but this
is happening:
Building C:\Users\me\test\test.exe...
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 183: Extensio
stuck forever linking, but issues
this warning:
..\..\Users\J.Spashett\AppData\Roaming\dub\packages\gtk-d-3.2.1\gtkd-3.lib
Warning 178: .LIB pagesize exceeds 512
I had the same issue a few weeks ago :
https://github.com/gtkd-developers/GtkD/issues/133
On my case optlink crashes instead of ge
Hello,
I am trying to build against the version 3.2.1 of gtk bindings in
the dub repository. The build system has built the gtkd-3.lib
library file, but doesn't not appear to want to link it to
anything else. It gets stuck forever linking, but issues this
warning:
..\..\Users\J.Spashett\App
On Friday, 20 November 2015 at 12:49:02 UTC, Rikki Cattermole
wrote:
Dunno if its been fixed in ~master (doubt it), but all you need
to do in your code, is copy it in.
Cool, that worked.
I've personally marked (well voted anyway) for this bug to be
critical.
It seems I'm the only one who thin
On Friday, 20 November 2015 at 12:31:37 UTC, Tofu Ninja wrote:
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole
wrote:
One already exists.
I've confirmed it in the build scripts. It only effects
Windows.
Any fix for this right now?
No, https://issues.dlang.org/show_bug.cgi?id=
On 21/11/15 1:31 AM, Tofu Ninja wrote:
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole wrote:
One already exists.
I've confirmed it in the build scripts. It only effects Windows.
Any fix for this right now?
Dunno if its been fixed in ~master (doubt it), but all you need to do
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole
wrote:
One already exists.
I've confirmed it in the build scripts. It only effects Windows.
Any fix for this right now?
On 11/11/15 5:17 PM, Dustin Walker wrote:
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OP
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copy
On 11/11/15 12:05 AM, uiop wrote:
On Tuesday, 10 November 2015 at 10:34:56 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is stil
On Tuesday, 10 November 2015 at 10:34:56 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
How can I do that?
When you setup dmd 2.069, did y
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
When you setup dmd 2.069, did you use the 7z or installer ?
i have the same issue. i used the installer. i only h
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
How can I do that?
When you setup dmd 2.069, did you use the 7z or installer ?
Installer always
btw. Thanks f
On Monday, 9 November 2015 at 18:07:39 UTC, ref2401 wrote:
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copy
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
On Monday, 20 July 2015 at 13:16:43 UTC, Lemonfiend wrote:
I was still using 2.066.1.
When I try to build using 2.067.0 or 2.067.1 I get:
Linking...
checkpoint(256)
--- errorlevel 1
with an "Unexpected OPTLINK Termination" popup which lists a
bunch of registers.
I'm not sure
I was still using 2.066.1.
When I try to build using 2.067.0 or 2.067.1 I get:
Linking...
checkpoint(256)
--- errorlevel 1
with an "Unexpected OPTLINK Termination" popup which lists a
bunch of registers.
I'm not sure how to proceed..
On Monday, 23 March 2015 at 13:29:15 UTC, wobbles wrote:
Maybe this should be distributed in the DMD installer?
i don't know :)
4 UTC, Etienne wrote:
This is due to a high amount of symbols in your code.
I fixed this almost a year ago in the optlink repository:
https://github.com/DigitalMars/optlink/pull/15
You should be able to download it on the digitalmars.com
website under:
Digital Mars C/C++ Compiler Version 8.57
ols in your code.
I fixed this almost a year ago in the optlink repository:
https://github.com/DigitalMars/optlink/pull/15
You should be able to download it on the digitalmars.com
website under:
Digital Mars C/C++ Compiler Version 8.57 (3662658 bytes)
The link.exe file in the bin folder is up-to-date.
rrors (symbols undefined) i
have only one error left:
Optlink:
Error 45: Too Much DEBUG Data for Old CodeView format
i googled, but really can't figure out what this error is about.
This is due to a high amount of symbols in your code.
I fixed this almost a year ago in the optlink reposito
On Saturday, 21 March 2015 at 21:25:26 UTC, Trass3r wrote:
Just save yourself lots of headaches and abandon the
optlink/omf crap with -m64 resp. -m32mscoff.
thank you.
After some reading about m32mscoff, i have to recompile druntime
and phobos with MODEL=32mscoff to use the new switch?
Just save yourself lots of headaches and abandon the optlink/omf
crap with -m64 resp. -m32mscoff.
On Friday, 20 March 2015 at 21:35:54 UTC, Orfeo wrote:
You can refer to
http://forum.dlang.org/post/jhbgaacoguxaubxgp...@forum.dlang.org
but i don't want to throw in the towel. ;)
Compiling in release mode works fine, yes.
Do you use dub?
I resolved my problems (on Win) abandoning dub
and usi
DerelictSDL2. As we all know, one update isn't enough, so i
updated my whole d-environment at the end of the day (current
dmd
version, VisualD).
After getting rid of some linking errors (symbols undefined) i
have only one error left:
Optlink:
Error 45: Too Much DEBUG Data for Old CodeView f
y one error left:
Optlink:
Error 45: Too Much DEBUG Data for Old CodeView format
i googled, but really can't figure out what this error is about.
On Sunday, 8 March 2015 at 23:05:53 UTC, David Held wrote:
On 3/8/2015 3:55 PM, David Held wrote:
Since DDT (Eclipse plugin) uses Dub, I am trying to convert
the DWT
build instructions into Dub. Here is my current attempt:
{
"name" : "foo",
"description" : "foo",
"importPaths" : [
On 3/8/2015 3:55 PM, David Held wrote:
Since DDT (Eclipse plugin) uses Dub, I am trying to convert the DWT
build instructions into Dub. Here is my current attempt:
{
"name" : "foo",
"description" : "foo",
"importPaths" : [ "d:/workspace/dwt/imp" ],
"stringImportPaths" : [
"D
t;stringImportPaths" : [
"D:/workspace/dwt/org.eclipse.swt.win32.win32.x86/res" ],
"lflags" : [
"-L+D:/workspace/dwt/lib",
"-L/SUBSYSTEM:WINDOWS:4.0"
],
"libs" : [
"org.eclipse.swt.win32.win32.x86",
If I compile with rdmd
```
$ dub build --rdmd
```
it works
iguration "library", build type
debug.
Running dmd...
Building ddb_test ~master configuration "application", build type
debug.
Compiling using dmd...
Linking...
```
I get a message:
Unexpected OPTLINK Termination a t EIP=0040F5Ba
If I comment just a row on app.d:
```
import ddb.postgres;
// import gtk.Window; <=
int main(string[] argv) {
return 0;
}
```
it works!
Thank you
I'm getting "Unexpected OPTLINK Termination at EIP = 0
and assembly register values" when compiling the follow code. I'm
doing something wrong?
class MyClass
{
void opCall()
{
}
}
public void main(string[] arguments)
{
MyClass clazz = new MyClass();
On 2013-07-16 12:41, Jeremy DeHaan wrote:
This seems kind of strange to me, but when I go to specify a search
directory for the linker I can't seem to get it to work for a path that
contains spaces.
It's a known issue.
--
/Jacob Carlborg
Any chance:
-L+"C:\Users\Jeremy\Desktop\Search Directory\"
works?
Nope, same error.
On Tuesday, 16 July 2013 at 10:41:51 UTC, Jeremy DeHaan wrote:
This seems kind of strange to me, but when I go to specify a
search directory for the linker I can't seem to get it to work
for a path that contains spaces.
I tried to put quotes around the switch like I've done for
other switches
This seems kind of strange to me, but when I go to specify a
search directory for the linker I can't seem to get it to work
for a path that contains spaces.
I tried to put quotes around the switch like I've done for other
switches, but when my program goes to link I get some strange
errors.
On 2012-10-19 02:30, Ellery Newcomer wrote:
extern(C) extern export PyTypeObject PyType_Type;
seems to do the trick (I'm using a boiled down case just now)!
High five to the [non-me] non-windows dev!
Hehe, high five :)
--
/Jacob Carlborg
On 10/18/2012 11:36 AM, Jacob Carlborg wrote:
On 2012-10-18 13:55, Ellery Newcomer wrote:
I am using python27_digitalmars.lib, which is generated from
libs\python27.lib with coffimplib, and it is linking my executables with
python.dll.
Ok. Do you know how the corresponding C code would look l
On 2012-10-18 13:55, Ellery Newcomer wrote:
I am using python27_digitalmars.lib, which is generated from
libs\python27.lib with coffimplib, and it is linking my executables with
python.dll.
Ok. Do you know how the corresponding C code would look like? Maybe you
need to use the "export" attrib
On 10/17/2012 11:41 PM, Jacob Carlborg wrote:
On 2012-10-18 05:12, Ellery Newcomer wrote:
nice tip, but adding extern doesn't change link behavior at all.
Hmm, are you linking with the DLL (the import library) ? In not, you
need to use dlopen, or what the corresponding Windows function is.
On Thu, 18 Oct 2012 07:41:16 +0100, Jacob Carlborg wrote:
On 2012-10-18 05:12, Ellery Newcomer wrote:
nice tip, but adding extern doesn't change link behavior at all.
Hmm, are you linking with the DLL (the import library) ? In not, you
need to use dlopen, or what the corresponding Windows
On 2012-10-18 05:12, Ellery Newcomer wrote:
nice tip, but adding extern doesn't change link behavior at all.
Hmm, are you linking with the DLL (the import library) ? In not, you
need to use dlopen, or what the corresponding Windows function is.
--
/Jacob Carlborg
On 10/16/2012 11:16 PM, Jacob Carlborg wrote:
You need to declare the variable as "extern" if it's defined in the C code:
extern(C) extern __gshared PyTypeObject PyType_Type;
http://dlang.org/interfaceToC.html#C%20Globals
nice tip, but adding extern doesn't change link behavior at all.
using it trouble. If I set PATH to only the dmd2\windows\bin
folder everything works.
Ok. Figured it all out. OPTLINK doesn't like a PATH with + in it.
C:\TEMP>dmd -g -debug crash.d
C:\TEMP>set path=%path%;+
C:\TEMP>dmd -g -debug crash.d
OPTLINK (R) for Win32 Release 8
older everything works.
Ok. Figured it all out. OPTLINK doesn't like a PATH with + in it.
C:\TEMP>dmd -g -debug crash.d
C:\TEMP>set path=%path%;+
C:\TEMP>dmd -g -debug crash.d
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All ri
Ok. Figured it all out. OPTLINK doesn't like a PATH with + in it.
C:\TEMP>dmd -g -debug crash.d
C:\TEMP>set path=%path%;+
C:\TEMP>dmd -g -debug crash.d
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/o
optlink is generating a new memory
location for PyType_Type.
strings output suggests that my lib file contains the symbol PyType_Type.
Is this sort of thing supposed to work?
You need to declare the variable as "extern" if it's defined in the C code:
extern(C) extern __gshar
I am interfacing with some C code [python.dll], which has some structs
declared like so:
PyTypeObject PyType_Type;
I wish to be able to link to PyType_Type like so:
extern(C) __gshared PyTypeObject PyType_Type;
in linux, I can do exactly that, but optlink is generating a new memory
location
On 2012-10-09 22:59, Andrei Alexandrescu wrote:
I'd be bummed because that's quite a logical decision, and how other
interpreters do it.
GDB uses the --args approach.
--
/Jacob Carlborg
On 09/10/2012 22:30, Andrei Alexandrescu wrote:
On 10/9/12 12:30 PM, Faux Amis wrote:
On a side-note, why is rdmd picky about argument order?
>dmd test.d -I..\include
Because anything after the program is considered an argument to the
program.
Andrei
My bad, should have read the spec bett
On 10/9/12, Andrei Alexandrescu wrote:
> I'd be bummed because that's quite a logical decision, and how other
> interpreters do it.
On second thought my solution wouldn't work. --args would still have
to be passed before the D file, and people would have to remember that
or it wouldn't work, same
On 10/9/12 4:38 PM, Andrej Mitrovic wrote:
On 10/9/12, Andrei Alexandrescu wrote:
On 10/9/12 12:30 PM, Faux Amis wrote:
On a side-note, why is rdmd picky about argument order?
>dmd test.d -I..\include
Because anything after the program is considered an argument to the
program.
Andrei
On 10/9/12, Andrei Alexandrescu wrote:
> On 10/9/12 12:30 PM, Faux Amis wrote:
>> On a side-note, why is rdmd picky about argument order?
>>
>> >dmd test.d -I..\include
>
> Because anything after the program is considered an argument to the
> program.
>
> Andrei
>
I think this is a fairly common
On 10/9/12 12:30 PM, Faux Amis wrote:
On a side-note, why is rdmd picky about argument order?
>dmd test.d -I..\include
Because anything after the program is considered an argument to the program.
Andrei
I get an unexpected OPTLINK termination when I run the lovely thing
below, any advice (dmd 2.060)?
rdmd --chatty --force --build-only ..\lib\libcairo-2.lib -I..\include
..\lib\libcairod.lib ..\lib\dmd_win32_x32.lib -version=Unicode
-version=WIN32_WINNT_ONLY -version=WindowsNTonly -version
o saw this problem pre the git
commit also has
trouble with debug builds, or if this is a different bug.
I also had lots of trouble with Pegged and optlink since 2.060.
Are
you using rdmd? Because I have no linking problems with dmd,
only
rdmd, strangely enough. Maybe it's due to rd
rouble with debug builds, or if this is a different bug.
I also had lots of trouble with Pegged and optlink since 2.060. Are
you using rdmd? Because I have no linking problems with dmd, only
rdmd, strangely enough. Maybe it's due to rdmd reusing cached
information that should be updated more aggressively.
I just ran into (I think) this bug
http://d.puremagic.com/issues/show_bug.cgi?id=8377 using dmd
2.060. Seeing that there was a fix in git, I cloned the latest
git dmd, built, and dropped the .exe into my existing dmd 2.060
installation directory.
I still get this unexpected optlink
Hi,
I'm getting the error mentioned in the subject. I can't find no
reference neither to DOSNEWSIZE nor to Error 63 on the Optilink
pages or google.
Where can I find information about this error ?
Is there a list which maps Optilink Error Numbers to Error Names ?
Cheers, ParticlePeter !
t, um...
dmd ssl_client.d "C:\Program Files\Microsoft
SDKs\Windows\v7.0\Lib\Crypt32.Lib"
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\Crypt32.Lib
use implib (http://ftp.digitalmars.com/bup.zip):
implib /s Crypt32_implib.Lib Crypt32.Lib
then use Crypt32_implib.Lib with dmd.
gram Files\Microsoft
SDKs\Windows\v7.0\Lib\Crypt32.Lib"
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\Crypt32.Lib
Error 43: Not a Valid Library File
Ac
Thanks, this is it!
On Sunday, 25 December 2011 at 22:46:33 UTC, Joshua Reusch wrote:
public string some_var = "Hello, world!";
It's important to note that public is the default access level
here.
Am 25.12.2011 22:37, schrieb Tal:
I want to save the hInstance of WinMain so I would be able to use it later in
some
other module. So how do I accomplish that ?
If you don't know: You can also get the HINSTANCE with
GetModuleHandle(NULL);
Am 25.12.2011 23:26, schrieb Tal:
I'm quite new to this language, could you please provide a short snippet of code
to clarify ?
--- a.d:
import std.stdio;
import b;
void main() {
writeln("some_var from Module b: \"", b.some_var, "\"");
}
--- b.d:
public string some_var = "Hello, world!";
I'm quite new to this language, could you please provide a short snippet of code
to clarify ?
Am 25.12.2011 22:37, schrieb Tal:
I want to save the hInstance of WinMain so I would be able to use it later in
some
other module. So how do I accomplish that ?
just define a public variable in the global scope.
I want to save the hInstance of WinMain so I would be able to use it later in
some
other module. So how do I accomplish that ?
You can't prototype D functions like that, they belong to a module.
test is built as _D1b4testFZAya, not _D1a4testFZAya (notice the module
names, a and b after _D1).
What exactly are you trying to do? DLLs?
1 - 100 of 161 matches
Mail list logo
