* Linking nominally incompatible object files @ 2004-05-02 16:41 Bernd Jendrissek 2004-05-05 16:26 ` Nick Clifton 0 siblings, 1 reply; 6+ messages in thread From: Bernd Jendrissek @ 2004-05-02 16:41 UTC (permalink / raw) To: binutils -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, me again. While I have a v850 toolchain (GCC + binutils), I'm working on hacking a copy of the v850 bits so that I can link in libraries supplied by Green Hills (EM_V800 not EM_V850, different relocs). So I have a mix of GCC-compiled v850 object files, and Green Hills v800 (what I've called my "new" target) libraries. When I link them all together, I get: + /mnt/disk2/src/binutils-build/ld/ld-new -e __start -L../../../../../SDK/Lib ../../../../../SDK/Lib/crtPulsarPlus.o -lstartup -lsys -lind -larch -lsedgnoe -lansi ../../../../../SDK/Lib/lCore.a -o emv.elf aim.o circbuf.o emv.o file.o mafif.o main.o sps.o swevent_m an.o tlv.o trace.o utils.o ../../../../manapp/Source/Common/data_store.o ../../../../manapp/Source/Common/event.o ../../../../manapp /Source/Common/mailbox.o ../../../../manapp/Source/Common/memory.o lt-ld-new: warning: v850 architecture of input file `aim.o' is incompatible with v850e output lt-ld-new: warning: v850 architecture of input file `circbuf.o' is incompatible with v850e output ... reloc type 2 not SUPPORTED aim.o(.text+0x2c): In function `AimEventHandler': /mnt/disk2/src/emv/sc5000/dev/PayApp/Emv/MafApp/Source/aim.c:42: internal error: unsupported relocation error ... The weird thing is, that aim.o is generated by the v850 toolchain, so its relocs cannot possibly be completely alien (if I link with the v850-ld and remove all the v800 libraries, the errors are "undefined reference", not "unsupported relocation"). Is the linker supposed to interpret the relocs based on the input file format (would be nice) or based on the output file format? Because, what seems to be happening now, is that the linker sees relocs in an input file of format A, but those relocs get misinterpreted as relocs in format B, and I get segfaults. Should I just give up now, while I can, before I involuntarily end up as a BFD hacker? - -- http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c) "years from now, we'll look back on this, laugh nervously and quickly change the subject" - lee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAlSNb/FmLrNfLpjMRAmtFAKCPGToQjpHxiFPf+2B3k90BCKOT7ACcCQT/ J3LhFhbb9mtnoUTRhOdGOk4= =1Mxe -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Linking nominally incompatible object files 2004-05-02 16:41 Linking nominally incompatible object files Bernd Jendrissek @ 2004-05-05 16:26 ` Nick Clifton 2004-05-05 18:20 ` Bernd Jendrissek 0 siblings, 1 reply; 6+ messages in thread From: Nick Clifton @ 2004-05-05 16:26 UTC (permalink / raw) To: Bernd Jendrissek; +Cc: binutils Hi Bernd, >So I have a mix of GCC-compiled v850 object files, and Green Hills v800 >(what I've called my "new" target) libraries. When I link them all >together, I get: > >lt-ld-new: warning: v850 architecture of input file `aim.o' is incompatible with v850e output >lt-ld-new: warning: v850 architecture of input file `circbuf.o' is incompatible with v850e output > > Assuming that "lt-ld-new" is the GNU linker then this message is arising because the machine numbers of the two files are different. These numbers are held in the e_machine field of the ELF header and the GNU linker is expecting one of the values defined in the bfd/archures.c file (bfd_mach_v850, bfd_mach_v850e, bfd_mach_v850e1). The output file has its e_machine value filled in by using the value from the very first object file on the linker's command line. This is usually a file like crt0.o. So in this case the linker is telling you that the crt0.o file (or whichever is the first file in the link) is for a different version of the v850 than the aim.o file. >reloc type 2 not SUPPORTED > > >The weird thing is, that aim.o is generated by the v850 toolchain, so >its relocs cannot possibly be completely alien (if I link with the >v850-ld and remove all the v800 libraries, the errors are "undefined >reference", not "unsupported relocation"). > > Reloc 2 is for a function call. So if you remove the libraries then you are probably removing the definition of the function being called and hence the failure changes to "undefined reference". I am not sure why you are getting the message that the reloc is not supported. I think that some further investigation is needed. >Is the linker supposed to interpret the relocs based on the input file >format (would be nice) or based on the output file format? > Neither and both. It is supposed to interpret them based on the target architecture that it was built to support. When it is built to support more than one architecture then it is supposed to select the relocs that is supports based upon the input file that it is processing. (It is also allowed to refuse to link together files of different architectural types if it thinks that it cannot handle this). >Should I just give up now, while I can, before I involuntarily end up as >a BFD hacker? > > Welcome to the dark side :-) Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Linking nominally incompatible object files 2004-05-05 16:26 ` Nick Clifton @ 2004-05-05 18:20 ` Bernd Jendrissek 2004-05-06 13:32 ` Nick Clifton 0 siblings, 1 reply; 6+ messages in thread From: Bernd Jendrissek @ 2004-05-05 18:20 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, May 05, 2004 at 05:30:37PM +0100, Nick Clifton wrote: > >So I have a mix of GCC-compiled v850 object files, and Green Hills v800 > >(what I've called my "new" target) libraries. When I link them all > >together, I get: > > > >lt-ld-new: warning: v850 architecture of input file `aim.o' is > >incompatible with v850e output > >lt-ld-new: warning: v850 architecture of input file `circbuf.o' is > >incompatible with v850e output > > > Assuming that "lt-ld-new" is the GNU linker then this message is arising Yes, lt-ld-new is a shell script that invokes the newly built GNU ld with the appropriate LD_LIBRARY_PATH hackery so that it uses the libraries it just built instead of those installed in /usr/lib. > because the machine numbers of the two files are different. These > numbers are held in the e_machine field of the ELF header and the GNU > linker is expecting one of the values defined in the bfd/archures.c file > (bfd_mach_v850, bfd_mach_v850e, bfd_mach_v850e1). The output file has > its e_machine value filled in by using the value from the very first > object file on the linker's command line. This is usually a file like > crt0.o. So in this case the linker is telling you that the crt0.o file > (or whichever is the first file in the link) is for a different version > of the v850 than the aim.o file. Yes, I got that, and I'm glad it's a warning and not an error. > >reloc type 2 not SUPPORTED > > > >The weird thing is, that aim.o is generated by the v850 toolchain, so > >its relocs cannot possibly be completely alien (if I link with the > >v850-ld and remove all the v800 libraries, the errors are "undefined > >reference", not "unsupported relocation"). > > > Reloc 2 is for a function call. It is for v850 indeed. Which is why I'm surprised that the linker claims it's *not* supported. (And I did configure with - --enable-targets=all.) > So if you remove the libraries then you > are probably removing the definition of the function being called and > hence the failure changes to "undefined reference". I am not sure why > you are getting the message that the reloc is not supported. I think > that some further investigation is needed. Yes. Some more data: I notice now that in my "new" file bfd/elf32-v800.c (*derived* from, not replacing elf32-v850.c!) the token "R_V850_22_PCREL" appears only in the macro call to HOWTO - IOW it is otherwise unhandled. Fine, because the Green Hills toolchain uses what it calls "R_V850_22_PCREL", reloc 22. It's as if the linker is looking at the v850 object file with my hacked v800 backend! And yet, the v850 backend is still there. Indeed, the error message ("reloc type 2 not SUPPORTED") MUST be from my v800 target, as the fprintf is commented out in the GNU version. > >Is the linker supposed to interpret the relocs based on the input file > >format (would be nice) or based on the output file format? > > Neither and both. It is supposed to interpret them based on the target > architecture that it was built to support. When it is built to support > more than one architecture then it is supposed to select the relocs that > is supports based upon the input file that it is processing. So if I configured my binutils with --enable-targets=all, the linker *should* interpret the relocs based on the input file in which they appear? IOW those R_*V850*_22_PCREL relocs should be getting handled just fine by the *v850* backend... but they evidently aren't. :( > (It is also allowed to refuse to link together files of different > architectural types if it thinks that it cannot handle this). You mean... you mean... in some circumstances ld *cannot* just read my mind and DTRT? What sort of crummy tool is THAT??!? :) Seriously, what sort of circumstances could cause ld to bail like this? I would have thought that relocs always operate on bits in the same object file as where the relocs are. Isn't that the whole point of BFD, to abstract object files as just BFDs which can then be linked together in an architecture-independent way? If I wanted to look at the logic that decides how input file relocs should be handled, where would I look? (What I want to check: whether ld will *really* change its interpretation of relocs on a per input file basis.) Hah! Look at bfd/elflink.h: elf_link_input_bfd(): [declarations] output_bfd = finfo->output_bfd; bed = get_elf_backend_data (output_bfd); relocate_section = bed->elf_backend_relocate_section; So, because my new linker is configured to produce v800 *output*, all *input* object files have their relocs interpreted as v800 relocs as well! Now, what do I do about it? Hah! I do this: - --- binutils/bfd/elflink.h.borig Wed Jan 14 23:07:43 2004 +++ binutils/bfd/elflink.h Wed May 5 19:39:49 2004 @@ -4678,7 +4678,7 @@ struct elf_link_hash_entry **sym_hashes; output_bfd = finfo->output_bfd; - - bed = get_elf_backend_data (output_bfd); + bed = get_elf_backend_data (input_bfd); relocate_section = bed->elf_backend_relocate_section; /* If this is a dynamic object, we don't want to do anything here: And now the only "not SUPPORTED" relocs are the v800 ones for which I haven't yet added support. What did I break? > >Should I just give up now, while I can, before I involuntarily end up as > >a BFD hacker? > > > Welcome to the dark side :-) I'm actually finding it a lot easier than I had originally imagined; I guess this is due to the plentiful helpful comments all over the code. Thanks for that, people! - -- http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c) I've generally found that the fastest way to get the right answer on the net is to confidently assert the answer you believe to be right; those who know will immediately correct you, while if you just ask, often no answers arrive. All it requires is a willingness to look bad on occasion. - Joe Buck on gcc@gcc.gnu.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAmS8u/FmLrNfLpjMRAgtIAJ4u5L8kzIelBvqWZjgSlD4GrV7wrQCcD2gJ 6oO0dOQiWSXilHkMAWi3KZQ= =fz+6 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Linking nominally incompatible object files 2004-05-05 18:20 ` Bernd Jendrissek @ 2004-05-06 13:32 ` Nick Clifton 2004-05-07 9:07 ` Bernd Jendrissek 0 siblings, 1 reply; 6+ messages in thread From: Nick Clifton @ 2004-05-06 13:32 UTC (permalink / raw) To: Bernd Jendrissek; +Cc: binutils Hi Bernd, >>Reloc 2 is for a function call. >> >> > >It is for v850 indeed. Which is why I'm surprised that the linker >claims it's *not* supported. > > Agreed - it is quite strange. >I notice now that in my "new" file bfd/elf32-v800.c (*derived* from, not >replacing elf32-v850.c!) the token "R_V850_22_PCREL" appears only in the >macro call to HOWTO - IOW it is otherwise unhandled. > This is probably not quite true. If the "special_function" field is set to "bfd_elf_generic_reloc" then the generic reloc handling code in bfd/elf.c will handle the processing of the reloc. >>Neither and both. It is supposed to interpret them based on the target >>architecture that it was built to support. When it is built to support >>more than one architecture then it is supposed to select the relocs that >>is supports based upon the input file that it is processing. >> >> > >So if I configured my binutils with --enable-targets=all, the linker >*should* interpret the relocs based on the input file in which they >appear? > Yes - but only if it can tell the difference between the input file types. In particular if both the GNU toolchain and the Green Hills toolchain are using the same machine number in the ELF header's e_machine field then the linker will not be able to distinguish them. (See elf_object_p() in bfd/elfcode.h). Also note that for a lot of targets with related variants (eg ARM, MIPS etc) a supplementary mechanism is used to distinguish between variants. This can be flags in the e_flags of the header or a special section in the object file containing information about how the file was compiled. The v850 port uses the flags method. (See bfd/elf32-v850.c:v850_elf_object_p()). If this function is unable to distinguish between Green Hills object files and GNU object files then it will be unable to set the correct (internal BFD) machine number and then the linker will not be able to determine which kind of relocs it should be processing. >Seriously, what sort of circumstances could cause ld to bail like this? >I would have thought that relocs always operate on bits in the same >object file as where the relocs are. Isn't that the whole point of BFD, >to abstract object files as just BFDs which can then be linked together >in an architecture-independent way? > > Yes - but the *meaning* of a reloc is not encoded within the reloc structure stored in the object file. All the linker has to go on is a reloc number. (Plus the knowledge of the target architecture of the object file). If the linker encounters a reloc number that it has not been programmed to handle (for a given architecture) then all it can do it complain. It has no way to derive the semantics of the reloc. >So, because my new linker is configured to produce v800 *output*, all >*input* object files have their relocs interpreted as v800 relocs as >well! Now, what do I do about it? Hah! I do this: > >- --- binutils/bfd/elflink.h.borig Wed Jan 14 23:07:43 2004 >+++ binutils/bfd/elflink.h Wed May 5 19:39:49 2004 >@@ -4678,7 +4678,7 @@ > struct elf_link_hash_entry **sym_hashes; > > output_bfd = finfo->output_bfd; >- - bed = get_elf_backend_data (output_bfd); >+ bed = get_elf_backend_data (input_bfd); > relocate_section = bed->elf_backend_relocate_section; > > /* If this is a dynamic object, we don't want to do anything here: > >And now the only "not SUPPORTED" relocs are the v800 ones for which I >haven't yet added support. What did I break? > > In theory, only the assumption that input_architecture == output_architecture. Well actually a lot more than that. For example the decision about whether relocs should be copied into the output file is specific to the output file architecture (bed->elf_backend_emit_relocs). Or the routine to be used to emit the relocated section (bed->elf_backend_write_section). It looks like elf_link_input_bfd() needs some tidying up to remove assumptions about input and output architectures. Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Linking nominally incompatible object files 2004-05-06 13:32 ` Nick Clifton @ 2004-05-07 9:07 ` Bernd Jendrissek 2004-05-07 14:00 ` Nick Clifton 0 siblings, 1 reply; 6+ messages in thread From: Bernd Jendrissek @ 2004-05-07 9:07 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, May 06, 2004 at 02:36:27PM +0100, Nick Clifton wrote: > >I notice now that in my "new" file bfd/elf32-v800.c (*derived* from, not > >replacing elf32-v850.c!) the token "R_V850_22_PCREL" appears only in the > >macro call to HOWTO - IOW it is otherwise unhandled. > > > This is probably not quite true. If the "special_function" field is set > to "bfd_elf_generic_reloc" then the generic reloc handling code in > bfd/elf.c will handle the processing of the reloc. I'm not going to worry about this; it's square peg round hole now - the relocs were getting interpreting by the wrong backend, AFAICT and IMHO. Fix that (trying to avoid breaking other stuff), and the problem goes away. > >>Neither and both. It is supposed to interpret them based on the target > >>architecture that it was built to support. When it is built to support > >>more than one architecture then it is supposed to select the relocs that > >>is supports based upon the input file that it is processing. > > > >So if I configured my binutils with --enable-targets=all, the linker > >*should* interpret the relocs based on the input file in which they > >appear? > > > Yes - but only if it can tell the difference between the input file > types. In particular if both the GNU toolchain and the Green Hills > toolchain are using the same machine number in the ELF header's > e_machine field then the linker will not be able to distinguish them. It seems able to distinguish them. Is e_machine the field that holds EM_V800 or EM_V850 or EM_<machine> in general? I'm only asking because the machine type seems to be encoded somewhere else as well: I hex-edit my GCC-compiled object file (carefully avoiding generating relocs; just symbols) to change the EM_V850 to EM_V800 at file offset 0x12, which makes the Green Hills linker happy enough to link the file in, but their "gdump" utility still says e_machine = <<< unknown V800 machine type (0x24) >>> but their own object files have exactly the same 0x24! > (See elf_object_p() in bfd/elfcode.h). Also note that for a lot of > targets with related variants (eg ARM, MIPS etc) a supplementary > mechanism is used to distinguish between variants. This can be flags in > the e_flags of the header or a special section in the object file > containing information about how the file was compiled. Thanks; I'll check that out if/when I fold my hackery back into the v850 bits. In the v850 case, the use is to subtly influence the set of valid instructions, no? Or is there much beyond that? > The v850 port uses the flags method. (See > bfd/elf32-v850.c:v850_elf_object_p()). If this function is unable to > distinguish between Green Hills object files and GNU object files then > it will be unable to set the correct (internal BFD) machine number and > then the linker will not be able to determine which kind of relocs it > should be processing. Actually, they differ more fundamentally: ELF_MACHINE_CODE has to be EM_V800 (not EM_V850) to even start interoperating with Green Hills. > >Seriously, what sort of circumstances could cause ld to bail like this? > >I would have thought that relocs always operate on bits in the same > >object file as where the relocs are. Isn't that the whole point of BFD, > >to abstract object files as just BFDs which can then be linked together > >in an architecture-independent way? > > > Yes - but the *meaning* of a reloc is not encoded within the reloc > structure stored in the object file. All the linker has to go on is a > reloc number. (Plus the knowledge of the target architecture of the > object file). If the linker encounters a reloc number that it has not > been programmed to handle (for a given architecture) then all it can do > it complain. It has no way to derive the semantics of the reloc. Yes, I understood that - that's why the reloc interpretation should be delegated the the backend *for that input file*, no? You later mention the possibility of only the output bfd knowing whether to copy relocs or not; that may throw a spanner in my works. > >So, because my new linker is configured to produce v800 *output*, all > >*input* object files have their relocs interpreted as v800 relocs as > >well! Now, what do I do about it? Hah! I do this: > > > >- --- binutils/bfd/elflink.h.borig Wed Jan 14 23:07:43 2004 > >+++ binutils/bfd/elflink.h Wed May 5 19:39:49 2004 > >@@ -4678,7 +4678,7 @@ > > struct elf_link_hash_entry **sym_hashes; > > > > output_bfd = finfo->output_bfd; > >- - bed = get_elf_backend_data (output_bfd); > >+ bed = get_elf_backend_data (input_bfd); > > relocate_section = bed->elf_backend_relocate_section; > > > > /* If this is a dynamic object, we don't want to do anything here: > > > >And now the only "not SUPPORTED" relocs are the v800 ones for which I > >haven't yet added support. What did I break? > > In theory, only the assumption that input_architecture == > output_architecture. In "theory"? Do you think that assumption is manifested anywhere? > Well actually a lot more than that. For example the decision about > whether relocs should be copied into the output file is specific to > the output file architecture (bed->elf_backend_emit_relocs). I'm afraid I'm lost now; I'll have to try following elf_backend_emit_relocs again later. > Or the routine to be used to emit the relocated section > (bed->elf_backend_write_section). It looks like elf_link_input_bfd() > needs some tidying up to remove assumptions about input and output > architectures. Am I the only one who's ever tried to link together object files of differing BFD backends? - -- http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c) I have neither the need, the time, or the inclination to put words into your mouth. You are perfectly capable of damaging your reputation without any help from me. --Richard Heathfield roasts a troll in comp.lang.c -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAm1B//FmLrNfLpjMRAoa8AJ0cuDwvQ/qnab2pGlFCcy2OSC9VYACgoQib 6OKlTDTzu8gZLFecs5twfJE= =RLBj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Linking nominally incompatible object files 2004-05-07 9:07 ` Bernd Jendrissek @ 2004-05-07 14:00 ` Nick Clifton 0 siblings, 0 replies; 6+ messages in thread From: Nick Clifton @ 2004-05-07 14:00 UTC (permalink / raw) To: Bernd Jendrissek; +Cc: binutils Hi Bernd, > <>It seems able to distinguish them. Is e_machine the field that holds > EM_V800 or EM_V850 or EM_<machine> in general? Yes. > <> I'm only asking because > the machine type seems to be encoded somewhere else as well: I hex-edit > my GCC-compiled object file (carefully avoiding generating relocs; just > symbols) to change the EM_V850 to EM_V800 at file offset 0x12, which > makes the Green Hills linker happy enough to link the file in, but their > "gdump" utility still says > e_machine = <<< unknown V800 machine type (0x24) >>> > but their own object files have exactly the same 0x24! It may be the changing of the relocs that makes the linker happy. I suspect that the gdump utility is checking some other fields in the ELF header as well as the e_machine field and that this is why it is complaining. (Although really it ought to say so, if this is the case). Likely candidates are the e_version and e_flags fields. >>(See elf_object_p() in bfd/elfcode.h). Also note that for a lot of >>targets with related variants (eg ARM, MIPS etc) a supplementary >>mechanism is used to distinguish between variants. This can be flags in >>the e_flags of the header or a special section in the object file >>containing information about how the file was compiled. >> >> > >Thanks; I'll check that out if/when I fold my hackery back into the v850 >bits. In the v850 case, the use is to subtly influence the set of valid >instructions, no? Or is there much beyond that? > > No that is about it. >>Yes - but the *meaning* of a reloc is not encoded within the reloc >>structure stored in the object file. All the linker has to go on is a >>reloc number. (Plus the knowledge of the target architecture of the >>object file). If the linker encounters a reloc number that it has not >>been programmed to handle (for a given architecture) then all it can do >>it complain. It has no way to derive the semantics of the reloc. >> >> > >Yes, I understood that - that's why the reloc interpretation should be >delegated the the backend *for that input file*, no? > Yes. (ie I agree with you). > You later mention >the possibility of only the output bfd knowing whether to copy relocs or >not; that may throw a spanner in my works. > > Right, but this was referring to whether the output file architecture needs to preserve (or transform) some of the relocs in the input files. For some targets, eg ones using shared libraries, some relocs are not processed by the linker but held in the executable and processed at program-load-time. >>>And now the only "not SUPPORTED" relocs are the v800 ones for which I >>>haven't yet added support. What did I break? >>> >>> >>In theory, only the assumption that input_architecture == >>output_architecture. >> >> > >In "theory"? Do you think that assumption is manifested anywhere? > > Probably. You see normally you would not expect to be able to link together object files for different architectures. eg you would not expect to be able link together ARM object files and MIPS object files. Hence the linker generally assumes that it is linking only one kind of input file. The linker does have some support for generating an output file that is in a different format from the input file, but this is really intended for transforming the executable into some kind of ROM friendly format (eg Intel iHex). This only works if the output format is architecture neutral, and it does not work for all targets either. So for most users it is simpler to linker together identical architecture input files to form a matching format output file and then, if necessary, use the objcopy utility to change the file format of the executable. In your case, where the underlying architecture is the same, and you are just trying to handle different reloc encoding schemes, the linker should be able to adapt. There is no theoretical reason why the linker cannot handle both Green Hills and GNU style relocs, but I do not know if anyone has tried something like this before, so you may well run into difficulties. Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-07 14:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-02 16:41 Linking nominally incompatible object files Bernd Jendrissek 2004-05-05 16:26 ` Nick Clifton 2004-05-05 18:20 ` Bernd Jendrissek 2004-05-06 13:32 ` Nick Clifton 2004-05-07 9:07 ` Bernd Jendrissek 2004-05-07 14:00 ` Nick Clifton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).