octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave & Fortran continued


From: Benjamin Lindner
Subject: Re: Octave & Fortran continued
Date: Fri, 09 Jan 2009 14:57:28 +0100
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)

Michael Goffioul wrote:
On Thu, Jan 8, 2009 at 5:41 PM, Benjamin Lindner <address@hidden> wrote:
Official MinGW gcc is not buggy per-se, but I found 2 problems that are
easy to fix:
1) some headers are missing in the g++ archive, but they are contained
in the full .7z archive
Yes, this was the bugginess I referred to.

Installing the full archive works fine.


Might be so, but as I want to ship the compiler along with the installer, and *not* want to ship the complete archive, I moved to TDM's port, where I can package the compiler used for building easily with the installer.


[Note: I also got some problems in making old libtool work with that
version of gcc, such that I had to re-libtoolize a few packages; maybe
tdm-gcc works better in that area...]
Hmm, which problems were these? I only encountered one with newer libtool as
used in fftw3 versino 3.2 where linker-options are not correctly recognized.

To generate shared libraries, the old libtool script does various complex
steps involving dlltool. The new libtool script simply uses
"g++ -shared -Wl,--export-all-symbols..." and it works fine. IIRC, the step
that failed was the dlltool-step: it tries to export some standard DLL symbol
(I don't remember which one, but something like DllRegisterServer or so;
one of those standard symbols in DLL)

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...)

Benjamin, are you OK to merge our work? If yes, are you OK that I
make an initial proposal for build scripts and we start from there?
Yes and Yes. Go ahead and I'll put my 2 cents in when appropriate :)

One thing that we did differently is about library naming convention.
I'm now naming all libraries as libxxx-yyy.dll: where xxx is the module
name, and yyy is the module version (as generated by libtool). AFAIK,
you don't use the lib prefix.


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?

benjamin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]