www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - crc32

reply John Reimer <brk_6502 yahoo.com> writes:
I'm having trouble linking with a D library that makes use of phobos' 
crc32 module.  I'm working on a linux platform.

I had a look at phobos source and found this:

file name:  crc32.d

but the module statement inside it says:  module crc;

Why is this?  Shouldn't the module name be "crc32", the same as the file 
name?

Also, my program can't resolve the symbol "getErrno" at link time.

libphobos.a is linked in per command line.  I've checked to see that 
errno.o and crc32.o are part of the library archive.

This is a recent issue since 0.125 (didn't happen on previous versions 
on linux).  The windows version works fine (although it doesn't use 
getErrno).

I'm using build 2.08 to build the libraries and project.  I've spent a 
fair bit of time trying to track down this bug.  In the past, I've been 
mostly successful with bug hunts, but not with this one...  Any 
suggestions would be appreciated.

-JJR
Jun 06 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jun 2005 13:53:36 -0700, John Reimer wrote:

 I'm having trouble linking with a D library that makes use of phobos' 
 crc32 module.  I'm working on a linux platform.
 
 I had a look at phobos source and found this:
 
 file name:  crc32.d
 
 but the module statement inside it says:  module crc;
 
 Why is this?  Shouldn't the module name be "crc32", the same as the file 
 name?

There are a number of misnamed modules in phobos. I think I've sent Walter a list of these a long, long time ago, but nothing's happened.
 Also, my program can't resolve the symbol "getErrno" at link time.
 
 libphobos.a is linked in per command line.  I've checked to see that 
 errno.o and crc32.o are part of the library archive.
 
 This is a recent issue since 0.125 (didn't happen on previous versions 
 on linux).  The windows version works fine (although it doesn't use 
 getErrno).
 
 I'm using build 2.08 to build the libraries and project.  I've spent a 
 fair bit of time trying to track down this bug.  In the past, I've been 
 mostly successful with bug hunts, but not with this one...  Any 
 suggestions would be appreciated.

Do you still get the getErrno problem when not using Build? I've tried on Windows and it links it. (import std.c.stdlib;) -- Derek Parnell Melbourne, Australia 6/06/2005 11:44:26 PM
Jun 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:
 
 There are a number of misnamed modules in phobos. I think I've sent Walter
 a list of these a long, long time ago, but nothing's happened.
 

Ouch!
 Do you still get the getErrno problem when not using Build? I've tried on
 Windows and it links it. (import std.c.stdlib;)
 
 

I guess I should give it a try without build. It's "dool" on linux. It was working before. I should try compiling with a makefile and see what happens. -JJR
Jun 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
John Reimer wrote:

 I guess I should give it a try without build.  It's "dool" on linux.  It 
 was working before.  I should try compiling with a makefile and see what 
 happens.
 
 -JJR

I should clarify this: compiling into a library is no problem. It's when I link with another project, like "leds" that the problem surfaces. I can't seem to figure out what's going on, but I'll look into it more. This means I'll have to use a makefile on all projects... -JJR
Jun 06 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jun 2005 23:57:16 -0700, John Reimer wrote:

 John Reimer wrote:
 
 I guess I should give it a try without build.  It's "dool" on linux.  It 
 was working before.  I should try compiling with a makefile and see what 
 happens.
 
 -JJR

I should clarify this: compiling into a library is no problem. It's when I link with another project, like "leds" that the problem surfaces. I can't seem to figure out what's going on, but I'll look into it more.

problem is. It could be a name mangling thing...?
  This means I'll have to use a makefile on all projects...

No. If its a mistake in Build, I'll fix it. -- Derek Parnell Melbourne, Australia 7/06/2005 8:12:53 AM
Jun 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:

 
 Got any messages to go on? It might help someone else figure out what the
 problem is. It could be a name mangling thing...?
 

Yep... a few. I should have posted them. I'll post them later tonight. I've been busy today. :P
 
 This means I'll have to use a makefile on all projects...

No. If its a mistake in Build, I'll fix it.

Ah... sorry. What I meant to say is that I will need to resort to a makefile just in order to determine if the problem is in build or not. I'm not sure how this could relate to a "build" issue, though, unless build isn't linking in the phobos library for some strange reason. But I doubt that's the case because the output clearly indicates that it is linking with phobos. 2.08, in all respects so far, seems to working very well. -JJR
Jun 07 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jun 2005 05:14:11 -0700, John Reimer wrote:

BTW, can you check the clock setting on your machine. All your latest posts
are "in the future". ;-)


-- 
Derek
Melbourne, Australia
7/06/2005 9:52:13 AM
Jun 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:
 On Tue, 07 Jun 2005 05:14:11 -0700, John Reimer wrote:
 
 BTW, can you check the clock setting on your machine. All your latest posts
 are "in the future". ;-)
 
 

Oh darn it... I got caught time-travelling again. I just wanted to see what /really/ was going to happen with Apple computers... Honest! Actually, this is from dual booting into linux and windows. I don't know why, but I have to reset the clock for each OS. Sometimes I forget. This didn't used to happen... but it looks like I've got incorrect settings somewhere in my linux config. -JJR
Jun 06 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.this-is-spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Reimer schrieb am Mon, 06 Jun 2005 17:30:44 -0700:
 Derek Parnell wrote:
 On Tue, 07 Jun 2005 05:14:11 -0700, John Reimer wrote:
 
 BTW, can you check the clock setting on your machine. All your latest posts
 are "in the future". ;-)
 
 

Oh darn it... I got caught time-travelling again. I just wanted to see what /really/ was going to happen with Apple computers... Honest! Actually, this is from dual booting into linux and windows. I don't know why, but I have to reset the clock for each OS. Sometimes I forget. This didn't used to happen... but it looks like I've got incorrect settings somewhere in my linux config.

Cause: One of your OSs stores the time in the BIOS with timezone offset while the other uses GMT or another timezone. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCpR9/3w+/yD4P9tIRAsgpAJ4/IdklHBnEPZoOR4BnfSc/OaPJ2gCdH3QV /v0hREDteR3OPAoqAlUhuj0= =Sxy3 -----END PGP SIGNATURE-----
Jun 06 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 John Reimer schrieb am Mon, 06 Jun 2005 17:30:44 -0700:
 
Derek Parnell wrote:

On Tue, 07 Jun 2005 05:14:11 -0700, John Reimer wrote:

BTW, can you check the clock setting on your machine. All your latest posts
are "in the future". ;-)

Oh darn it... I got caught time-travelling again. I just wanted to see what /really/ was going to happen with Apple computers... Honest! Actually, this is from dual booting into linux and windows. I don't know why, but I have to reset the clock for each OS. Sometimes I forget. This didn't used to happen... but it looks like I've got incorrect settings somewhere in my linux config.

Cause: One of your OSs stores the time in the BIOS with timezone offset while the other uses GMT or another timezone. Thomas

Well, I explicitly avoided using GMT on the linux system in hopes it would be compatible with XP. I was sure I directed it to local time (time zone offset), which, I assumed, would use the BIOS setting. Apparently, I'm still not clear what the problem is. :-( Maybe I should have stuck with GMT? I'll have to try that now, since the way it is set now obviously isn't working. -JJR
Jun 06 2005
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <d811i9$2ukd$1 digitaldaemon.com>, John Reimer says...
I'm having trouble linking with a D library that makes use of phobos' 
crc32 module.  I'm working on a linux platform.

I had a look at phobos source and found this:

file name:  crc32.d

but the module statement inside it says:  module crc;

Why is this?  Shouldn't the module name be "crc32", the same as the file 
name?

I agree, and I'd even take it a step further. Move it into std and call it "std.crc32". I'd like to see "gcstats.d", "object.d", and "unittest.d" be moved into std, too, but maybe there's a reason why this can't be done. But at the minimum, I do think that the file name and module name should match for all of the Phobos modules. This crc32 vs. crc thing is probably just an oversight. jcc7
Jun 06 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Okay... here's a few more details.  I've tried it on two linux systems 
with the same results.

I compile and archive these three libraries using build 2.08:

libdool.a
libdantfw.a
libdui.a

I stick them all in /opt/dmd/lib

My dmd.conf has a line -L-L/opt/dmd/lib in it so that gcc knows where to 
search for d libraries.

There is also a symbolic link to libphobos.a in /usr/lib that points to 
/opt/dmd/lib.

I then try to compile and link "Leds" IDE with the above libraries.  I 
use build 2.08 here also with a project build control source file called 
build.d for the project:

# module build;

# version(build)
# {
#        version(Windows)
#        {
#                pragma(target, "leds.exe");
#
#                pragma(link, dool.lib);
#                pragma(link, dantfw.lib);
#                pragma(link, dui.lib);
#        }
#        version(linux)
#        {
#                pragma(target, "Leds");
#
#                pragma(link, dool);
#                pragma(link, dantfw);
#                pragma(link, dui);
#                pragma(link, dl);
#        }
#        pragma(nolink);  // this file
# }
#
# private import leds.Leds;

A build scripts executes this command on the file:

build build.d -I/home/john/projects/d/dool/src 
-I/home/john/projects/d/dui/src -I/home/john/projects/d/dantfw/src 
-Xdool -Xdui -Xdantfw -clean

Phobos is included by default for all d programs.

The output is:

gcc property/Properties.o leds/LedsPaned.o leds/Leds.o leds/Workspace.o 
leds/ImageView.o leds/LedsVPaned.o leds/FindAndReplace.o leds/FSTree.o 
leds/FSView.o property/Props.o leds/FileView.o leds/InputStringDialog.o 
property/PropertiesUI.o leds/ProjectTarget.o leds/CodeView.o 
leds/Project.o leds/EventImage.o leds/LedsHPaned.o leds/CompilerBox.o 
leds/DockerTools.o leds/TipWindow.o leds/DockerFiles.o 
leds/CreateProjectElement.o leds/Docker.o leds/GotoLineDialog.o 
resources/Pixmaps.o leds/StatusBar.o leds/KeyMap.o leds/CodeEdit.o 
leds/BrowserView.o leds/ListWindow.o leds/ErrorPane.o 
leds/ProjectError.o leds/ProjectTargetUI.o leds/DSpell.o leds/TrashUI.o 
leds/ProjectView.o leds/CompilerWindow.o leds/SimpleCodeEdit.o 
resources/DUILogo.o leds/ExecConsole.o leds/CodeLookup.o leds/ListBox.o 
property/PropsUI.o leds/WrapGtk.o leds/Scintilla.o leds/SystemConsole.o 
leds/Trash.o -o Leds -lphobos -lpthread -lm -Xlinker -L/opt/dmd/lib 
-Xlinker -ldool -Xlinker -ldantfw -Xlinker -ldui -Xlinker -ldl -Xlinker 
-L/opt/dmd/lib

With errors to follow as:

/opt/dmd/lib/libdool.a(Stream.o): In function 
`_D4dool2io6Stream6Stream6toHashFZk':
dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x35): 
undefined reference to `_D3crc10init_crc32FZk'
dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x85): 
undefined reference to `_D3crc12update_crc32FhkZk'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer4readFC4dool6String6StringZAv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer4readFC4dool6Str
ng6StringZAv+0xb7): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6String6StringAvZv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6Stri
g6StringAvZv+0x76): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6String6StringAvZv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6Stri
g6StringAvZv+0x76): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o): In function 
`_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6String6StringZv':
dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6St
ing6StringZv+0x32): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o): In function 
`_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6String6StringbZv':
dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x3e): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o):dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x75): 
more undefined references to `getErrno' follow
/opt/dmd/lib/libdool.a(FileException.o):(.data+0x70): undefined 
reference to `_ModuleInfo_3std8syserror'
collect2: ld returned 1 exit status

The dool library imports "crc" in file dool/io/Stream.d.

It uses getErrno in file dool/io/FileBuffer.d; this is imported from 
dool/system/stdlib as extern(C).  It basically duplicates the 
declarations of std.c.stdlib.  Replacing the import with std.c.stdlib 
does nothing to fix this error.

All these libraries compile fine.  These errors only occur during the 
linking stage during the leds project build, as you can see.  You can 
also see that libphobos is being linked in with the other files, so the 
getErrno() symbol should be available to the linker.  The crc problem is 
strange too because changing the module statement in it to crc32 instead 
of crc and recompiling phobos does not fix the problem.  Instead the 
linker output above just gives the same crc error but replaces the error 
with crc32 instead of crc.

Any suggestions would be welcome!

Thanks!

-JJR
Jun 06 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jun 2005 23:32:00 -0700, John Reimer wrote:

 Okay... here's a few more details.  I've tried it on two linux systems 
 with the same results.
 
 I compile and archive these three libraries using build 2.08:
 
 libdool.a
 libdantfw.a
 libdui.a
 
 I stick them all in /opt/dmd/lib
 
 My dmd.conf has a line -L-L/opt/dmd/lib in it so that gcc knows where to 
 search for d libraries.
 
 There is also a symbolic link to libphobos.a in /usr/lib that points to 
 /opt/dmd/lib.
 
 I then try to compile and link "Leds" IDE with the above libraries.  I 
 use build 2.08 here also with a project build control source file called 
 build.d for the project:
 
 # module build;
 
 # version(build)
 # {
 #        version(Windows)
 #        {
 #                pragma(target, "leds.exe");
 #
 #                pragma(link, dool.lib);
 #                pragma(link, dantfw.lib);
 #                pragma(link, dui.lib);
 #        }
 #        version(linux)
 #        {
 #                pragma(target, "Leds");
 #
 #                pragma(link, dool);
 #                pragma(link, dantfw);
 #                pragma(link, dui);
 #                pragma(link, dl);
 #        }
 #        pragma(nolink);  // this file
 # }
 #
 # private import leds.Leds;
 
 A build scripts executes this command on the file:
 
 build build.d -I/home/john/projects/d/dool/src 
 -I/home/john/projects/d/dui/src -I/home/john/projects/d/dantfw/src 
 -Xdool -Xdui -Xdantfw -clean
 
 Phobos is included by default for all d programs.
 
 The output is:
 
 gcc property/Properties.o leds/LedsPaned.o leds/Leds.o leds/Workspace.o 
 leds/ImageView.o leds/LedsVPaned.o leds/FindAndReplace.o leds/FSTree.o 
 leds/FSView.o property/Props.o leds/FileView.o leds/InputStringDialog.o 
 property/PropertiesUI.o leds/ProjectTarget.o leds/CodeView.o 
 leds/Project.o leds/EventImage.o leds/LedsHPaned.o leds/CompilerBox.o 
 leds/DockerTools.o leds/TipWindow.o leds/DockerFiles.o 
 leds/CreateProjectElement.o leds/Docker.o leds/GotoLineDialog.o 
 resources/Pixmaps.o leds/StatusBar.o leds/KeyMap.o leds/CodeEdit.o 
 leds/BrowserView.o leds/ListWindow.o leds/ErrorPane.o 
 leds/ProjectError.o leds/ProjectTargetUI.o leds/DSpell.o leds/TrashUI.o 
 leds/ProjectView.o leds/CompilerWindow.o leds/SimpleCodeEdit.o 
 resources/DUILogo.o leds/ExecConsole.o leds/CodeLookup.o leds/ListBox.o 
 property/PropsUI.o leds/WrapGtk.o leds/Scintilla.o leds/SystemConsole.o 
 leds/Trash.o -o Leds -lphobos -lpthread -lm -Xlinker -L/opt/dmd/lib 
 -Xlinker -ldool -Xlinker -ldantfw -Xlinker -ldui -Xlinker -ldl -Xlinker 
 -L/opt/dmd/lib
 
 With errors to follow as:
 
 /opt/dmd/lib/libdool.a(Stream.o): In function 
 `_D4dool2io6Stream6Stream6toHashFZk':
 dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x35): 
 undefined reference to `_D3crc10init_crc32FZk'
 dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x85): 
 undefined reference to `_D3crc12update_crc32FhkZk'
 /opt/dmd/lib/libdool.a(FileBuffer.o): In function 
 `_D4dool2io10FileBuffer10FileBuffer4readFC4dool6String6StringZAv':
 dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer4readFC4dool6Str
ng6StringZAv+0xb7): 
 undefined reference to `getErrno'
 /opt/dmd/lib/libdool.a(FileBuffer.o): In function 
 `_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6String6StringAvZv':
 dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6Stri
g6StringAvZv+0x76): 
 undefined reference to `getErrno'
 /opt/dmd/lib/libdool.a(FileBuffer.o): In function 
 `_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6String6StringAvZv':
 dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6Stri
g6StringAvZv+0x76): 
 undefined reference to `getErrno'
 /opt/dmd/lib/libdool.a(Path.o): In function 
 `_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6String6StringZv':
 dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6St
ing6StringZv+0x32): 
 undefined reference to `getErrno'
 /opt/dmd/lib/libdool.a(Path.o): In function 
 `_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6String6StringbZv':
 dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x3e): 
 undefined reference to `getErrno'
 /opt/dmd/lib/libdool.a(Path.o):dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x75): 
 more undefined references to `getErrno' follow
 /opt/dmd/lib/libdool.a(FileException.o):(.data+0x70): undefined 
 reference to `_ModuleInfo_3std8syserror'
 collect2: ld returned 1 exit status
 
 The dool library imports "crc" in file dool/io/Stream.d.
 
 It uses getErrno in file dool/io/FileBuffer.d; this is imported from 
 dool/system/stdlib as extern(C).  It basically duplicates the 
 declarations of std.c.stdlib.  Replacing the import with std.c.stdlib 
 does nothing to fix this error.
 
 All these libraries compile fine.  These errors only occur during the 
 linking stage during the leds project build, as you can see.  You can 
 also see that libphobos is being linked in with the other files, so the 
 getErrno() symbol should be available to the linker.  The crc problem is 
 strange too because changing the module statement in it to crc32 instead 
 of crc and recompiling phobos does not fix the problem.  Instead the 
 linker output above just gives the same crc error but replaces the error 
 with crc32 instead of crc.
 
 Any suggestions would be welcome!
 
 Thanks!
 
 -JJR

Have you done a list of the .o files and/or the library to check out the exact spelling of the module names in the files? It still sounds like a name-mangling issue to me. -- Derek Melbourne, Australia 7/06/2005 4:51:06 PM
Jun 06 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:
 On Mon, 06 Jun 2005 23:32:00 -0700, John Reimer wrote:
 
 
Okay... here's a few more details.  I've tried it on two linux systems 
with the same results.

I compile and archive these three libraries using build 2.08:

libdool.a
libdantfw.a
libdui.a

I stick them all in /opt/dmd/lib

My dmd.conf has a line -L-L/opt/dmd/lib in it so that gcc knows where to 
search for d libraries.

There is also a symbolic link to libphobos.a in /usr/lib that points to 
/opt/dmd/lib.

I then try to compile and link "Leds" IDE with the above libraries.  I 
use build 2.08 here also with a project build control source file called 
build.d for the project:

# module build;

# version(build)
# {
#        version(Windows)
#        {
#                pragma(target, "leds.exe");
#
#                pragma(link, dool.lib);
#                pragma(link, dantfw.lib);
#                pragma(link, dui.lib);
#        }
#        version(linux)
#        {
#                pragma(target, "Leds");
#
#                pragma(link, dool);
#                pragma(link, dantfw);
#                pragma(link, dui);
#                pragma(link, dl);
#        }
#        pragma(nolink);  // this file
# }
#
# private import leds.Leds;

A build scripts executes this command on the file:

build build.d -I/home/john/projects/d/dool/src 
-I/home/john/projects/d/dui/src -I/home/john/projects/d/dantfw/src 
-Xdool -Xdui -Xdantfw -clean

Phobos is included by default for all d programs.

The output is:

gcc property/Properties.o leds/LedsPaned.o leds/Leds.o leds/Workspace.o 
leds/ImageView.o leds/LedsVPaned.o leds/FindAndReplace.o leds/FSTree.o 
leds/FSView.o property/Props.o leds/FileView.o leds/InputStringDialog.o 
property/PropertiesUI.o leds/ProjectTarget.o leds/CodeView.o 
leds/Project.o leds/EventImage.o leds/LedsHPaned.o leds/CompilerBox.o 
leds/DockerTools.o leds/TipWindow.o leds/DockerFiles.o 
leds/CreateProjectElement.o leds/Docker.o leds/GotoLineDialog.o 
resources/Pixmaps.o leds/StatusBar.o leds/KeyMap.o leds/CodeEdit.o 
leds/BrowserView.o leds/ListWindow.o leds/ErrorPane.o 
leds/ProjectError.o leds/ProjectTargetUI.o leds/DSpell.o leds/TrashUI.o 
leds/ProjectView.o leds/CompilerWindow.o leds/SimpleCodeEdit.o 
resources/DUILogo.o leds/ExecConsole.o leds/CodeLookup.o leds/ListBox.o 
property/PropsUI.o leds/WrapGtk.o leds/Scintilla.o leds/SystemConsole.o 
leds/Trash.o -o Leds -lphobos -lpthread -lm -Xlinker -L/opt/dmd/lib 
-Xlinker -ldool -Xlinker -ldantfw -Xlinker -ldui -Xlinker -ldl -Xlinker 
-L/opt/dmd/lib

With errors to follow as:

/opt/dmd/lib/libdool.a(Stream.o): In function 
`_D4dool2io6Stream6Stream6toHashFZk':
dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x35): 
undefined reference to `_D3crc10init_crc32FZk'
dool/io/Stream.d:(.gnu.linkonce.t_D4dool2io6Stream6Stream6toHashFZk+0x85): 
undefined reference to `_D3crc12update_crc32FhkZk'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer4readFC4dool6String6StringZAv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer4readFC4dool6Str
ng6StringZAv+0xb7): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6String6StringAvZv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer5writeFC4dool6Stri
g6StringAvZv+0x76): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(FileBuffer.o): In function 
`_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6String6StringAvZv':
dool/io/FileBuffer.d:(.gnu.linkonce.t_D4dool2io10FileBuffer10FileBuffer6appendFC4dool6Stri
g6StringAvZv+0x76): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o): In function 
`_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6String6StringZv':
dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path6renameFC4dool6String6StringC4dool6St
ing6StringZv+0x32): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o): In function 
`_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6String6StringbZv':
dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x3e): 
undefined reference to `getErrno'
/opt/dmd/lib/libdool.a(Path.o):dool/io/Path.d:(.gnu.linkonce.t_D4dool2io4Path4Path4linkFC4dool6String6StringC4dool6Str
ng6StringbZv+0x75): 
more undefined references to `getErrno' follow
/opt/dmd/lib/libdool.a(FileException.o):(.data+0x70): undefined 
reference to `_ModuleInfo_3std8syserror'
collect2: ld returned 1 exit status

The dool library imports "crc" in file dool/io/Stream.d.

It uses getErrno in file dool/io/FileBuffer.d; this is imported from 
dool/system/stdlib as extern(C).  It basically duplicates the 
declarations of std.c.stdlib.  Replacing the import with std.c.stdlib 
does nothing to fix this error.

All these libraries compile fine.  These errors only occur during the 
linking stage during the leds project build, as you can see.  You can 
also see that libphobos is being linked in with the other files, so the 
getErrno() symbol should be available to the linker.  The crc problem is 
strange too because changing the module statement in it to crc32 instead 
of crc and recompiling phobos does not fix the problem.  Instead the 
linker output above just gives the same crc error but replaces the error 
with crc32 instead of crc.

Any suggestions would be welcome!

Thanks!

-JJR

Have you done a list of the .o files and/or the library to check out the exact spelling of the module names in the files? It still sounds like a name-mangling issue to me.

I'll keep looking, but nothing seems to be amiss. With my luck, though, it's probably something obvious. :-P -JJR
Jun 07 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jun 2005 23:32:00 -0700, John Reimer wrote:

[snip]

 build build.d -I/home/john/projects/d/dool/src 
 -I/home/john/projects/d/dui/src -I/home/john/projects/d/dantfw/src 
 -Xdool -Xdui -Xdantfw -clean

BTW, if you create a text file called "build.cfg" in the directory that Build is installed in, and place these lines in it ... # Start of John's configuration CMDLINE=-I/home/john/projects/d/dool/src CMDLINE=-Xdool CMDLINE=-I/home/john/projects/d/dui/src CMDLINE=-Xdui CMDLINE=-I/home/john/projects/d/dantfw/src CMDLINE=-Xdantfw # ---- end of configuration file Then all you need to type in is ... build build.d -clean -- Derek Parnell Melbourne, Australia Download BUILD from ... http://www.dsource.org/projects/build/ v2.08 released 29/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 7/06/2005 4:59:16 PM
Jun 06 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:
 On Mon, 06 Jun 2005 23:32:00 -0700, John Reimer wrote:
 
 [snip]
 
 
build build.d -I/home/john/projects/d/dool/src 
-I/home/john/projects/d/dui/src -I/home/john/projects/d/dantfw/src 
-Xdool -Xdui -Xdantfw -clean

BTW, if you create a text file called "build.cfg" in the directory that Build is installed in, and place these lines in it ... # Start of John's configuration CMDLINE=-I/home/john/projects/d/dool/src CMDLINE=-Xdool CMDLINE=-I/home/john/projects/d/dui/src CMDLINE=-Xdui CMDLINE=-I/home/john/projects/d/dantfw/src CMDLINE=-Xdantfw # ---- end of configuration file Then all you need to type in is ... build build.d -clean

Good tip. Thanks! -JJR
Jun 07 2005
prev sibling parent reply Carlos Santander <Carlos_member pathlink.com> writes:
In article <d83f0p$1olr$1 digitaldaemon.com>, John Reimer says...
gcc property/Properties.o leds/LedsPaned.o leds/Leds.o leds/Workspace.o 
leds/ImageView.o leds/LedsVPaned.o leds/FindAndReplace.o leds/FSTree.o 
leds/FSView.o property/Props.o leds/FileView.o leds/InputStringDialog.o 
property/PropertiesUI.o leds/ProjectTarget.o leds/CodeView.o 
leds/Project.o leds/EventImage.o leds/LedsHPaned.o leds/CompilerBox.o 
leds/DockerTools.o leds/TipWindow.o leds/DockerFiles.o 
leds/CreateProjectElement.o leds/Docker.o leds/GotoLineDialog.o 
resources/Pixmaps.o leds/StatusBar.o leds/KeyMap.o leds/CodeEdit.o 
leds/BrowserView.o leds/ListWindow.o leds/ErrorPane.o 
leds/ProjectError.o leds/ProjectTargetUI.o leds/DSpell.o leds/TrashUI.o 
leds/ProjectView.o leds/CompilerWindow.o leds/SimpleCodeEdit.o 
resources/DUILogo.o leds/ExecConsole.o leds/CodeLookup.o leds/ListBox.o 
property/PropsUI.o leds/WrapGtk.o leds/Scintilla.o leds/SystemConsole.o 
leds/Trash.o -o Leds -lphobos -lpthread -lm -Xlinker -L/opt/dmd/lib 
-Xlinker -ldool -Xlinker -ldantfw -Xlinker -ldui -Xlinker -ldl -Xlinker 
-L/opt/dmd/lib

Try to split compilation and linking. When linking, make sure you have -lpthread, -lm, and -ldl after -lphobos, but try this: place -lphobos after -ldool, -ldantfw, and -ldui. -- Carlos Santander Bernal
Jun 07 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Carlos Santander wrote:
 In article <d83f0p$1olr$1 digitaldaemon.com>, John Reimer says...
 
gcc property/Properties.o leds/LedsPaned.o leds/Leds.o leds/Workspace.o 
leds/ImageView.o leds/LedsVPaned.o leds/FindAndReplace.o leds/FSTree.o 
leds/FSView.o property/Props.o leds/FileView.o leds/InputStringDialog.o 
property/PropertiesUI.o leds/ProjectTarget.o leds/CodeView.o 
leds/Project.o leds/EventImage.o leds/LedsHPaned.o leds/CompilerBox.o 
leds/DockerTools.o leds/TipWindow.o leds/DockerFiles.o 
leds/CreateProjectElement.o leds/Docker.o leds/GotoLineDialog.o 
resources/Pixmaps.o leds/StatusBar.o leds/KeyMap.o leds/CodeEdit.o 
leds/BrowserView.o leds/ListWindow.o leds/ErrorPane.o 
leds/ProjectError.o leds/ProjectTargetUI.o leds/DSpell.o leds/TrashUI.o 
leds/ProjectView.o leds/CompilerWindow.o leds/SimpleCodeEdit.o 
resources/DUILogo.o leds/ExecConsole.o leds/CodeLookup.o leds/ListBox.o 
property/PropsUI.o leds/WrapGtk.o leds/Scintilla.o leds/SystemConsole.o 
leds/Trash.o -o Leds -lphobos -lpthread -lm -Xlinker -L/opt/dmd/lib 
-Xlinker -ldool -Xlinker -ldantfw -Xlinker -ldui -Xlinker -ldl -Xlinker 
-L/opt/dmd/lib

Try to split compilation and linking. When linking, make sure you have -lpthread, -lm, and -ldl after -lphobos, but try this: place -lphobos after -ldool, -ldantfw, and -ldui.

Thanks, Carlos. I'll give it a try. -JJR
Jun 07 2005