Re: Sparc cross-toolchain and libiconv-2.dll

Re: Sparc cross-toolchain and libiconv-2.dll

[David Paterson]

Quick PS after more googling - I also have "--disable-nls" in the
configuration params, so I definitely shouldn't need libiconv...


On 27 May 2014 16:16, David Paterson <dnpaterson@gmail.com> wrote:
>
> Hi folks,
>
> I'm trying to rebuild my Sparc (LEON) toolchain using the latest versions of
> all the GCC packages, in particular gcc-4.8.2, but it now seems to need
> access to the library libiconv-2.dll in order to run.
>
> I'm building under MinGW, and gcc runs happily in that environment (as the
> DLL is in mingw/bin).  However, running either in a DOS command window, or
> via Eclipse, it's failing as it can't find a path to the DLL.
>
> I get the same result (as you might expect) when I copy the toolchain to
> another machine.  Since I don't want to install MinGW on the other system,
> I'm looking for a way to remove the dependency, rather than finding the
> path.
>
> My older version, based on gcc-4.6.1 didn't have this problem, and from
> various searches it looks like this DLL is only required for Java, which I'm
> not configuring for - only C and C++.   (I could perhaps go back to the
> older version, but I've reinstalled MinGW and the newer compiler apparently
> won't build older versions, plus I'll have to move up to newer versions
> eventually, so really want to find a solution.)
>
> This DLL appears in quite a lot of search results, often as "missing" from
> application installations, and occasional bug reports for GNU tools, but I
> can't see any explanation of how to disable its use in a cross tool build.
>
> Any suggestions would be appreciated.
>
> Regards,
>
> David P.

Sparc cross-toolchain and libiconv-2.dll

[David Paterson]

Hi folks,

I'm trying to rebuild my Sparc (LEON) toolchain using the latest
versions of all the GCC packages, in particular gcc-4.8.2, but it now
seems to need access to the library libiconv-2.dll in order to run.

I'm building under MinGW, and gcc runs happily in that environment (as
the DLL is in mingw/bin).  However, running either in a DOS command
window, or via Eclipse, it's failing as it can't find a path to the
DLL.

I get the same result (as you might expect) when I copy the toolchain
to another machine.  Since I don't want to install MinGW on the other
system, I'm looking for a way to remove the dependency, rather than
finding the path.

My older version, based on gcc-4.6.1 didn't have this problem, and
from various searches it looks like this DLL is only required for
Java, which I'm not configuring for - only C and C++.   (I could
perhaps go back to the older version, but I've reinstalled MinGW and
the newer compiler apparently won't build older versions, plus I'll
have to move up to newer versions eventually, so really want to find a
solution.)

This DLL appears in quite a lot of search results, often as "missing"
from application installations, and occasional bug reports for GNU
tools, but I can't see any explanation of how to disable its use in a
cross tool build.

Any suggestions would be appreciated.

Regards,

David P.