[D Programming] Using Codeblocks with Tango

[doctor_vitus]

Hi all!

Is there any proper way of programming with Tango under Codeblocks? I cannot figure out any way of configuring build tools like Build or Rebuild.

As a workaround, I compiled my main source module once using Rebuild. Then I added the so generated Tango libraries to the Codeblocks Project. This works so far, but it's far from comfortable, and I was not able to use the debugging functionality this way (any breakpoints seem to be ignored), wheres the debugger works fine for Phobos projects.

My system: Ubuntu 7.04 (Feisty), DMD 1.014, gdb, current Nightly Build of Codeblocks.

Thanks and best regards,
Vitus

[stahta01]

I can not answer your questions.

Heres, information for the others, who never heard of tango, it is a software library.

http://www.dsource.org/projects/tango

Tim S

[doctor_vitus]

Sorry for not explaining.

Tango is an alternative (and IMHO much better) runtime library for the D Programming Language. The standard runtime library is called Phobos.

[afb]

Is there any proper way of programming with Tango under Codeblocks?

By default the standard (Phobos) library is assumed, like with the wizards and such.

But you should be able to switch to using Tango insted, provided you add the required
versions such as "Tango" and "Posix" and the required librararies such as "libgtango.a"

I cannot figure out any way of configuring build tools like Build or Rebuild.

Code::Blocks uses a built-in system to compile/link, so it doesn't call external tools
like make or rebuild. This also means that it won't automatically include any imports.

Support for the D language might improve later, but for now it is treated like C/C++.

[doctor_vitus]

No, just adding libgtango.a unfortunately won't do (you'ld get a lot of 'undefined reference' messages from the linker this way). The binary libraries of the Tango modules have to be added as well. They are created in the source folder if you use Build or Rebuild [1], and you can add them in Codeblocks afterwards, but (as I wrote) I don't consider this a comfortable and 'straight' way of working. And even worse: I cannot debug such projects.

[1] For my current project, the list of generated Tango libraries looks like this:

tango.core.Type.o
tango.io.Buffer.o
tango.io.Conduit.o
tango.io.Console.o
tango.io.DeviceConduit.o
[...]
tango.text.String.o
tango.text.Util.o
tango.util.time.Utc.o

Edit:
I'm pretty astonished. I reinstalled the binary version of Tango and tried to compile my project with only libtango.a again some a couple of minutes ago, and now it worked, after it had always failed before (with my self compiled tango library). And even the debugger works now!

I don't understand why, but I think you can consider this issue solved.

Thanks! :-)

[afb]

I'm pretty astonished. I reinstalled the binary version of Tango and tried to compile my project with only libtango.a again some a couple of minutes ago, and now it worked, after it had always failed before (with my self compiled tango library). And even the debugger works now!

There are two libraries called "tango", one is a component of the runtime - another all modules.

I think they renamed the part of the runtime to something else, in order to avoid confusion...
But it would explain why it would fail before, and why it would work now (like you'd expect)

For practical purposes, I only use two libraries with Tango: "libgphobos.a" and "libgtango.a"
Where the second is optional when using Rebuild, as it will pick up the sources if left out.

Great that it works now, though. If you have any other bugs or suggestions, do post them too.

[Vladsharp]

I need some help on using tango...

I'm a gentoo user (gcc-4.2.0, dmd-bin 1.014, tango 0.98)

This is the problem I'm trying to compile:

Code Select Expand

import tango.io.Console;

alias char[] String;


void main(String[] args)
{


Cout("Hello, world!").newline;
}


When I do "dmd hello.d" the program compiles and runs fine.

The following output is produced:

Code Select Expand

gcc hello.o -o hello -m32 -Xlinker /opt/dmd/lib/libtango.a -Xlinker -L/opt/dmd/bin/../lib -lphobos -lpthread -lm
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.

Now, Codeblock doesn't want to play nice with it...
After some time of playing with it, all I can get is:

Code Select Expand

-------------- Build: Debug in TestingProject ---------------
Linking console executable: bin/Debug/TestingProject
obj/Debug/hello.o:(.data+0x30): undefined reference to `_D5tango2io7Console12__ModuleInfoZ'
obj/Debug/hello.o: In function `_Dmain':
/root/projects/TestingProject/hello.d:8: undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output'
/root/projects/TestingProject/hello.d:9: undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output'
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.
collect2: ld returned 1 exit status

I have a feeling it's a matter of doing something basic right, but please - it's quite frustrating not to be able to use codeblocks to compile. Thanks for your help

[Auria]

-lphobos

You're still linking against phobos

[Vladsharp]

-lphobos

You're still linking against phobos

I realise that, but that's what dmd does (I've posted its output from the CLI above) - and since the program runs fine, what do you suggest?

[afb]

-lphobos

You're still linking against phobos

Tango also has a replacement library called "libphobos.a", because that name is hardcoded within DMD.

I realise that, but that's what dmd does (I've posted its output from the CLI above) - and since the program runs fine, what do you suggest?

It seems that your command-line call to DMD is linking in libtango.a, but that Code::Blocks does not ?

[Vladsharp]

I realise that, but that's what dmd does (I've posted its output from the CLI above) - and since the program runs fine, what do you suggest?

It seems that your command-line call to DMD is linking in libtango.a, but that Code::Blocks does not ?

Yes, it seems like that. When I add "-Xlinker /opt/dmd/lib/libtango.a -Xlinker -L/opt/dmd/bin/../lib" to C::B linker options, it still comes with the error.

Is there a way to see the full command line arguments for dmd/gcc linker?

[Auria]

-Xlinker /opt/dmd/lib/libtango.a

This is just a guess - but are you sure you need -Xlinker ? AFAIK C::B compiles D code just like C++ code, meaning that it compiles each file into an object file and then calls the linker - if so you don't need -Xlinker

For full command :
Compiling: Settings -> Compiler and Debugger -> Tab "Other" -> Compiler logging = "Full command line".

(thanks to Morten's signature )

[Vladsharp]

-Xlinker /opt/dmd/lib/libtango.a

This is just a guess - but are you sure you need -Xlinker ? AFAIK C::B compiles D code just like C++ code, meaning that it compiles each file into an object file and then calls the linker - if so you don't need -Xlinker

For full command :
Compiling: Settings -> Compiler and Debugger -> Tab "Other" -> Compiler logging = "Full command line".

(thanks to Morten's signature )

Here's what DMD does:

Code Select Expand

gcc hello.o -o hello -m32 -Xlinker /opt/dmd/lib/libtango.a -Xlinker -L/opt/dmd/bin/../lib -lphobos -lpthread -lm
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object

And in C::B

Code Select Expand

gcc -o bin/Debug/Test -m32 -Xlinker /opt/dmd/lib/libtango.a -Xlinker -L/opt/dmd/bin/../lib  obj/Debug/hello.o  -lpthread -lm -lphobos
obj/Debug/hello.o:(.data+0x40): undefined reference to `_D5tango2io6Stdout12__ModuleInfoZ'
obj/Debug/hello.o: In function `_Dmain':
........

Hmnnn. The order doesn't look correct.

[Vladsharp]

Solved the problem - as I guessed, it was the order of command-line options...

In C::B, the default for linking D programs is: "$linker -o $exe_output $link_options $link_objects $libs"

But the program links only correctly with: "$linker $link_objects -o $exe_output $link_options $libs"

Can this be made default in C::B because I suspect it's not just me that could pop into the problem some day with the dmd compiler...?