Re: Compile Phobos library ?
Hello GG, Hello ! I have already used gdb to debug program compiled with dmd, but never link gdb with DMD at same time. I found on google something like this : nameofprogram -g -d gdb But when I try with DMD like : DMD -g -d gdb [...] , the compiler DMD look for a .d file (cannot read file gdb.d) Of course, it's normal. So could you explain me how to link gdb with DMD ? Is there an option parameter to pass to DMD? I was suggesting running DMD under the debugger as you would any other program: gdb dmd r -g -d files.d You might have to make a debug build of DMD but that's easy (a one line change in linux.mak and run it) -- ... <
Re: Compile Phobos library ?
Hello ! I have already used gdb to debug program compiled with dmd, but never link gdb with DMD at same time. I found on google something like this : nameofprogram -g -d gdb But when I try with DMD like : DMD -g -d gdb [...] , the compiler DMD look for a .d file (cannot read file gdb.d) Of course, it's normal. So could you explain me how to link gdb with DMD ? Is there an option parameter to pass to DMD? Thanks ! GG
Re: Compile Phobos library ?
Hello GG, DMD2.040 on linux: When I try to build phobos library with make -f linux.mak, I got : [...] make: *** [obj/posix/release/libphobos2.a] Segmentation fault (core dumped) libdruntime.a is needed, so I compiled it and got no error, but libphobos2.a doesn't build. Am I missing something ? can you try that with a debug build of DMD under GDB and get a stack trace? It might help finding/fixing the error. Thanks ! GG -- ... <
Re: DMD on x86_64
On 15/02/10 15:54, Robert Clipsham wrote: I've been wanting to try D2 properly for a while now, but as I use linux x86-64 I've had to resort to using a virtual machine, which is really off putting when I just want to play around with it. I've read multiple threads about getting dmd working with a multilib system, but I still can't get it working, here's what I've tried: I managed to get it working! Took a lot of effort, but in short: % yaourt -S lib32-glibc-multilib # The next step should be yaourt -S gcc-multilib, but the package # is broken currently, and I suspect most people don't really want # to install another locale and wait over an hour for gcc to compile # only to find you forgot something and have to start again, so... % cd /tmp # I've uploaded my precompiled version of gcc-multilib with the tweaks # I needed to compile already done, removing the need to install new # locales and wait for gcc to compile, aren't I nice? # I might even post newer versions here when the package is updated on # AUR :) % wget http://omploader.org/vM2w4cw # I know this step looks questionable, it's needed though (try skipping # it if you want a reason) % sudo pacman -Rd gcc lib32-glibc lib32-glibc-multilib lib32-gcc-libs # And install gcc-multilib % sudo pacman -U gcc-multilib-4.4.2-10-x86_64.pkg.tar.gz # You should now be able to use dmd :) % cat > hello.d
Re: Compile Phobos library ?
On 02/17/2010 07:09 PM, GG wrote: DMD2.040 on linux: When I try to build phobos library with make -f linux.mak, I got : dmd -w -O -release -nofloat -d -lib -ofobj/posix/release/libphobos2.a crc32.d std/algorithm.d std/array.d std/atomics.d std/base64.d std/bigint.d std/bitmanip.d std/boxer.d std/compiler.d std/complex.d std/contracts.d std/conv.d std/cpuid.d std/cstream.d std/ctype.d std/date.d std/datebase.d std/dateparse.d std/demangle.d std/encoding.d std/file.d std/format.d std/functional.d std/getopt.d std/intrinsic.d std/iterator.d std/json.d std/loader.d std/math.d std/md5.d std/metastrings.d std/mmfile.d std/numeric.d std/outbuffer.d std/path.d std/perf.d std/process.d std/random.d std/range.d std/regex.d std/regexp.d std/signals.d std/socket.d std/socketstream.d std/stdint.d std/stdio.d std/stdiobase.d std/stream.d std/string.d std/syserror.d std/system.d std/traits.d std/typecons.d std/typetuple.d std/uni.d std/uri.d std/utf.d std/variant.d std/xml.d std/zip.d std/zlib.d std/c/stdarg.d std/c/stdio.d etc/c/zlib.d std/c/linux/linux.d std/c/linux/socket.d obj/posix/release/etc/c/zlib /adler32.o obj/posix/release/etc/c/zlib/compress.o obj/posix/release/etc/c/zlib/crc32.o obj/posix/release/etc/c/zlib/gzio.o obj/posix/release/etc/c/zlib/uncompr.o obj/posix/release/etc/c/zlib/deflate.o obj/posix/release/etc/c/zlib/trees.o obj/posix/release/etc/c/zlib/zutil.o obj/posix/release/etc/c/zlib/inflate.o obj/posix/release/etc/c/zlib/infback.o obj/posix/release/etc/c/zlib/inftrees.o obj/posix/release/etc/c/zlib/inffast.o libdruntime.a make: *** [obj/posix/release/libphobos2.a] Segmentation fault (core dumped) libdruntime.a is needed, so I compiled it and got no error, but libphobos2.a doesn't build. Am I missing something ? Thanks ! GG fwiw, I tried compiling a project I wrote last semester with 2.040 (and 2.038) a few days ago and got the same output. Something in DMD seems to have broken since 2.035
Compile Phobos library ?
DMD2.040 on linux: When I try to build phobos library with make -f linux.mak, I got : dmd -w -O -release -nofloat -d -lib -ofobj/posix/release/libphobos2.a crc32.d std/algorithm.d std/array.d std/atomics.d std/base64.d std/bigint.d std/bitmanip.d std/boxer.d std/compiler.d std/complex.d std/contracts.d std/conv.d std/cpuid.d std/cstream.d std/ctype.d std/date.d std/datebase.d std/dateparse.d std/demangle.d std/encoding.d std/file.d std/format.d std/functional.d std/getopt.d std/intrinsic.d std/iterator.d std/json.d std/loader.d std/math.d std/md5.d std/metastrings.d std/mmfile.d std/numeric.d std/outbuffer.d std/path.d std/perf.d std/process.d std/random.d std/range.d std/regex.d std/regexp.d std/signals.d std/socket.d std/socketstream.d std/stdint.d std/stdio.d std/stdiobase.d std/stream.d std/string.d std/syserror.d std/system.d std/traits.d std/typecons.d std/typetuple.d std/uni.d std/uri.d std/utf.d std/variant.d std/xml.d std/zip.d std/zlib.d std/c/stdarg.d std/c/stdio.d etc/c/zlib.d std/c/linux/linux.d std/c/linux/socket.d obj/posix/release/etc/c/zlib/! adler32.o obj/posix/release/etc/c/zlib/compress.o obj/posix/release/etc/c/zlib/crc32.o obj/posix/release/etc/c/zlib/gzio.o obj/posix/release/etc/c/zlib/uncompr.o obj/posix/release/etc/c/zlib/deflate.o obj/posix/release/etc/c/zlib/trees.o obj/posix/release/etc/c/zlib/zutil.o obj/posix/release/etc/c/zlib/inflate.o obj/posix/release/etc/c/zlib/infback.o obj/posix/release/etc/c/zlib/inftrees.o obj/posix/release/etc/c/zlib/inffast.o libdruntime.a make: *** [obj/posix/release/libphobos2.a] Segmentation fault (core dumped) libdruntime.a is needed, so I compiled it and got no error, but libphobos2.a doesn't build. Am I missing something ? Thanks ! GG
Re: DMD on x86_64
Robert Clipsham Wrote: > On 17/02/10 06:05, Jesse Phillips wrote: > > Oh, yeah Arch dropped most efforts to support 32bit didn't they. This > > I'm pretty sure they didn't... maybe they did on x86_64, I don't know. > > > probably won't help but maybe trying > > > > dmd test.d -L-L/opt/lib32/lib -L-melf_i386 > > Already tried this, no luck :( > > > > > I'd hope that would at least stop it complaining about libpthread. (but > > so should have your gcc -m32 > > No luck unfortunately with either method :s My understanding was that all you had was x86_64 Arch http://www.archlinux.org/news/440/ And I found this, "I don't think that the default arch64 gcc is a cross-compiler so you won't be able to compile 32-bit apps with it" But isn't really related to linking so... http://bbs.archlinux.org/viewtopic.php?id=64979
Re: DMD on x86_64
Don't forget that gcc adds a couple of system libraries (like libgcc) to the linker command. You need to give the right path for those too (you might want to try with --sysroot, or use --nostdlib and specify -lgcc manually) Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: DMD on x86_64
On 17/02/10 16:58, Lars T. Kyllingstad wrote: Try typing: export LD_LIBRARY_PATH="/opt/lib32" before compiling. -Lars No luck unfortunately, I get all the same errors as when I use -L, (I believe -L is checked first anyway, not sure though).
Re: DMD on x86_64
Robert Clipsham wrote:
I've been wanting to try D2 properly for a while now, but as I use linux
x86-64 I've had to resort to using a virtual machine, which is really
off putting when I just want to play around with it. I've read multiple
threads about getting dmd working with a multilib system, but I still
can't get it working, here's what I've tried:
test.d:
import std.stdio;
void main()
{
writeln( "Hello World!" );
}
% dmd -v test.d
-- snip --
gcc test.o -o test -m32 -Xlinker -L./../lib -lphobos2 -lpthread -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libpthread.so when
searching for -lpthread
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libpthread.a when
searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching
for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching
for -lpthread
/usr/bin/ld: cannot find -lpthread
collect2: ld returned 1 exit status
--- errorlevel 1
I have a 32 bit version of libpthread in /opt/lib32/lib, so I then tried:
% dmd test.d -L-L/opt/lib32/lib
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libpthread.so when
searching for -lpthread
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libpthread.a when
searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching
for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching
for -lpthread
/usr/bin/ld: cannot find -lpthread
collect2: ld returned 1 exit status
--- errorlevel 1
ld still seems to be trying to use the 64 bit version. Trying to link
manually with gcc (some options tweaked):
% gcc test.o -o test -m32 -Xlinker -L./../lib -L/opt/lib32/lib
-L/opt/lib32/usr/lib -lphobos2 -lpthread -lm
/usr/bin/ld: skipping incompatible /lib/libpthread.so.0 when searching
for /lib/libpthread.so.0
/usr/bin/ld: cannot find /lib/libpthread.so.0
collect2: ld returned 1 exit status
This seemed to get less errors than before. When I specified the path to
libpthread manually it started complaining about libgcc. Using -v with
the above command I found the linking command, then adapted that and
tried manually again, but was left with the error:
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
08048c90
When editing the linking command I had to remove a selection of gcc
libraries that I don't have 32 bit versions of, which could be the
issue, however according to nm none of the other .o's or .a's that are
meant to get linked contain _start. Does anyone have any idea how I can
get dmd working with a multi lib x86-64 system? I'm using Arch Linux, if
you could point me in the right direction to get the missing libraries
or whatever's needed to get dmd working let me know, thanks.
Robert
Try typing:
export LD_LIBRARY_PATH="/opt/lib32"
before compiling.
-Lars
Re: DMD on x86_64
On 17/02/10 06:20, Brad Roberts wrote: On 2/16/2010 10:05 PM, Jesse Phillips wrote: Robert Clipsham wrote: On 16/02/10 15:20, Jesse Phillips wrote: Robert Clipsham wrote: I don't use ubuntu, so those instructions don't apply to me. I don't either, but the instructions still apply to me. What distro are you using? If you figure it out, write up some instructions for it. I'm using Arch Linux. I've found a gcc-multilib package in AUR ( http://aur.archlinux.org/packages.php?ID=28545 ), it's out of date and doesn't build for me though, it seems to require the de_DE locale too for some unknown reason. I'm hoping when this package is updated it'll do what I need, I'm not holding my breath though. Oh, yeah Arch dropped most efforts to support 32bit didn't they. This probably won't help but maybe trying dmd test.d -L-L/opt/lib32/lib -L-melf_i386 I'd hope that would at least stop it complaining about libpthread. (but so should have your gcc -m32 The other thing you could try is to take dmd out of the loop. Can you build a 32 bit c/c++ app with gcc/g++ directly? If you can't get that to work, it's unlikely that dmd will we successful either, given that it relies on gcc to invoke the linker, picking up all the right c library pieces. # Compile normally % gcc hello.c % ./a.out Hello World! # Compile as 32 bit % gcc -m32 hello.c In file included from /usr/include/features.h:371, from /usr/include/stdio.h:28, from hello.c:1: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory # Stop #including and extern printf directly % gcc -m32 hello.c /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status # Add some -L's % gcc -m32 hello.c -L/opt/lib32/lib -L/opt/lib32/usr/lib /usr/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 /usr/bin/ld: cannot find /lib/libc.so.6 collect2: ld returned 1 exit status # As a side note, libc.so.6 can be found in /opt/lib32/lib. # I don't feel like symlinking that to make it work as it'll # break 64 bit builds :) Seems the path is hard coded there, # there might be an option to fix that, I don't know it though
Re: running an external .exe
Funog Wrote: > Is it possible to run an external .exe and have access to its standard > input/output? Apparently std.process does not allow this. > You can try loading the .exe into memory as a library (dll) and passing the .exe's entry point (main) to a thread (core.thread.Thread). Just a rant.
Re: DMD on x86_64
On 17/02/10 06:05, Jesse Phillips wrote: Oh, yeah Arch dropped most efforts to support 32bit didn't they. This I'm pretty sure they didn't... maybe they did on x86_64, I don't know. probably won't help but maybe trying dmd test.d -L-L/opt/lib32/lib -L-melf_i386 Already tried this, no luck :( I'd hope that would at least stop it complaining about libpthread. (but so should have your gcc -m32 No luck unfortunately with either method :s
Re: DMD on x86_64
On 17/02/10 06:20, Brad Roberts wrote: On 2/16/2010 10:05 PM, Jesse Phillips wrote: Robert Clipsham wrote: On 16/02/10 15:20, Jesse Phillips wrote: Robert Clipsham wrote: I don't use ubuntu, so those instructions don't apply to me. I don't either, but the instructions still apply to me. What distro are you using? If you figure it out, write up some instructions for it. I'm using Arch Linux. I've found a gcc-multilib package in AUR ( http://aur.archlinux.org/packages.php?ID=28545 ), it's out of date and doesn't build for me though, it seems to require the de_DE locale too for some unknown reason. I'm hoping when this package is updated it'll do what I need, I'm not holding my breath though. Oh, yeah Arch dropped most efforts to support 32bit didn't they. This probably won't help but maybe trying dmd test.d -L-L/opt/lib32/lib -L-melf_i386 I'd hope that would at least stop it complaining about libpthread. (but so should have your gcc -m32 The other thing you could try is to take dmd out of the loop. Can you build a 32 bit c/c++ app with gcc/g++ directly? If you can't get that to work, it's unlikely that dmd will we successful either, given that it relies on gcc to invoke the linker, picking up all the right c library pieces. I haven't tried that yet, I'll give it a shot and see how it goes, thanks :) I suspect that won't work either, at least that gives me some insight into where I'm going wrong though.
Re: DMD on x86_64
On 17/02/10 08:48, BCS wrote: Hello Brad, The other thing you could try is to take dmd out of the loop. Can you build a 32 bit c/c++ app with gcc/g++ directly? If you can't get that to work, it's unlikely that dmd will we successful either, given that it relies on gcc to invoke the linker, picking up all the right c library pieces. if all else fails, you could use "dmd -c" and invoke the linker directly. I tried that, can't manage to get it to link though, even after changing every library and file mentioned to the 32 bit versions and passing in the right -m :s
Re: DMD on x86_64
On 17/02/10 11:06, Lutger wrote: If you manage to find the proper 32 bit libraries, there is a configuration file for ld where you can specify the search paths, should be: /etc/ld.so.conf The 64-bit distro's I have used fail to add the 32-bit lib paths to this file, even if you install the right packages. The paths to my 32bit libs seem to be in there, thanks :)
Are D templates exported ?
Seems like D templates don't require to be in each translation unit. Does that mean that D templates are "exported" (like Comeau C++ do ?). export template blabla... Is it the very same feature that C++ dropped ? If so I think it's a great compared the C++ way (implementation all over the place) and could be advertised more.
Re: DMD on x86_64
If you manage to find the proper 32 bit libraries, there is a configuration file for ld where you can specify the search paths, should be: /etc/ld.so.conf The 64-bit distro's I have used fail to add the 32-bit lib paths to this file, even if you install the right packages.
Re: running an external .exe
On 02/16/2010 08:09 PM, Funog wrote: Is it possible to run an external .exe and have access to its standard input/output? Apparently std.process does not allow this. You'll want to choose either the input or the output stream, otherwise you might get eaten by a deadlock.
Re: DMD on x86_64
Hello Brad, The other thing you could try is to take dmd out of the loop. Can you build a 32 bit c/c++ app with gcc/g++ directly? If you can't get that to work, it's unlikely that dmd will we successful either, given that it relies on gcc to invoke the linker, picking up all the right c library pieces. if all else fails, you could use "dmd -c" and invoke the linker directly. -- ... <
