I am trying compile etc.bigint from Deimos into a static library (in linux), but I am having huge problems! Am I just doing something stupid, or is this a dmd bug?

I try the following:
Compile all .d files with dmd -c (everything compiles)
Gather all .o files: ar rcs libbigint.a *.o
Compile the following program:

--------------
import etc.bigint.bigint;
import std.stdio;

void main()
{
Int i = Int(2);
i = i * 12;
writefln(i.toInt);
writefln(i.toString);
}
--------------

with dmd inttest.d -L-lbigint

This compiles but linking gives lots of undefined references. Most are to the Int invariant, but some are to _d_switch_string or similar. Giving bigint_int.o explicitly to dmd removes the errors, except one reference to _d_switch_string. For some reason including radix.o removes this error as well. (Both these should already be part of libbigint.a).

The program outputs the following when run:
24
Segmentation Fault

Can anyone reproduce this error? Any help would be greatly appreciated.

Nick

Ignore the segfault below, I've traced it down to an unrelated error.

In article <cgncq3$1le5$1@digitaldaemon.com>, Nick says...
>
>I am trying compile etc.bigint from Deimos into a static library (in linux), but I am having huge problems! Am I just doing something stupid, or is this a dmd bug?
>
>I try the following:
>Compile all .d files with dmd -c (everything compiles)
>Gather all .o files: ar rcs libbigint.a *.o
>Compile the following program:
>
>--------------
>import etc.bigint.bigint;
>import std.stdio;
>
>void main()
>{
>Int i = Int(2);
>i = i * 12;
>writefln(i.toInt);
>writefln(i.toString);
>}
>--------------
>
>with dmd inttest.d -L-lbigint
>
>This compiles but linking gives lots of undefined references. Most are to the Int invariant, but some are to _d_switch_string or similar. Giving bigint_int.o explicitly to dmd removes the errors, except one reference to _d_switch_string. For some reason including radix.o removes this error as well. (Both these should already be part of libbigint.a).
>
>The program outputs the following when run:
>24
>Segmentation Fault
>
>Can anyone reproduce this error? Any help would be greatly appreciated.
>
>Nick
>
>

In article <cgncq3$1le5$1@digitaldaemon.com>, Nick says...

Oh no! I hope someone can help you sort this out, because I've only ever tested this on Windows. Assuming you succeed, I'd really like to understand both the problem and its resolution.

I wish I could help, but I'm just not a Linux person. I know there's nothing Windows-specific in there.

Jill


>
>I am trying compile etc.bigint from Deimos into a static library (in linux), but I am having huge problems! Am I just doing something stupid, or is this a dmd bug?
>
>I try the following:
>Compile all .d files with dmd -c (everything compiles)
>Gather all .o files: ar rcs libbigint.a *.o
>Compile the following program:
>
>--------------
>import etc.bigint.bigint;
>import std.stdio;
>
>void main()
>{
>Int i = Int(2);
>i = i * 12;
>writefln(i.toInt);
>writefln(i.toString);
>}
>--------------
>
>with dmd inttest.d -L-lbigint
>
>This compiles but linking gives lots of undefined references. Most are to the Int invariant, but some are to _d_switch_string or similar. Giving bigint_int.o explicitly to dmd removes the errors, except one reference to _d_switch_string. For some reason including radix.o removes this error as well. (Both these should already be part of libbigint.a).
>
>The program outputs the following when run:
>24
>Segmentation Fault
>
>Can anyone reproduce this error? Any help would be greatly appreciated.
>
>Nick
>
>

In article <cgncq3$1le5$1@digitaldaemon.com>, Nick says...
>
>I am trying compile etc.bigint from Deimos into a static library (in linux),

>with dmd inttest.d -L-lbigint
>
>This compiles but linking gives lots of undefined references.

I always link on a separate step (with gcc ...)
and often have undefined references that go away when the order
of the libs pass to the linker is changed.
I don't know why, if it's related to your problem,
if it's a common problem or if it's someting I'm doing wrong.

Ant

"Nick" <Nick_member@pathlink.com> wrote in message news:cgncq3$1le5$1@digitaldaemon.com...
> Giving bigint_int.o
> explicitly to dmd removes the errors, except one reference to
_d_switch_string.

_d_switch_string is defined in libphobos.a in module internal/switch.d.

In article <cgnhf8$1npg$1@digitaldaemon.com>, Ant says...
>
>I always link on a separate step (with gcc ...)
>and often have undefined references that go away when the order
>of the libs pass to the linker is changed.
>I don't know why, if it's related to your problem,
>if it's a common problem or if it's someting I'm doing wrong.
>

Thank you, this solves it. Apparently the gnu linker, ld, only searches files in the order specified. So I have to specify libbigint _before_ libphobos. You can get around this by specifying libraries multiple times, or by using the --start-group/--end-group parameters. All this is clearly stated in the man file, which I should have read before complaining here :)

Nick

In article <cgnedd$1m7l$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cgncq3$1le5$1@digitaldaemon.com>, Nick says...
>
>Oh no! I hope someone can help you sort this out, because I've only ever tested this on Windows. Assuming you succeed, I'd really like to understand both the problem and its resolution.

It turned out to be a trivial linker usage problem.

By the way, the Karatsuba implementation seems to contain a bug. The following multiplication fails:

---------------------
Int i = Int("9404835527576434225246446545397488797239");
Int j = Int("9347137150106640150244934603401185184986");
i = i * j;
---------------------
with: "Error: AssertError Failure multiply.d(144)"

Compiling multiply.d with -version=DisableKaratsuba solves it.

Nick

In article <cgqae3$30j2$1@digitaldaemon.com>, Nick says...

>By the way, the Karatsuba implementation seems to contain a bug.

Okay, thanks. I haven't looked at the Int code for a while because I've been spending too much time on etc.unicode (which it looks like we're now going to replace). I will look into it.

Jill