Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.dsp > #7139 > unrolled thread

g21k and ar

Back to article view | Back to comp.dsp

Contents

  g21k and ar Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-24 09:18 +0100
    Re: g21k and ar - COFF DSP21K filetype Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-24 13:40 +0100
      Re: g21k and ar - COFF DSP21K filetype Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-11-24 15:54 +0200
        Re: g21k and ar - COFF DSP21K filetype Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-24 15:41 +0100
          Re: g21k and ar - COFF DSP21K filetype Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-11-24 21:02 +0200
            Re: g21k and ar - COFF DSP21K filetype Alessandro Basili <alessandro.basili@cern.ch> - 2011-11-25 09:48 +0100

#7139 — g21k and ar

Hi all,
after some work I managed to compile g21k (a gcc port for ADSP21k
architecture) and I used it to cross-compile the whole ADI C-runtime
library (ref. <news:9gj66aFvuvU1@mid.individual.net>)

So now I have the following pieces:

- g21k     (compiler)
- asm21k   (assembler)
- ld21k    (linker)
- mem21k   (memory initializer)
- cdump21k (a coff dump utility)

After I compiled the C-runtime library I naively thought to use ar to
make an archive - that I called libc.a - but unfortunately when I link
against it from my application, it looks like the linker does not find a
symbol directory and I get the following errors:

> Archive symbol directory is missing from archive /usr/local/21k/lib/libc.a
> Archive symbol directory in archive /usr/local/21k/lib/libc.a is too large
> Can't read archive symbol directory of archive /usr/local/21k/lib/libc.a

It looks like the archiver failed to create a symbol directory (indeed
nm does not recognize the object format, since i believe the coff
produced by the linker is not supported by gnu binutils).

It is somehow frustrating since I'm only missing a very small part of
the whole and it will be a shame, after so much effort, to give up.
Unfortunately the author of the port seems does not reply to emails,
while the mailing list seems somehow defunct. Alternative efforts to
find people who previously worked with this tool have not been fruitful
(understandable to some extent, since we are talking about a 20 y.o. tool!).

If anyone out there has any solution/suggestion/advice I would really
appreciate.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[toc] | [next] | [standalone]

#7141 — Re: g21k and ar - COFF DSP21K filetype

On 11/24/2011 9:18 AM, Alessandro Basili wrote:
> [...]
> It looks like the archiver failed to create a symbol directory (indeed
> nm does not recognize the object format, since i believe the coff
> produced by the linker is not supported by gnu binutils).

I have found that the object files produced by the cross-compiler are of
type "COFF DSP21K" and if I want to archive them apparently ar does not
create an archive symbol directory.

Now my question would be, is there any tool/application/trick to archive
these objects in order to create a library?

Does anyone in the community know why the application /file/ does
recognize the format, while /ar/ and /nm/ others do not?

[toc] | [prev] | [next] | [standalone]

#7142 — Re: g21k and ar - COFF DSP21K filetype

On 24.11.11 2:40 , Alessandro Basili wrote:
> On 11/24/2011 9:18 AM, Alessandro Basili wrote:
>> [...]
>> It looks like the archiver failed to create a symbol directory (indeed
>> nm does not recognize the object format, since i believe the coff
>> produced by the linker is not supported by gnu binutils).
>
> I have found that the object files produced by the cross-compiler are of
> type "COFF DSP21K" and if I want to archive them apparently ar does not
> create an archive symbol directory.
>
> Now my question would be, is there any tool/application/trick to archive
> these objects in order to create a library?
>
> Does anyone in the community know why the application /file/ does
> recognize the format, while /ar/ and /nm/ others do not?

If the binary utilities are based on the old GNU tools,
you should run the appropriate ranlib against the library
to create the symbol directory in it.

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#7144 — Re: g21k and ar - COFF DSP21K filetype

On 11/24/2011 2:54 PM, Tauno Voipio wrote:
> On 24.11.11 2:40 , Alessandro Basili wrote:
>> On 11/24/2011 9:18 AM, Alessandro Basili wrote:
>>> [...]
>>> It looks like the archiver failed to create a symbol directory (indeed
>>> nm does not recognize the object format, since i believe the coff
>>> produced by the linker is not supported by gnu binutils).
[...]
> 
> If the binary utilities are based on the old GNU tools,
> you should run the appropriate ranlib against the library
> to create the symbol directory in it.
> 

If the binary utilities you are referring to are the one for the g21k,
than there's no archiver in the g21k-binutils.
Only programs in the g21k-binutils are the following:

a21000
asm21k
mem21k
ld21k
cdump
coffdump

If the binary utilities you are referring to are the one from GNU than
my problem is that neither /ar -s/ nor /ranlib/ will create any symbol
directory.

[toc] | [prev] | [next] | [standalone]

#7146 — Re: g21k and ar - COFF DSP21K filetype

On 24.11.11 4:41 , Alessandro Basili wrote:
> On 11/24/2011 2:54 PM, Tauno Voipio wrote:
>> On 24.11.11 2:40 , Alessandro Basili wrote:
>>> On 11/24/2011 9:18 AM, Alessandro Basili wrote:
>>>> [...]
>>>> It looks like the archiver failed to create a symbol directory (indeed
>>>> nm does not recognize the object format, since i believe the coff
>>>> produced by the linker is not supported by gnu binutils).
> [...]
>>
>> If the binary utilities are based on the old GNU tools,
>> you should run the appropriate ranlib against the library
>> to create the symbol directory in it.
>>
>
> If the binary utilities you are referring to are the one for the g21k,
> than there's no archiver in the g21k-binutils.
> Only programs in the g21k-binutils are the following:
>
> a21000
> asm21k
> mem21k
> ld21k
> cdump
> coffdump
>
> If the binary utilities you are referring to are the one from GNU than
> my problem is that neither /ar -s/ nor /ranlib/ will create any symbol
> directory.

That's what is expected. ar is a part of the binutils package, and
it is target-specific. You cannot expect i386+ archiver to function
correctly with a foreign architecture.

 From where did you get the sources for the 21k binary utilities?

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#7149 — Re: g21k and ar - COFF DSP21K filetype

On 11/24/2011 8:02 PM, Tauno Voipio wrote:
> [...]
>> If the binary utilities you are referring to are the one from GNU than
>> my problem is that neither /ar -s/ nor /ranlib/ will create any symbol
>> directory.
> 
> That's what is expected. ar is a part of the binutils package, and
> it is target-specific. You cannot expect i386+ archiver to function
> correctly with a foreign architecture.
> 
> From where did you get the sources for the 21k binary utilities?
> 

you can find the source here:

http://code.google.com/p/g21k/updates/list

it took me a while though to compile it under my system. I tried to
contact the maintainer of the project but no joy. I'm willing to create
a tarball for myself anytime soon. I also plan to change the use of
deprecated functions like tempnam and solve some issues with LONG
formats that will cause a shift operation to issue a warning.

I'm not sure if the whole C-runtime library was released under GPL by
Analog Devices (need to check), if this is the case I will not be able
to make it available for public use.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.dsp

csiph-web