Re: Octave & Fortran continued

[Michael Goffioul]

On Fri, Jan 9, 2009 at 1:57 PM, Benjamin Lindner <address@hidden> wrote:
> The problem I find ist that -shared-libgcc is not honoured as link flag,
> although it should be. So building with shared libgcc and shared libstd++
> fails (well, it does not fail, it simply does not link against the shared
> libgcc which results in subtle errors later on when linking with a library -
> which is worse than if it would fail just at link stage. Took me quite some
> time to track this down, sigh...)

I don't link against shared libgcc or libstdc++. Is there any advantage
in doing so (except file size, which is not such a big deal)?

> True, I followed the windows-way and removed at least the prefix in every
> lib. Not all libs use it and I saw no point in mixing, so I removed it
> generally. I also found that where win32 compiled versions are available for
> download, they also do not use the lib prefix (e.g. fftw, zlib) - so there
> seems to be no general consensus on how to name them.
>
> I frankly also don't see the point in the -yyy flag. It's not a version
> number. I admit that I have kept some postfixes and removed some, no general
> pattern here.
>
> But that's cosmetic, so we should agree on doing it one way and do it
> consistently.
>
> I once thought about adding a octave-specific prefix, e.g. "oct", to be sure
> that any library already-installed-and-maybe-in-a-preceeding-path does not
> conflict with the ones shipped with the binary installer.
> (I ran into problems with jpeg and png library)
> Comment?

IMO, it's better to go with lib prefix, because libraries compiled with
libtool use it. And a big part of stuffs included in the binary package
uses libtool. This means you can compile modules out of the box
with mingw, without touching the sources. The only modules you have
to care about are those that do not use lib prefix and that do not have
a libtool-based build scheme (sometimes you have a libtool-based build
and a Win32-dedicated build, in that case, I use the libtool one).

Michael.