On 7/9/23 10:01 AM, Dmitry Olshansky wrote:
Trying to compile the following:
https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d
with:
ldc2 curl_download.d -L-lcurl
get:
"__D6photon12__ModuleInfoZ", referenced from:
__D13curl_download12__ModuleInfoZ in curl_d
On Saturday, 1 October 2022 at 21:18:05 UTC, Ali Çehreli wrote:
On 10/1/22 11:15, Kyle Ingraham wrote:
> storing structs as
> `void*` in a wrapper struct with information about their
module and
> identifier saved elsewhere.
Perhaps unrelated but that part reminded me of the following
discussio
On 10/1/22 11:15, Kyle Ingraham wrote:
> storing structs as
> `void*` in a wrapper struct with information about their module and
> identifier saved elsewhere.
Perhaps unrelated but that part reminded me of the following discussion:
https://forum.dlang.org/post/tfbn10$19nv$1...@digitalmars.co
On Tuesday, 13 September 2022 at 08:43:45 UTC, Nick Treleaven
wrote:
On Tuesday, 13 September 2022 at 03:00:17 UTC, Kyle Ingraham
wrote:
Any suggestions for being able to call one function for any
instance given but maintain flexible return types?
Not sure if it helps, but you can define final
On Tuesday, 13 September 2022 at 03:00:17 UTC, Kyle Ingraham
wrote:
Any suggestions for being able to call one function for any
instance given but maintain flexible return types?
Not sure if it helps, but you can define final methods in an
interface, which can call virtual interface methods:
On Tuesday, 13 September 2022 at 01:46:14 UTC, Paul Backus wrote:
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham
wrote:
I am writing a library where I would like to be able to store
instances of a type of class to an associative array for later
usage. Each class stored has to impl
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham
wrote:
I am writing a library where I would like to be able to store
instances of a type of class to an associative array for later
usage. Each class stored has to implement a function as part of
the required interface. The argument g
Most of the time these are dependency-issues. You need to install
a package called python-dev. This package includes header files,
a static library and development tools for building Python
modules, extending the Python interpreter or embedding Python in
applications. When encountering this err
On Tuesday, 12 October 2021 at 00:01:25 UTC, jfondren wrote:
On Monday, 11 October 2021 at 23:43:17 UTC, Ruby The Roobster
wrote:
package mixin template move__() {
pragma(inline) package void mv(Point moveby, ref Skeleton
tomove) {
foreach(i;tomove.faces) {
On Monday, 11 October 2021 at 23:43:17 UTC, Ruby The Roobster
wrote:
package mixin template move__() {
pragma(inline) package void mv(Point moveby, ref Skeleton
tomove) {
foreach(i;tomove.faces) {
foreach(k;i.lines) {
On Thursday, 14 May 2020 at 16:09:16 UTC, solidstate1991 wrote:
When I try to compile my own project under Ubuntu with dub, I
get the following linker error:
/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o:
undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so
On Friday, 15 May 2020 at 23:49:37 UTC, solidstate1991 wrote:
Dub should do the linking by itself.
How does it know what to link?
On Friday, 15 May 2020 at 03:46:57 UTC, evilrat wrote:
Um, pardon the stupid question, but did you just forgot to link
it? I can't see a mention of it anywhere in both the old json
and dub.sdl, and I don't see subpackages either. (does it links
implicitly by the compiler?)
Also if it's digg
On Thursday, 14 May 2020 at 16:09:16 UTC, solidstate1991 wrote:
When I try to compile my own project under Ubuntu with dub, I
get the following linker error:
/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o:
undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so
On 2019-05-30 15:36:53 +, Robert M. Münch said:
I updated to the latest DMD compiler and just re-compiled a project and
now I get two unresolved external errors:
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol
"_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m".
widgets.obj : erro
On 2019-05-30 16:06:48 +, KnightMare said:
immutable(ulong[2]) object.RTInfoImpl!([48, 57]).RTInfoImpl
immutable(ulong[2]) object.RTInfoImpl!([32, 14]).RTInfoImpl
through
writeln( demangle("_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m"));
writeln( demangle("_D6object__T10RTInfoImplVAmA2i32i14Z
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol
"_D6object__T10RTInfoImplVAmA2i48i57ZQyyG2m".
widgets.obj : error LNK2001: Nicht aufgelöstes externes Symbol
"_D6object__T10RTInfoImplVAmA2i32i14ZQyyG2m".
immutable(ulong[2]) object.RTInfoImpl!([48, 57]).RTInfoImpl
immutable(ulong
On 1/21/19 5:28 PM, Jerry wrote:
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer wrote:
On 1/21/19 3:37 PM, Jerry wrote:
[...]
I had a similar problem that I fixed myself actually last dconf:
https://issues.dlang.org/show_bug.cgi?id=17968
This looks almost identical as the
On Monday, 21 January 2019 at 22:31:15 UTC, H. S. Teoh wrote:
On Mon, Jan 21, 2019 at 10:19:00PM +, Jerry via
Digitalmars-d-learn wrote:
On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:
[...]
> Looks like a problem with stale cached object files. Try:
>
> rm dub.selections.
On Mon, Jan 21, 2019 at 10:19:00PM +, Jerry via Digitalmars-d-learn wrote:
> On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:
[...]
> > Looks like a problem with stale cached object files. Try:
> >
> > rm dub.selections.json
> > dub build --force
> >
> > (Be sure to back
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer
wrote:
On 1/21/19 3:37 PM, Jerry wrote:
[...]
I had a similar problem that I fixed myself actually last dconf:
https://issues.dlang.org/show_bug.cgi?id=17968
This looks almost identical as the issue was in the generated
xtoHas
On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote:
On Mon, Jan 21, 2019 at 04:02:23PM -0500, Steven Schveighoffer
via Digitalmars-d-learn wrote:
On 1/21/19 3:37 PM, Jerry wrote:
> [...]
[...]
> [...]
[...]
Looks like a problem with stale cached object files. Try:
rm dub.
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer
wrote:
What version of the compiler are you using? My issue was fixed
in 2.080.1, and then a followup fix in 2.081.1.
-Steve
Hello!
I am using 2.084.
Interestingly it works with LDC 1.9 (frontend 2.79) and that just
works fine
On Mon, Jan 21, 2019 at 04:02:23PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/21/19 3:37 PM, Jerry wrote:
> > Hello, I am trying to compile a 1 year old project of mine which
> > uses htmld and vibed. But I get this weird linker error which does
> > not make any sense to me
On 1/21/19 3:37 PM, Jerry wrote:
Hello, I am trying to compile a 1 year old project of mine which uses
htmld and vibed. But I get this weird linker error which does not make
any sense to me atleast. I am using Windows 7 and dub.
htmld 0.3.6: target for configuration "library" is up to date.
ta
On Sunday, 1 July 2018 at 01:16:59 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 00:42:30 spikespaz via
Digitalmars-d-learn wrote:
Hey guys, I'm getting a linker error when compiling with DMD
`-m63` that I don't get as 23 bit.
I'm importing `ShowWindow` from `core.sys.windows.winuser`,
On Sunday, July 01, 2018 00:42:30 spikespaz via Digitalmars-d-learn wrote:
> Hey guys, I'm getting a linker error when compiling with DMD
> `-m63` that I don't get as 23 bit.
>
> I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I
> get the following:
>
> C:\D\dmd2\windows\bin\lld-lin
On Sunday, 17 December 2017 at 20:09:02 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter
wrote:
On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter
[snip]
LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe
or
LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link
On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter
wrote:
On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:
I don't think so, all that would need to be changed is this
line:
https://github.com/dlang/dmd/blob/v2.
On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:
I don't think so, all that would need to be changed is this
line:
https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53
Not very many people use it I gue
On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:
I don't think so, all that would need to be changed is this
line:
https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53
Not very many people use it I guess if it's been there for 8
months lol.
Hm, actually that line I
On Sunday, 17 December 2017 at 17:15:57 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:
Yah the sc.ini file is wrong for Environment64.
[Environment64]
LIB="%@P%\..\lib64"
.
.
.
; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\
On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:
Yah the sc.ini file is wrong for Environment64.
[Environment64]
LIB="%@P%\..\lib64"
.
.
.
; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe
Thanks! Is this a known, reported bug?
On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile
a mixed c++/d project (DMD links to one c++ lib). Here is the
full error message:
fatal error C1905: Front end and back end not compatible (must
target same proces
On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile
a mixed c++/d project (DMD links to one c++ lib). Here is the
full error message:
Forgot most important info, ita an x64 project those used VS
linker by default af
On Friday, 10 June 2016 at 13:17:32 UTC, Steven Schveighoffer
wrote:
On 6/10/16 8:04 AM, Chris wrote:
I get the error below with code like this:
auto res = ['1', '2'].map!(a => a.to!string);
dmd 2.071.0
What's wrong here? I import std.algorithm, std.range,
std.array,
std.conv in the module.
On 6/10/16 8:04 AM, Chris wrote:
I get the error below with code like this:
auto res = ['1', '2'].map!(a => a.to!string);
dmd 2.071.0
What's wrong here? I import std.algorithm, std.range, std.array,
std.conv in the module.
(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10Inpu
On Friday, 10 June 2016 at 13:04:32 UTC, Chris wrote:
It doesn't compile with
`dmd file1.d file2.d`
either. I'll have to look into this. Weird.
looks like a clear sign of dmd versions conflict. most of the
time things like that caused by some leftover from previous dmd —
like old libphobos.
On Friday, 10 June 2016 at 12:52:05 UTC, Chris wrote:
I use dub and `dvm use 2.071.0`.
hm. sorry, i can't help you with this. straight "dmd test.d" is
ok, so it's probably something with dub/dvm interaction...
On Friday, 10 June 2016 at 13:00:23 UTC, ketmar wrote:
On Friday, 10 June 2016 at 12:52:05 UTC, Chris wrote:
I use dub and `dvm use 2.071.0`.
hm. sorry, i can't help you with this. straight "dmd test.d" is
ok, so it's probably something with dub/dvm interaction...
It doesn't compile with
`
On Friday, 10 June 2016 at 12:12:17 UTC, ketmar wrote:
On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote:
I get the error below with code like this:
auto res = ['1', '2'].map!(a => a.to!string);
dmd 2.071.0
What's wrong here? I import std.algorithm, std.range,
std.array, std.conv in the m
On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote:
I get the error below with code like this:
auto res = ['1', '2'].map!(a => a.to!string);
dmd 2.071.0
What's wrong here? I import std.algorithm, std.range,
std.array, std.conv in the module.
(.data._D65TypeInfo_xC3std5range10interfaces18_
On Monday, 6 June 2016 at 02:21:03 UTC, docandrew wrote:
On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:
On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
[...]
You can report it here: https://issues.dlang.org
[...]
On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:
On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
Should I report this as a dmd bug then? Not sure where / how
to do that.
You can report it here: https://issues.dlang.or
On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
Should I report this as a dmd bug then? Not sure where / how
to do that.
You can report it here: https://issues.dlang.org
I think I'll just let it go; I was able to work passed
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
> Should I report this as a dmd bug then? Not sure where / how to
> do that.
You can report it here: https://issues.dlang.org
> I think I'll just let it go; I was able to work passed it anyway
> using "static Note[] empty;", and `null` works to
On Sunday, 5 June 2016 at 20:16:54 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
static Note[0] empty;
Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}
It's likely an accepts-invalid bug
On 6/5/16, Anonymous via Digitalmars-d-learn
wrote:
> static Note[0] empty;
>
> Note[] getNotes(string id)
> {
> return (id in store) ? store[id] : empty;
> }
It's likely an accepts-invalid bug, meaning it should be a compiler
error instead. I d
On Sunday, 5 June 2016 at 18:45:36 UTC, docandrew wrote:
On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:
On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:
[...]
Should have included:
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reser
On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:
On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:
[...]
Should have included:
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns
On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:
Why does the following give a linker error?
If I change static Note[0] empty; to static Note[] empty;, all
is well.
Or if I leave it as Note[0] empty; and don't use it in
getNotes, all is well.
struct Note
{
string topic;
On Saturday, 23 April 2016 at 17:06:07 UTC, rcorre wrote:
On Saturday, 23 April 2016 at 00:55:07 UTC, rcorre wrote:
On Friday, 22 April 2016 at 10:25:34 UTC, Chris wrote:
[...]
No luck with cmain.d.
Its definitely an environmental problem -- I have an almost
identical Archlinux desktop that
On Saturday, 23 April 2016 at 00:55:07 UTC, rcorre wrote:
On Friday, 22 April 2016 at 10:25:34 UTC, Chris wrote:
On Friday, 22 April 2016 at 09:49:02 UTC, Rene Zwanenburg
wrote:
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos and
On Friday, 22 April 2016 at 10:25:34 UTC, Chris wrote:
On Friday, 22 April 2016 at 09:49:02 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos and
druntime, and with a custom entry point? I've never done
On Friday, 22 April 2016 at 09:49:02 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos and
druntime, and with a custom entry point? I've never done that
myself and don't remember how to do that off the t
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos and
druntime, and with a custom entry point? I've never done that
myself and don't remember how to do that off the top of my
head, but the info should be somewhere on dlang.org.
I
On Thursday, 21 April 2016 at 12:57:36 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 11:54:27 UTC, rcorre wrote:
Thanks for the tip. Here's the linking code it shows:
cc d.o -o d -m64 -L/usr/lib -L/usr/lib32 -Xlinker
--export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker
-Bdynami
On Thursday, 21 April 2016 at 11:54:27 UTC, rcorre wrote:
Thanks for the tip. Here's the linking code it shows:
cc d.o -o d -m64 -L/usr/lib -L/usr/lib32 -Xlinker
--export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic
-lpthread -lm -lrt -ldl
/usr/bin/ld: d.o: relocation R_X86_64_32 a
On Thursday, 21 April 2016 at 09:55:30 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 01:20:27 UTC, rcorre wrote:
s/compile/link
I _can_ compile a D library, but as soon as I try to link
anything compiled with DMD it falls over.
What is dmd's verbose output? (add -v switch)
Some o
On Thursday, 21 April 2016 at 01:20:27 UTC, rcorre wrote:
s/compile/link
I _can_ compile a D library, but as soon as I try to link
anything compiled with DMD it falls over.
What is dmd's verbose output? (add -v switch)
Some of the things it outputs are the location of the config file
it uses
On Thursday, 21 April 2016 at 01:20:27 UTC, rcorre wrote:
s/compile/link
I _can_ compile a D library, but as soon as I try to link
anything compiled with DMD it falls over.
Sorry, I didn't see the code in your first post. I tried it
myself (in only have 2.070.2) and it worked fine.
Have y
On Thursday, 21 April 2016 at 01:18:14 UTC, rcorre wrote:
On Wednesday, 20 April 2016 at 19:24:49 UTC, Chris wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making
On Wednesday, 20 April 2016 at 19:24:49 UTC, Chris wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding s
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit statu
On Wednesday, 20 April 2016 at 12:48:46 UTC, rcorre wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit statu
On Thursday, 12 November 2015 at 06:11:37 UTC, BBasile wrote:
On Thursday, 12 November 2015 at 06:03:49 UTC, BBasile wrote:
It worked fine because it was not used, not parsed, not
linked. Maybe just the functions declarations was parsed to
solve the symbols in the program, but since none was us
On Thursday, 12 November 2015 at 06:03:49 UTC, BBasile wrote:
It worked fine because it was not used, not parsed, not linked.
Maybe just the functions declarations was parsed to solve the
symbols in the program, but since none was used the 'import
blas.blas' was eliminated or something like tha
On Thursday, 12 November 2015 at 05:44:37 UTC, Stiff wrote:
On Thursday, 12 November 2015 at 05:17:58 UTC, BBasile wrote:
On Thursday, 12 November 2015 at 02:02:56 UTC, Stiff wrote:
Possibly a dumb question, I'm not sure.
[...]
undefined reference to `cblas_dgemm'
collect2: error: ld returned 1
On Thursday, 12 November 2015 at 05:17:58 UTC, BBasile wrote:
On Thursday, 12 November 2015 at 02:02:56 UTC, Stiff wrote:
Possibly a dumb question, I'm not sure.
[...]
undefined reference to `cblas_dgemm'
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.
On Thursday, 12 November 2015 at 02:02:56 UTC, Stiff wrote:
Possibly a dumb question, I'm not sure.
[...]
undefined reference to `cblas_dgemm'
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.
Any suggestions? I do have a blas library installed, but the
c
On Friday, 2 October 2015 at 14:03:08 UTC, John Colvin wrote:
On Friday, 2 October 2015 at 09:43:54 UTC, Chris wrote:
Why do I get this error msg with dmd 2.067.1 and 2.068.0 in
release mode:
$ dub --build=release
(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__
On Friday, 2 October 2015 at 09:43:54 UTC, Chris wrote:
Why do I get this error msg with dmd 2.067.1 and 2.068.0 in
release mode:
$ dub --build=release
(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
undefined reference to
`_D64TypeInfo_C3std5range
Raised as a bug:
http://d.puremagic.com/issues/show_bug.cgi?id=11439
On Friday, 1 November 2013 at 16:24:09 UTC, Gary Willoughby wrote:
On Friday, 1 November 2013 at 15:32:54 UTC, Daniel Davidson
wrote:
An alternative is to move the import statements in test1.d out
of the unittest block, which becomes a function, to file
scope. Then if you have multiple unittest
On Friday, 1 November 2013 at 15:32:54 UTC, Daniel Davidson wrote:
An alternative is to move the import statements in test1.d out
of the unittest block, which becomes a function, to file scope.
Then if you have multiple unittests in test1.d all are covered
and the symbols are available.
...
v
On Friday, 1 November 2013 at 12:59:24 UTC, Gary Willoughby wrote:
I have a small test case that displays a linker error. I
wondered if this is an issue with the tool chain or whether i'm
doing something wrong.
I have a simple directory structure like this:
test/methods.d
test/test1.d
test/te
On Friday, 11 October 2013 at 22:33:31 UTC, Namespace wrote:
On Friday, 11 October 2013 at 21:16:38 UTC, Brad Roberts wrote:
It's due to having the destructor versioned out when building
foo and visible when building bar. When brought together,
you've created an incompatible whole. There's no
On Friday, 11 October 2013 at 21:16:38 UTC, Brad Roberts wrote:
It's due to having the destructor versioned out when building
foo and visible when building bar. When brought together,
you've created an incompatible whole. There's no destructor
actually included in foo's .o file that you told i
Ok, that is what I wanted to hear.
It's due to having the destructor versioned out when building foo and visible when building bar.
When brought together, you've created an incompatible whole. There's no destructor actually
included in foo's .o file that you told it it could expect to find.
There's no bug in the compiler or lin
It's annoying and I don't get it. What is the problem of Optlink?
I tried version(unittest) instead of debug. It works then with
-debug, but if you compile with -unittest you get the same error.
On Wednesday, 29 May 2013 at 21:17:29 UTC, Namespace wrote:
Why is the phobos lib automatically detected with dmd 2.062 ,
but not with 2.063?
Any other answer? I have the same problem again.
And I hate it.
On Tuesday, 10 September 2013 at 10:42:44 UTC, Gary Willoughby
wrote:
On Friday, 16 August 2013 at 09:52:53 UTC, Gary Willoughby
wrote:
You might be onto something here as i only import this module
into unit tests. When i get time i'll investigate a little
further.
If i take the import out of
On Friday, 16 August 2013 at 09:52:53 UTC, Gary Willoughby wrote:
You might be onto something here as i only import this module
into unit tests. When i get time i'll investigate a little
further.
If i take the import out of the unit test and place it at the top
of my source file everything wo
On Friday, 16 August 2013 at 06:39:42 UTC, Jacob Carlborg wrote:
No, I don't think so. At least on Mac OS X it always tell you
the architecture:
void foo();
void main ()
{
foo();
}
Undefined symbols for architecture x86_64:
"_D4main3fooFZv", referenced from:
__Dmain in main.d.o
ld
On Thursday, 15 August 2013 at 18:54:40 UTC, Jesse Phillips wrote:
I don't have an answer, but in case you are not familiar with
cryptic linker:
On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby
wrote:
But when i import it and use the getUnixTime function i get
the following linke
On 2013-08-15 20:54, Jesse Phillips wrote:
I don't have an answer, but in case you are not familiar with cryptic
linker:
On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby wrote:
But when i import it and use the getUnixTime function i get the
following linker error:
Undefined symbol
I don't have an answer, but in case you are not familiar with
cryptic linker:
On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby
wrote:
But when i import it and use the getUnixTime function i get the
following linker error:
Undefined symbols for architecture x86_64:
The linker i
On Wednesday, 14 August 2013 at 16:11:38 UTC, Gary Willoughby
wrote:
...
Hm, I remember I had similar issue once which faded away once I
have stopped naming main module as `main`. Was not able to track
exact conditions to trigger it - this may be something similar.
On Wednesday, 14 August 2013 at 14:05:07 UTC, Jacob Carlborg
wrote:
Have you compiled all the files? Show us the command you use to
compile your code. Usually this is enough "rdmd main.d", where
"main.d" is the file containing the main function.
I'm sure all source files are compiled during th
On 2013-08-14 15:21, Gary Willoughby wrote:
I have defined the following module:
/**
* Module containing unit test helper functions for date time operations.
*/
module common.test.unit.datetime;
/**
* Imports.
*/
import std.conv;
import std.datetime;
/**
* Return a unix timestamp.
On Wednesday, 29 May 2013 at 21:17:29 UTC, Namespace wrote:
Why is the phobos lib automatically detected with dmd 2.062 ,
but not with 2.063?
I dunno, I suspected the sc.ini to be modified in some way, but
surprisingly nothing changed in there. Anyway I just built a
trivial sample program w/o
Why is the phobos lib automatically detected with dmd 2.062 , but
not with 2.063?
On Wednesday, 29 May 2013 at 06:19:33 UTC, Namespace wrote:
Davis (Debug) wird erzeugt
pragma(lib, "D:\\D\\dmd2\\windows\\lib\\phobos.lib");
Might help. Please try to define this somewhere in your code -
specifying the library in the project might also be sufficient.
Solution:
pragma(lib, "D:\\D\\dmd2\\windows\\lib\\phobos.lib");
I have to link the phobos lib by myself. o.O
Davis (Debug) wird erzeugt
Performing main compilation...
Current dictionary:
C:\Users\Besitzer\Documents\Projects\Davis\Davis
D:\D\dmd2\windows\bin\dmd.exe -debug -gc "main.d"
"-ID:\D\dmd2\src\ext" "-ID:\D\dmd2\src\druntime\import"
"-ID:\D\dmd2\src\phobos" "-odobj\Debug"
"-ofC:\Users\Bes
On Tuesday, 28 May 2013 at 22:28:50 UTC, Namespace wrote:
I don't even understand the error. Where is a previous
definition? And why?
Seems like I have to switch back to 2.062.
In the case of using Mono-D,
could you give me your build log please? That might help!
When copypasting the command,
I don't even understand the error. Where is a previous
definition? And why?
Seems like I have to switch back to 2.062.
This is still there with the new release of 2.063.
[quote]
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
Graphics.lib(object) Offset 201F6H Record Type 0091
Error 1: Previous Definition Different :
1 - 100 of 114 matches
Mail list logo
