www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - noob string concatenation help.

reply anupam kapoor <anupam.kapoor gmail.com> writes:
hi all,

i am trying out a trivial string concatenation sample like this :

,----
| void do_string_test()
| {
|         char[] s;
|         writefln("Length: %d\tString: '%s'", s.length, s);
|         
|         s ~= "something ";
|         writefln("Length: %d\tString: '%s'", s.length, s);
|         
|         s ~= "whatever";
|         writefln("Length: %d\tString: '%s'", s.length, s);
| }
`----

however, i get the following link errors:

gcc string.o -o obj/string-test -m32 -lphobos -lpthread -lm 
string.o: In function `_Dmain':
string.d:(.gnu.linkonce.t_Dmain+0x45): undefined reference to `_d_arrayappendT'
string.d:(.gnu.linkonce.t_Dmain+0x78): undefined reference to `_d_arrayappendT'
collect2: ld returned 1 exit status
--- errorlevel 1

can you please help ? is my installation br0ken ? i have used stuff from the
wiki4d for setting up
the environment.

thank you
anupam
Apr 13 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
anupam kapoor wrote:
[snip]

 however, i get the following link errors:
 
 gcc string.o -o obj/string-test -m32 -lphobos -lpthread -lm 
 string.o: In function `_Dmain':
 string.d:(.gnu.linkonce.t_Dmain+0x45): undefined reference to `_d_arrayappendT'
 string.d:(.gnu.linkonce.t_Dmain+0x78): undefined reference to `_d_arrayappendT'
 collect2: ld returned 1 exit status
 --- errorlevel 1
 
 can you please help ? is my installation br0ken ? i have used stuff from the
wiki4d for setting up
 the environment.


It looks like you're trying to use a new DMD with an old Phobos. You 
should check your import paths for a leftover libphobos.a from a 
previous installation.
Apr 13 2007
parent reply anupam kapoor <anupam.kapoor gmail.com> writes:
Frits van Bommel Wrote:

 It looks like you're trying to use a new DMD with an old Phobos. You 
 should check your import paths for a leftover libphobos.a from a 
 previous installation.


strange...probably copied the wrong version of file over. is it possible to
find out the version of
compiler (front-end) that i am currently using, something similar to "gcc
--version" thinge ?

thank you
anupam
Apr 13 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
anupam kapoor wrote:

 Frits van Bommel Wrote:

 It looks like you're trying to use a new DMD with an old Phobos. You 
 should check your import paths for a leftover libphobos.a from a 
 previous installation.


 strange...probably copied the wrong version of file over. is it possible to
find out the version of
 compiler (front-end) that i am currently using, something similar to "gcc
--version" thinge ?


The DMD version can be determined by simply typing 'dmd' at the command 
line. It's on the first line, so (on Linux) 'dmd | head -n 1' will 
remove all the extra stuff.

Also interesting would be the version of Phobos it's finding (since that 
seems to be older than your DMD). I'm not sure if there's a good way to 
determine this other than manually checking the import paths DMD 
searches for libphobos.a, and comparing the date to DMD release dates...
Apr 13 2007
parent reply anupam kapoor <anupam.kapoor gmail.com> writes:
Frits van Bommel Wrote:


 
 The DMD version can be determined by simply typing 'dmd' at the command 
 line. It's on the first line, so (on Linux) 'dmd | head -n 1' will 
 remove all the extra stuff.


thanks ! 


 Also interesting would be the version of Phobos it's finding (since that 
 seems to be older than your DMD). I'm not sure if there's a good way to 
 determine this other than manually checking the import paths DMD 
 searches for libphobos.a, and comparing the date to DMD release dates...


true. 

is there a strict one-to-one relationship between libphobos and D releases i.e.
libphobos-ver-X goes _only_ with d-version-X ? it does feel a bit odd to have
that kind of 
restriction though.

anupam
Apr 13 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
anupam kapoor wrote:

 is there a strict one-to-one relationship between libphobos and D releases i.e.
 libphobos-ver-X goes _only_ with d-version-X ? it does feel a bit odd to have
that kind of 
 restriction though.


You can probably use "close" Phobos versions most of the time, but 
sometimes incompatibilities are introduced. For this reason it's 
typically best to just use the Phobos version corresponding to your DMD 
version, unless you have a good reason not to.

The particular incompatibility causing your problem was IIRC introduced 
when the improved GC got implemented just after v1.00 and memory 
allocation started needing the TypeInfo for the allocated memory.
Apr 13 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:evoor3$1n4g$1 digitalmars.com...

 The particular incompatibility causing your problem was IIRC introduced 
 when the improved GC got implemented just after v1.00 and memory 
 allocation started needing the TypeInfo for the allocated memory.


It might have been the array resize and append improvements in 1.010 as 
well.
Apr 13 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:

 "Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
 news:evoor3$1n4g$1 digitalmars.com...

 The particular incompatibility causing your problem was IIRC introduced 
 when the improved GC got implemented just after v1.00 and memory 
 allocation started needing the TypeInfo for the allocated memory.


 
 It might have been the array resize and append improvements in 1.010 as 
 well. 


No, I'm actually pretty sure the variants ending in 'T' were introduced 
at the time of the new GC. The postfix 'T' seems to indicate it needs 
TypeInfo. Because those functions are extern(C) they aren't mangled, so 
if the argument lists need to change they are renamed to reflect that. 
(The most likely reason they're extern(C) is probably _because_ it 
disables mangling, removing the need to hard-code their module names 
into the compiler)

P.S. Also, _d_arrayappendT happens to be in phobos/internal/gc/gc.d in 
an unzipped v1.009 tree I happened to have handy :).
Apr 14 2007
prev sibling parent Georg Wrede <georg nospam.org> writes:
Frits van Bommel wrote:

 anupam kapoor wrote:
 

 is there a strict one-to-one relationship between libphobos and D 
 releases i.e.
 libphobos-ver-X goes _only_ with d-version-X ? it does feel a bit odd 
 to have that kind of restriction though.


 
 You can probably use "close" Phobos versions most of the time, but 
 sometimes incompatibilities are introduced. For this reason it's 
 typically best to just use the Phobos version corresponding to your DMD 
 version, unless you have a good reason not to.


I'd say one should *never* use anything but the compiler's own libphobos 
version.

(While some gurus might get away with it, some of the time, I can see no 
reason even for them to do it. It's simply asking for trouble.)

Especially when one is learning the language (whether a noob or a 
20-year C++ guru), the wrong version would be simply another place 
causing unexpected behavior. And even worse if it "seems to work" in the 
beginning. Then one forgets about having a wrong version, and people 
trying to help here probably can't always guess it's a version problem.

Even if they could, it'd waste everybody's time.

Certainly, Walter has never promised to even think about anybody using 
"a wrong libphobos version". This means that subtle changes can and will 
be introduced whenever needed, and most of the time they aren't 
explained in the changelog. Only some of the bigger things are.
May 09 2007
prev sibling parent anupam kapoor <anupam.kapoor gmail.com> writes:
 gcc string.o -o obj/string-test -m32 -lphobos -lpthread -lm 
 string.o: In function `_Dmain':
 string.d:(.gnu.linkonce.t_Dmain+0x45): undefined reference to `_d_arrayappendT'
 string.d:(.gnu.linkonce.t_Dmain+0x78): undefined reference to `_d_arrayappendT'
 collect2: ld returned 1 exit status


replying to self.

the undefined symbol is present in libphobos.a, somehow dmd cannot find it. if
i try a "manual" link via gcc using:
"gcc string.o -o obj/st -m32 -L/usr/local/lib -lphobos -lpthread -lm" it just
works.

here is how my /etc/dmd.conf looks:
,----

| [Environment]
| DFLAGS="-I/usr/local/lib/phobos -L-L/usr/local/lib"
`----
the phobos sources are in /usr/local/lib/phobos while, libphobos.a is in
/usr/local/lib.

anupam
Apr 13 2007