On 17/04/2010 21:32, Paul Bibbings wrote:
> The .dlls in question are:
>
> 21:10:29 Paul bibbi...@jijou
> ~ $ls -l /opt/gcc-4.5.0/bin | grep dll
> -rwxr-xr-x 1 ... 437743 Apr 15 09:08 cyggcc_s-1.dll
> -rwxr-xr-x 1 ... 271146 Apr 15 09:08 cyggomp-1.dll
> -rwxr-xr-x 1 ... 55679 Apr 15 09:08 cygssp-0.dll
> -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
>
> Maybe I am missing something in having these in the first place. I
> didn't get any new .dlls for gcc-4.4.1, for instance:
That'd be my fault. GCC never used to build DLLs for anything, except
libgcc, prior to 4.5. Now it does, for all languages. (At last, the simplest
possible "hello world" in java isn't 45 megabytes any more.) They install
into $bindir, because that's where they need to be to be found easily;
alongside the executables that require them.
Like a lot of libraries, they occasionally sprout new interfaces, but they
should always remain backwardly-compatible. Applications compiled with older
GCC against older versions of the DLL ought to run just fine with the newer
ones (it's a bug if they don't), but of course applications compiled with the
newer compilers that actually make use of the new features in the newer
versions of the DLLs won't be able to work with older ones.
From the end-user's point of view, the simple solution would be to not worry
about switching them round or alternatives or any of that, but just make sure
the newest ones are at the front of your $PATH at all times, you could even
feel free to install them straight into /usr/bin and just overwrite the
existing versions; everything should still work.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
