Please disregard my previous message in this thread, which was sent by
mistake. (Stupid fingers!)
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Eric Smith schreef op za 12-05-2012 om 11:22 [-0700]:
If a mingw package build produces a ".a" file that is not usable as a
static library, is there any reason to include that ".a" file in the
package at all?
On 05/12/2012 11:41 AM, Erik van Pienbroek wrote:
As far as I&
If a mingw package build produces a ".a" file that is not usable as a
static library, is there any reason to include that ".a" file in the
package at all?
The specific case I'm wondering about is mingw-pthreads. I need a
static version, and mingw-pthreads needs special attention to build a
s
Kalev Lember wrote:
Not sure, depends on if there are any apps would actually use it. It
might very well be that everything uses pkg-config .pc files instead
and the config script is just provided for backwards compatibility.
The llvm-config script does some fancy dependency analysis of the L
Kalev Lember wrote:
I have a vague recollection that llvm supports both autotools and
cmake builds systems. Perhaps another idea would be to use cmake, if
it's easier to cross compile llvm with it?
LLVM's cmake build system cannot produce the DLLs at all, so I'll stick
with the autotools.
I think I may have found why I'm not getting any .dll.a and .la files for
mingw-llvm.
"the LLVM source code lacks the symbol export directives, [...]
The autoconf build exploits a feature of MinGW's binutils
that auto-exports all symbols, like in Linux."
[from the thread:
http://c
I've finally found time to work on preparing a mingw-llvm-3.0 package,
so that I can cross-compile a program that uses the LLVM libraries.
I've run into a few problems that I could use some help with.
1) The %mingw_configure macro defines a bunch of environment variables
such as AR, CXX, GC
