[Mingw-w64-public] [PATCH] headers: Fix CREATE_VIRTUAL_DISK_PARAMETERS
Hello all,
The attached patch fixes the CREATE_VIRTUAL_DISK_PARAMETERS structure
virtdisk.h. The missing field is documented in MSDN:
https://learn.microsoft.com/en-us/windows/win32/api/virtdisk/ns-virtdisk-create_virtual_disk_parameters
Best regards,
Pavel
From e767c5c2b766c4f060c502a4b484c0a047332aa8 Mon Sep 17 00:00:00 2001
From: Pavel Shishpor
Date: Sat, 26 Aug 2023 12:45:44 +0200
Subject: [PATCH] headers: Fix CREATE_VIRTUAL_DISK_PARAMETERS
In accordance with MSDN:
https://learn.microsoft.com/en-us/windows/win32/api/virtdisk/ns-virtdisk-create_virtual_disk_parameters
Signed-off-by: Pavel Shishpor
---
mingw-w64-headers/include/virtdisk.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/include/virtdisk.h
b/mingw-w64-headers/include/virtdisk.h
index e929ef966..047beb8b5 100644
--- a/mingw-w64-headers/include/virtdisk.h
+++ b/mingw-w64-headers/include/virtdisk.h
@@ -308,6 +308,7 @@ typedef struct _CREATE_VIRTUAL_DISK_PARAMETERS {
ULONGLONG MaximumSize;
ULONG BlockSizeInBytes;
ULONG SectorSizeInBytes;
+ ULONG PhysicalSectorSizeInBytes;
PCWSTR ParentPath;
PCWSTR SourcePath;
OPEN_VIRTUAL_DISK_FLAG OpenFlags;
--
2.42.0.windows.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How the program is runing in windowsxp?
Hello, I think this is not sufficient. -D__USE_MINGW_ANSI_STDIO should help, however, my experience is that it somehow cripples swprintf with %s placeholder on post-XP systems. So you always need to create separate build for XP, if you want to support that system :-( Pavel On Mon, 2016-04-11 at 14:21 +0200, julien.darthe...@laposte.net wrote: > Hello, > > Can you try to build your program with the g++ flag "-D_WIN32_WINNT=0x0501" > or maybe "-D_WIN32_WINNT=0x0502"? > > - Mail original - > > De: "kl222" <kl...@126.com> > À: "mingw android" <mingw.andr...@gmail.com> > Cc: mingw-w64-public@lists.sourceforge.net > Envoyé: Lundi 11 Avril 2016 03:42:18 > Objet: [Mingw-w64-public] How the program is runing in windowsxp? > > Hi all: > > I use mingw g++ to build a programe. It is running in windows 7 and > laster. But it don't run in windowsxp. > > Use msvc 2013 tools chains build a programe with parameter > /SUBSYSTEM:WINDOWS",5.01" . It is running in windowsxp. > > How do use mingw g++? > > > > Thinks! > > -- > > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ > gampad/clk?id=1444514301=/ca-pub-7940484522588532 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ > gampad/clk?id=1444514301=/ca-pub-7940484522588532 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Contributing a package
Hi! Done, added Pavel Fedin (sonic_amiga). You can push the code to ssh://git.code.sf.net/p/mingw-w64/portablexdr It can be moved to github or elsewhere if it really shouldn't go into mingw-w64. Thank you very much. I heard the voice of other people, so i will ask MSYS2 guy first. If it doesn't work for some reason, i'll at least put the source code. P.S. With some stretch of imagination we could think that portablexdr has the same role as winpthreads (portability improvement)... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Contributing a package
Hi! What is your sourceforge ID? It's sonic_amiga. And it's still operational, to my great surprise :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Contributing a package
Hello! IMHO, no project is too small for a separate project page and repository. And I don't see how this could ever belong inside the mingw-w64 project, honestly, as it is not related to the Windows runtime in any way (unless I'm missing something, which is very well possible). Is mingw-w64 strictly limited to compiler and runtime only? I thought it's not, i've seen some ported packages in External binary packages and 3rd party development tools. I thought portablexdr would perfectly fit there. If you find Sourceforge too daunting, there's also the now more popular platform github, and numerous other alternatives where you can dump your source code. I believe that github will give it the greatest visibility though in the current open source world of hosting new projects. No, i don't. I would not like to set up a separate project only because the actual scope of portablexdr improvement is limited. There will be some bug fixes and code upgrades to fix warnings, but that's all. After this it will be frozen. See also the MSYS2 packages for libvirt and portablexdr which you may consider contributing the changes to: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-libvirt https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-portablexdr Ok, i can check with Alex about that. I just thought that gathering the complete set of various tools and useful packages (like MinGW32 and Cygwin projects do) is a good idea. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Contributing a package
Hello! I am currently building libvirt (http://libvirt.org/) for 64-bit Windows. The ultimate goal is to get virt-manager (https://virt-manager.org/) running. Building libvirt requires Sun (now ONC) RPC headers and RPC code generator. Since MinGW doesn't have them i decided to use portablexdr (http://people.redhat.com/~rjones/portablexdr/). Actually this is what Redhat does, they cross-build Windows version of libvirt on Linux machine. portablexdr package as it is currently have some bugs, i had to fix them in order to be able to use it. I tried to post them back to Redhat, but Richard replied that support for portablexdr was stopped because Oracle relicensed original RPC code. So they don't accept patches and don't plan to develop it furtner. However, looks like it's the simplest way to go on Windows, because we anyway don't have any RPC code ported. And i guess porting TI-RPC is more complex task. So i would like to take over portablexdr and contribute the package to MinGW64. The question is - how can i do it ? What do i need in order to be able to upload it ? Also it would be nice to be able to host a repository on MinGW64 sourceforge page, because Richard told me that they don't give away maintainership of their code repositories, and if i want to go on with portablexdr (which is perfectly OK by itself), i'll have to set up my own repository. Could anybody help me with that ? I believe setting up a separate project on sf.net would be too much for that. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Confused by apparent conflicting swprintf declaration in swprintf.inl
On Fri, 2015-05-15 at 00:43 +1000, Shaddy Baddah wrote:
Hi,
I've been trying to use mingw-64 to build the eclipse native launcher
(.exe).
I encountered an issue around the indirect (via preprocessor defines) of
swprintf.
The eclipse code usage of swprintf suggested that the declaration should
match this (from
https://msdn.microsoft.com/en-us/library/aa272937%28v=vs.60%29.aspx):
int swprintf( wchar_t *buffer, const wchar_t *format [, argument] ... );
However, the declaration in mingw-w64-headers/crt/swprintf.inl, at least
outside the C++ scope, it is defined with the extra size_t __count
argument:
int swprintf (wchar_t *__stream, size_t __count, const wchar_t
*__format, ...)
I mention the C++ scope, because the declaration in the same
swprintf.inl file seems to conflict with the one above it (and match
that of the MSDN link):
#ifdef __cplusplus
extern C++ {
...
int swprintf (wchar_t *__stream, const wchar_t *__format, ...)
So my first confusion is the mismatch in the same file.
The second is, I've also seen an article which shows the second,
problematic (for the eclipse build) form:
https://msdn.microsoft.com/en-us/library/ybk95axf.aspx
The third confusion is that I've already seen that mingw-64 developers
seemingly rejected the first form I've specified. That's what I gather
from the rejection of this bug:
http://sourceforge.net/p/mingw-w64/bugs/332/
and another bit of discussion I can no longer bring up.
I've thrown a bit out there. So first thing is, it is not a
bug/incorrect for the two different declarations to be in swprint.inl?
Is the eclipse code wrong to use the first form, over the second? The
code is C and not C++.
It looks like the first version should be swprintf_s
https://msdn.microsoft.com/en-us/library/ce3zzk1k.aspx
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling SDL2
On Tue, 2015-04-28 at 09:25 +0200, Ruben Van Boxem wrote:
2015-04-28 8:36 GMT+02:00 Pavel pa...@pamsoft.cz:
On Tue, 2015-04-28 at 08:08 +0200, Christer Solskogen wrote:
On 27.04.2015 20:16, LRN wrote:
At a glance it looks like SDL_render_d3d11.c declares and
defines
IID_IDXGIFactory2, and mingw's dxgi1_2.h declares
IID_IDXGIFactory2 as well
(and defines it in some library, likely libuuid.a).
Apparently, SDL2 was written against a SDK (likely
mingw.org) that has no
IID_IDXGIFactory2.
The fix is to remove
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c,
0xe072, 0x4c48, { 0x87,
0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
from SDL2 (or at least ifdef it out based on some macro
from dxgi1_2.h).
At a glance, anyway.
Okay? Compiling SDL2 using v3.x (git) works just fine.
This is nothing surprising. The UIDs and interface definitions
are
constantly added to the MinGW source (includes). For example,
I have an
application using MSXML. There were no definitions for MSXML
interfaces
so I had to add my own. It compiled fine with MinGW 3.x, but
the MSXML
UIDs and interfaces has been added in MinGW 4.x. So I had to
remove my
definitions in order to compile my project with MinGW 4.x.
This is
called progress or evolution :-)
This progress would go faster if *all* upstream projects would just
contribute these changes back instead of hiding them in their headers.
I know a lot of them are already doing this, and it may just be a
remnant of the stale MinGW.org developer policy to accepting and
implementing such changes. Here's me hoping for a brighter future :p
/rant
Well, I am just a (happy) user of MinGW64, but I believe this is not a
problem of upstream projects. This is a general problem of COM objects
available in the OS. There are plenty of COM libraries delivered by
Windows and other dozens of those delivered by installed applications.
It is neither possible nor desirable to deliver all the definitions with
the compiler. It would be much better to provide a generic tool capable
of reading type libraries and generating C++ headers for them. I have
developed such a tool many years ago. Unfortunately it is written in
Delphi, so it would be a shame to share the source code. But maybe I can
consider rewriting it into C++.
Pavel
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling SDL2
On Tue, 2015-04-28 at 08:08 +0200, Christer Solskogen wrote:
On 27.04.2015 20:16, LRN wrote:
At a glance it looks like SDL_render_d3d11.c declares and defines
IID_IDXGIFactory2, and mingw's dxgi1_2.h declares IID_IDXGIFactory2 as well
(and defines it in some library, likely libuuid.a).
Apparently, SDL2 was written against a SDK (likely mingw.org) that has no
IID_IDXGIFactory2.
The fix is to remove
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 0x87,
0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
from SDL2 (or at least ifdef it out based on some macro from dxgi1_2.h).
At a glance, anyway.
Okay? Compiling SDL2 using v3.x (git) works just fine.
This is nothing surprising. The UIDs and interface definitions are
constantly added to the MinGW source (includes). For example, I have an
application using MSXML. There were no definitions for MSXML interfaces
so I had to add my own. It compiled fine with MinGW 3.x, but the MSXML
UIDs and interfaces has been added in MinGW 4.x. So I had to remove my
definitions in order to compile my project with MinGW 4.x. This is
called progress or evolution :-)
Pavel
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Example of COM server and client in C++
Hi Suresh, 1. COM client - this is quite simple, the only you need is to call CoInitialize or CoInitializeEx at the beginning of your program, and then call CoUninitialize at the end. The most important thing you need is a C(++) interface definition of the COM objects you want to use. Many of them are already in the MinGW header files, such as IMalloc or ADO objects (adoint.h). In this case, you only need to include the appropriate header file and call CoCreateInstance to create the object you want and finally cast it to the appropriate type. Bigger problem appears if you want to use objects which are not considered to be part of the OS, such as Adobe Acrobat Reader control. In this case you need to get the interface definition out of the Type Library. I am not aware of any OSS tool which could read type libraries and create C++ wrappers for the objects described there. Perhaps the easiest solution is to create new C++ project in Visual Studio, does not need to be ATL enabled, reference the TLB you want in the project. VS will generate two files with extensions .tli and .tlh. You can use the tlh file to create header file with the type definitions you want to use. 2. COM server - this is a bit more complicated, since you must implement several interfaces such as IClassFactory and also interfaces of your objects. If you only implement some existing interface with existing type library, you can directly link this TLB file into resource of your project. You will need the types described in TLB to implement IDispatch interface for your objects. You will do this through CreateStdDispatch API. You could avoid this by implementing of all the IDispatch methods yourself, but this is not recommended and will require lots of work. If you want to design your own interface, you will also face the problem of generating type library for your interfaces. I could not find anything else than using MIDL compiler delivered with Visual Studio for this task. - I don't have any COM client example at the moment I could share, although I wrote many in my life. But I can share COM server - it is an implementation of OLE DB provider for PostgreSQL database. You can compile the project both as 32 and 64 bit version. The source code is available here: http://sourceforge.net/projects/pmpostgresqlole/ (zipped in the Files section). Pavel On Sat, 2014-11-22 at 19:20 -0800, Suresh Govindachar wrote: Hello, Please point me to a simple but complete, 64 bit, C++, non-gui example of a COM server and client. I know nothing about COM but hope to have access to the book Essential COM by Don Box within a week or so. Via google, I found this thread from six years ago (Sep 2008) COM and ATL supporT in minGW http://mingw.5.n7.nabble.com/COM-and-ATL-supporT-in-minGW-td15733.html . Thanks, --Suresh -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] windows 32 bit memory address space
Actually the virtual memory limit available for single application is 2GB on 32bit Windows. It is possible to extent it to 3GB if special care is taken: http://msdn.microsoft.com/en-us/library/bb613473(VS.85).aspx Pavel On Mon, 2014-10-27 at 18:33 +0100, Adrien Nader wrote: No, it's impossible. 2 ** 32 = 4GB so the whole system is limited to 4GB in total and there's 1GB (or 2GB) which is not usable by applications. The only solution is to move to 64bit applications. Actually the limitation on memory allocations is the main reason for the creation of 64bit systems. Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] windows 32 bit memory address space
Hi Rashad, I believe this is given by the 32 bit implementation of Win32 API (surprisingly, the API on 64bit systems is also called Win32, but is implemented as 64bit). The system simply does not allow you to allocate more memory. It even looks like the 3GB option (4GT) is maybe not supported on Windows Vista/7/8 at all. Some interesting info can be found in this thread: http://www.sevenforums.com/general-discussion/114715-4-gigabyte-tunning-windows-7-ultimate-32-bit.html some other info related to pre-Vista systems is here: http://technet.microsoft.com/en-us/library/cc786709(v=WS.10).aspx Well, clearly - the answer is: if you want to allocate more than 2GB of memory, use 64bit application. Pavel The page says that supported OS are XP and 2003 Server. why --large-address-aware linker option is not helpful. Can anyone explain this? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Where is x86_64-w64-mingw32-gcc in Debian 7?
Hi Ralph, I have installed mingw-w64 (and all what has automatically been suggested) and the mentioned file, along with other mingw64 executables, is in /usr/bin. Pavel On Sun, 2014-09-14 at 17:23 +0200, Ralph Gossamer wrote: So I have installed mingw-w64 components targetting only w64 architecture on Debian 7. After installation, I couldn't locate x86_64-w64-mingw32-gcc. Or could it be called by another name? Thanks in advance for your help. Ralph -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What are the Debian packages of MinGW-w64?
Hi Ralph, I think you need a cross compiler, and the only OSS cross compiler I know is Mingw64 based. In Debian 7, you can install it directly from Synaptic Package Manager, just type mingw into the search edit, and you will see the list of all available packages. (Well, there are also cross compiler packages based on Mingw (mingw32), but I would not recommend you those.) If you are not sure, just install everything what has -w64- in the name. If you uses older version of Debian, then you need to install the cross compiler manually. There used to be a link on Mingw64 web site to download personal builds. I don't know what happened or whether these builds are still available. I have used Ruben's personal build cross compiler for Linux and it worked fine on Debian 6. Pavel On Sat, 2014-09-13 at 17:44 +0200, Ralph Gossamer wrote: I apologize for the rather awkward formatting of my earlier post. Could the moderator delete it please? Below is the same post but in text format. Hi I wish to build a 64-bit Windows binary on a Debian 64-bit OS. What are the Debian packages of MinGW-w64 that I need? Is it possible to cross-compile for Microsoft Windows without ever using MinGW-w64 on Debian? Regards. Ralph -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [RFC] sinf and cosf for ARM
Hi André,
I have some comments to the sinf implementation. First of all,
calculating the factorials in separate function is quite inefficient,
since you repeat multiplication of what has already been multiplied.
Slightly better would be to declare local variable and calculate the
factorial in the for loop:
float fact = 1;
float y = 1;
float res = y;
for(int i = 1; i 6; i++)
{
y *= x;
fact *= i;
res += y/fact;
}
this is rather an example for exp function, sine would require a
modification. And since you only calculate 6 values, it would be even
better to precalculate them and hardcode them in a table.
However, calculating goniometric functions from Taylor expansion is
quite inefficient and slow in general. In your algorithm, you use 6
values and power of 11, which itself introduces some error. The accuracy
of your implementation is 4 decimal digits at pi/2, where I believe the
deviation is the highest.
I suggest the following formula for calculating sine at (0, pi/2)
interval:
sin(x) = (0.6736*x - 0.09779183*x^2 - 0.12839086*x^3 +
0.01826627*x^4) / (1 - 0.09809942*x + 0.03936879*x^2)
This is accurate at 6 decimal digits in the whole interval, moreover it
matches the values at 0, pi/12, pi/6, pi/4, pi/3, 5*pi/12 and pi/2
exactly. The highest deviation magnitude is about 7.8e-7. I have derived
the coefficients using R.
cosine can be then calculated as sin(pi/2 - x) at the (0, pi/2)
interval.
So I hope it might help you.
Pavel
On Mon, 2014-06-16 at 23:04 +0200, André Hentschel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 16.06.2014 21:51, schrieb Kai Tietz:
2014-06-16 21:16 GMT+02:00 André Hentschel n...@dawncrow.de:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please review this initial implementation for the remaining math functions
I'm unsure about the folder name and the license for taylor_private.h, it
mostly contains
defines/typedefs/consts from FreeBSD...
Well, license is BSD. That's actuallly ok.
ok, true
What is about the accuracy of the sinf/cosf implementation?
It might be of interest to replace for x64 the current x87
implementation by soft-float, too.
As discussed on IRC i'll continue the plan of bringing the algorithms and
build system changes in and later we see what we can do for amd64
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQGcBAEBAgAGBQJTn1vLAAoJEGm5GZTakYssUFML/1WN9ff0SZLmMy5j8pgPIO3h
lHIwEPL8Bau+aHr/TNlah7ihnKToXgqGHlOkP6y757ZAdr1t5AZoOKmGILVFJ8xz
0xBSWp3LNCHtivBvz4x9AFLiTQCvXuHkpFgl6Kcw/sec3n6++ZN4OxOg8InoKgXs
JTz5ylLcwLiwTftWa+2Twx90q+TVw61AbOCb7KK7EiA2cDZCBNf7b+6tBIH5BcdR
xKjJFsuW+Wqdp4+IvHsI2zKm3Dx2IfJPn1q/Ht1RCJE/Ly5SMYzBKAtzrgJt63tj
RkOltTUADuM29uKoR2IvAFRNcRy7fbkMLtcqd0u8yJXXMfWeyrXVQqKm0PjNQVYc
4JFqhfrW3ra7tCfPZmC9d5dN8EGj45nLSJGw7kTpuDKcAj95Nr2NmlI5/2IYe03E
uvOGynAGh4dNVJH6JELYFJ1B7KJSKHaBylv7Dvajg18vrDlQcoi8lsWSMXFloPRB
xYTl//LvfKHGpxBmv8AHxR/G/ZCS8FNVHb6yxJXpZA==
=vomx
-END PGP SIGNATURE-
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Building Packages on MinGW-w64
On Fri, 2013-12-06 at 17:39 +0900, wynfi...@gmail.com wrote: I am going to try to build the Linphone VoIP SIP application, whose source I download using git, using MinGW-w64 with Cygwin on an XP SP3 environment. I assume that Cygwin's m4, aclocal, autoheader, automake, autoconf, autogen.sh, libtoolize modules are safe to use and don't inject any Cygwin dll dependent setings? I also assume that MinGW-w64's include files and libraries will automatcially be detected, but I doubt that this is true. I ran ./autogen.h which completed without error. Then I ran configure as: $ ./configure CC=/usr/bin/i686-w64-mingw32-gcc CXX=/usr/bin/i686-w64-mingw32-c++.exe Are there any other ./configure flags or variables that need to be set for a configure script? But I don't see any flags for the loader, but w64-mingw32-gcc probably knows which loader to use by default. If there are any inGW-w64 specific include files or libraries, are they stored in /usr/incude and /usr/lib respectively? If not where are they stored? I ran into a dependency problem: checking for LIBGTK... configure: error: Package requirements (gtk+-2.0 = 2.18.0 gthread-2.0) were not met: No package 'gtk+-2.0' found No package 'gthread-2.0' found I will need the gtk+-2.0 library. Cygwin has one, but it requires cygwin.dll which I don't mind using, but can it be done ? I need native speed for the video and audio processing, so don't want to go through Cygwin. Has anyone built gtk+-2.0 or newer with Mingw-w64 or is it not worth the effort? Year ago, I built the whole Gimp. In the beginning I started with cygwin, but it was extremely slow, so I gave it up. In the end, I cross-compiled both the 32bit and 64bit version from Linux using Ruben's built. This worked, however, the effort to achieve that was quite enormous and the result not really satisfactory and sometimes even impossible to reproduce. Building gtk+ requires lots of prerequisities, at minimum libz, libffi, libiconv, libxml2, gettext, glib, gtk-doc, atk, libpng, jpeg-8d, jasper, tiff, gdk-pixbuf, freetype, fontconfig, lcms, lcms2, jbig2dec, ghostscript, libspectre, poppler, pixman, cairo, harfbuzz, pango, libcroco, librsvg, libexif, libmng and iso-codes Some of them are perhaps only needed for Gimp, I don't remember exactly, but if so, then just few of them. Most of these libraries must be built for gtk+. Pavel Thanks -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Learning to use MinGW-w64
I am not sure what is the status now, but couple of years ago, GCC could
not compile programs with UNICODE version of WinMain. If it still
persist, you will need to declare the entry point as
int main(int argc, char **argv)
You can get the UNICODE command line arguments later by calling
GetCommandLine API.
Pavel
On Thu, 2013-12-05 at 22:41 +0900, wynfi...@gmail.com wrote:
From: JonY
Date: Thu, 05 Dec 2013 17:23:48 +0800
Subject: Re: [Mingw-w64-public] Using MinGW-w64
On 12/5/2013 12:58, wynfield wrote:
# I then tried to compile it, but it failed as soon below.
$ /bin/i686-w64-mingw32-gcc.exe hello.c
i686-w64-mingw32-gcc: error: spawn: No such file or directory
Don't do that, just use i686-w64-mingw32-gcc, or
/usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc.
I followed JonY's instruction and invoked the compiler simply as
i686-w64-mingw32-gcc.
I does get to the compiler now. Thank you.
Next I'm getting a linking error as follows from this example code on
MinGW-w64 site.
#define _UNICODE
#define UNICODE
#include tchar.h
int _tmain(int argc, _TCHAR **argv)
{
_tprintf(__T(Hello\n));
return 0;
}
Note: I am assuming the example given is oomplete and that tchar.h covers
what
normal stdio.h and stdlib.h do.
$ i686-w64-mingw32-gcc hello.c
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
In function `main':
/usr/src/debug/mingw64-i686-runtime-3.0.0-1/crt/crt0_c.c:18: undefined
reference to `WinMain@16'
collect2: error: ld returned 1 exit status
[ undefined reference to `WinMain@16' ]
Advice on solving this is appreciated.
Thank you.
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Cannot access inherited pointer
Hi team,
I have the following situation
class CBase
{
protected:
ULONG m_lRefCount;
IMalloc *m_pMalloc;
public:
CBase(IMalloc *pMalloc);
...
class CDerived : public CBase
{
public CDerived(IMalloc *pMalloc, int iSomeOtherParam);
...
CBase::CBase(IMalloc *pMalloc)
{
m_pMalloc = pMalloc;
}
CDerived::CDerived(IMalloc *pMalloc, int iSomeOtherParam) :
CBase(pMalloc)
{
...
now, whenever I try to access the m_pMalloc member from CDerived, it
crashes, however, accessing m_lRefCount is fine. Accessing m_pMalloc
from CBase is OK. Moreover, this only happens with 64bit version, 32bit
version works all fine.
I am using Ruben's personal build, win64 compiler for both 32bit and
64bit target. I have tested gcc 4.6.3-2 and 4.8.0 - both behave the same
way.
Any idea?
Thanks, Pavel
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cannot access inherited pointer
OK, so the problem was that the derived class was compiled with #pragma
pack(1), while the base class without it.
Thanks anyway, Pavel
On Mon, 2013-04-29 at 12:04 +0200, Pavel wrote:
Hi team,
I have the following situation
class CBase
{
protected:
ULONG m_lRefCount;
IMalloc *m_pMalloc;
public:
CBase(IMalloc *pMalloc);
...
class CDerived : public CBase
{
public CDerived(IMalloc *pMalloc, int iSomeOtherParam);
...
CBase::CBase(IMalloc *pMalloc)
{
m_pMalloc = pMalloc;
}
CDerived::CDerived(IMalloc *pMalloc, int iSomeOtherParam) :
CBase(pMalloc)
{
...
now, whenever I try to access the m_pMalloc member from CDerived, it
crashes, however, accessing m_lRefCount is fine. Accessing m_pMalloc
from CBase is OK. Moreover, this only happens with 64bit version, 32bit
version works all fine.
I am using Ruben's personal build, win64 compiler for both 32bit and
64bit target. I have tested gcc 4.6.3-2 and 4.8.0 - both behave the same
way.
Any idea?
Thanks, Pavel
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Practical Questions about Mingw-w64
Hi Larry, cross compiling is a nice fun, but be prepared that it will most likely not go smoothly. I have recently cross compiled some modules, so I can give you some hints. Autotools should be fine, but still it depends much on how the automake or configure is created. First of all, I have used Ruben's personal build which is most likely newer than the cross compiler from the deb package. So I don't know whether it already delivers some precompiled dll's like libz.dll etc. Look into your usr or etc folders if there is something like that. If there is such a folder where some essential dll files can be found, then you can use it as your target directory. The dll's should be in a folder named bin. At the same level, there should be also directories etc, include, lib, man and share. There should be a subfolder of lib folder named pkgconfig, this one is of special importance. If there is nothing like that on your system, create a target folder somewhere in your local profile - so that you don't have problems to write there. Create the mentioned subfolders bin, etc, etc. And create the pkgconfig folder under lib. Once you have that, try to run ./configure with the following arguments: --host=x86_64-w64-mingw32 // this is the target --build=x86_64-unknown-linux-gnu // this is only to prevent some annoying warning messages --prefix=/home/.../local64 // this is the path to your target folder, which contains bin etc. PKG_CONFIG_PATH=/home/.../local64/lib/pkgconfig the last argument is important and a well written configure script should know everything after that. However, sometimes the script is not as good and you need to add some more: CFLAGS=-I/home/.../local64/include CPPFLAGS=-I/home/.../local64/include LDFLAGS=-L/home/.../local64/lib When you run configure with these arguments, you will most likely get a message that some dependency package is missing. Then go to web and download the source of the missing package and try to configure the package. It is a recursive process, if you are lucky, it will end up one day. If you have bad luck, ghostscript will be requested. Sometimes, you can also download already precompiled packages. The developer version of such precompiled package should be packed exactly with the directory structure as your target folder, so just unpack them there and run configure again on the previous package. Sometimes it is also good to run ./configure --help to see what options the script accepts. You can for example turn off features which has no meaning for MS Windows. Once configure finishes without errors, run make, and if make finishes without errors, run make install. This will copy all necessary files into your target folder. Your exe or dll should appear in your target/bin folder then. It most likely means that compilation was successful. Finally, it is quite brave decision to cross compile something with little knowledge of programming in general, although not impossible. But a 3D game is most likely going to be even tougher than anything else. Are you sure that this game has been ever ported to Windows? If not, then because of OpenGL, your chance to succeed is really not big. But I cross fingers and wish you good luck. Pavel On Thu, 2013-02-07 at 21:30 -0500, Larry Pottle wrote: Hi, I am new to mingw and have only rudimentary knowledge of cross compilling and even programing in general. I have source code of a long abandoned 64bit 3D open source Linux game that I would like to cross compile for Windows7 64bit. My devel box has Ubuntu 11.04 Linux installed as well as mingw-w64 from the Ubuntu repositories and all the necessary build dependencies for compiling the game on Linux. After a long and arduous journey through dependency hell, I am able to successfully configure, build and install a Debian package of the game from source and run it on my system. Since Mingw, for all practical purposes; is not self intuitive to the novice or non-programmer, I am wondering what to expect when I attempt to cross compile a program using it. Since the source is based on Autotools; I understand that ./configure used in conjunction with the triplet --host=x86_64-w64-mingw32 from the command line will cross compile to a windows 64bit host. Assuming that the cross compilation was a success and that I desire a monolithic executable, How may I find the name of the cross compiled file and its suffix. Where should I expect to find the cross compiled file and how may I package this file so that I may actually run it on Windows7? Also how may I know that the cross compilation was successful or not? Thank you for your patience! Larry -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Mingw-w64
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Hi Frank,
I went again through your posts and if I understand well, you are trying
to adapt some code written for MS VC++ to MinGW, is that correct?
In this case, you would probably need to rewrite a small portion of the
code, unless you will get for libxml2 in the end.
I know nothing about QuickFIX but from the code bellow I deduce that the
only you need is the initialized m_pDoc pointer. You can use the code
bellow, however you should avoid using stdafx.h, it is a header
generated by MS VS for each VC project. The atl* headers are headers for
MS Active Template Library, this is a support stuff for COM. I cannot
see these headers in my MinGW installation and I suggest you to also
drop these includes.
So what you basically need is to check whether CLSID_DOMDocument (or
something like this) is declared in some of the msxml header files
delivered with MinGW. I suppose it is, so you will include this header
and use the CLSID constant declared there to create the m_pDoc instance
through the CoCreateInstance call. I suppose the MSXML_DOMDocument class
is only a cosmetic wrapper around m_pDoc, more precisely about
IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h.
So, I am not sure whether my explanation is clear enough. My conclusion
is that if you decide to go for msxml, you would need to manually update
the code a bit, however, it should not be difficult with the headers
provided by MinGW.
Pavel
On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote:
Hi Pavel (and List)!
(Since my follow-up to Pavel's comments are about msxml, I am starting
a new thread here to separate the discussion from that about libxml2.)
On Wed, Jan 9, 2013 at 8:48 AM, pavel ... wrote:
Frank, see my comments bellow.
On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote:
I am hoping that all I need to do is translate the above code
fragment, e.g.:
#import msxml3.dll raw_interfaces_only named_guids
into the mingw-w64 world (without learning DCOM).
Any suggestions or even educated guesses would be helpful.
Should I just #include all four msxml headers? Include only
one master header file? Something else? Might I have to
manually add some msxml library to the link command?
I'm speculating that the microsoft #import command is reading
through the .dll to find and extract the function-prototype information
that in the mingw-w64 world is in the #include header files. But
that's just a guess, so any help would be appreciated.
Again, I'm not asking how to use msxml. I just need to know how
to make msxml available to code that presumably already uses it
correctly by finding the mingw-w64 equivalent of the #import line.
MS #import command does not read in the .dll. It reads in a binary file
called type library, usually with extension .tlb (however, the type
library can be also linked as resource to any executable file, e.g. exe,
dll and ocx). There is public API for reading type libraries, so
virtually a support for #import could be implemented into MinGW, but I
am afraid that it would be quite a big job.
You don't need to link any COM dll, it is useless. On the other hand,
you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32
(defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then
you must call CoInitialize in the beginning of your code (definitively
prior trying to load a COM object) and call CoUninitialize in the end of
your application. This all is perhaps handled by the MS _WIN32_DCOM
definition, I am not sure.
You then create a new instance of a COM object by calling the
CoCreateInstance function with appropriate arguments.
Thank you for the overview. I do have a cartoon picture of how COM
works, but nothing really more than that.
I do see in the msxml.h file provided by mingw-w64 declarations of
various xml interfaces. I'm guessing that's effectively the information
that visual studio gets with its #import command.
In the QuickFIX code (in MSXML_DOMDocument.cpp, for those who
care) I see the following code:
MSXML_DOMDocument::MSXML_DOMDocument() throw( ConfigError )
: m_pDoc(NULL)
{
if(FAILED(CoInitializeEx( 0, COINIT_MULTITHREADED )))
if(FAILED(CoInitializeEx( 0, COINIT_APARTMENTTHREADED )))
throw ConfigError(Could not initialize COM);
HRESULT hr = CoCreateInstance(
MSXML2::CLSID_DOMDocument, NULL, CLSCTX_ALL, __uuidof(
MSXML2::IXMLDOMDocument2 ),
( void ** ) m_pDoc );
if ( hr != S_OK )
throw( ConfigError( MSXML DOM Document could not be created ) );
}
Maybe I'm being too optimistic, but I see the QuickFIX code calling
CoInitialize and CoCreate, and so on. So I'm hoping that all of the
COM stuff is already taken care of in the QuickFIX code, *if* *only*
I can figure out how to translate the
#define _WIN32_DCOM
#import msxml3.dll raw_interfaces_only named_guids
using namespace MSXML2
Re: [Mingw-w64-public] libxml2 with mingw-w64?
Frank, see my comments bellow. On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote: I am hoping that all I need to do is translate the above code fragment, e.g.: #import msxml3.dll raw_interfaces_only named_guids into the mingw-w64 world (without learning DCOM). Any suggestions or even educated guesses would be helpful. Should I just #include all four msxml headers? Include only one master header file? Something else? Might I have to manually add some msxml library to the link command? I'm speculating that the microsoft #import command is reading through the .dll to find and extract the function-prototype information that in the mingw-w64 world is in the #include header files. But that's just a guess, so any help would be appreciated. Again, I'm not asking how to use msxml. I just need to know how to make msxml available to code that presumably already uses it correctly by finding the mingw-w64 equivalent of the #import line. MS #import command does not read in the .dll. It reads in a binary file called type library, usually with extension .tlb (however, the type library can be also linked as resource to any executable file, e.g. exe, dll and ocx). There is public API for reading type libraries, so virtually a support for #import could be implemented into MinGW, but I am afraid that it would be quite a big job. You don't need to link any COM dll, it is useless. On the other hand, you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32 (defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then you must call CoInitialize in the beginning of your code (definitively prior trying to load a COM object) and call CoUninitialize in the end of your application. This all is perhaps handled by the MS _WIN32_DCOM definition, I am not sure. You then create a new instance of a COM object by calling the CoCreateInstance function with appropriate arguments. Pavel Ruben Thanks again. K. Frank -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 with mingw-w64?
On Tue, 2013-01-08 at 10:24 -0500, K. Frank wrote: Great. If I end up needing libxml2, I'll plan to build it myself. Do you happen to know if I should expect the build to be totally straightforward (with mingw-w64)? Any gotcha's or dependencies I should be expecting? I have cross-compiled libxml2 from Debian recently without any issues. I've used Ruben's personal build and compiled zlib, libffi, libiconv and libxml2 in this order. I am not sure whether libffi and libiconv is required by libxml, I needed them for some other stuff. zlib cannot be configured for cross-compilation (or at least I heven't managed that), Makefile.gcc should be used instead for direct compilation. I can attach the whole script for compilation, if it helps. libffi, libiconv and libxml2 can be easily configured with the following: ./configure --host=i686-w64-mingw32 \ --build=x86_64-unknown-linux-gnu \ --prefix=/home/pavel/Programs/local32 It works the same for 64bit Windows with -host=x64_86-w64-mingw32 HTH, Pavel -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Export symbols with aliases with 64bit
Hi, recently I am trying to cross compile some base GNU libraries for both 32bit and 64bit Windows host. The build system is Debian 6.0.6. I am using Ruben's personal build (xxx-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar). When building glib with the x86_64 target, I get the following error at some point of linking: CC gspawn-win32.lo CC gwin32.lo cd .. /bin/bash ./config.status glib/glib.rc config.status: creating glib/glib.rc x86_64-w64-mingw32-windres glib.rc glib-win32-res.o CCLD libglib-2.0.la Cannot export g_dir_open: symbol not defined Cannot export g_dir_read_name: symbol not defined ... Cannot export g_unsetenv: symbol not defined Cannot export g_win32_get_package_installation_directory: symbol not defined Cannot export g_win32_get_package_installation_subdirectory: symbol not defined collect2: error: ld returned 1 exit status make[4]: *** [libglib-2.0.la] Error 1 make[4]: Leaving directory `/home/pavel/Programs/GNUsystem/glib/glib' make[3]: *** [all-recursive] Error 1 The list of not defined symbols is longer but it is not important at the moment. The interesting point is that all the not defined symbols have an alias defined via #define directive. So for example gdir.h contains: #define g_dir_open g_dir_open_utf8 GDir* g_dir_open(const gchar *path, guint flags, GError **error); and the glib.def declares both g_dir_open and g_dir_open_utf8 for export. g_dir_open is marked as PRIVATE, but it is probably also not important. When I comment out the #define line in gdir.h and comment out g_dir_open_utf8 in the def file, then g_dir_open is not reported as undefined symbol anymore. And finally, when configure runs with the same parameters for the i686 host, then everything compiles without problems. So, can anybody help me with this so that I don't need to make changes to the source code? Is there any compiler switch or something like that? Or is there any other mingw64 cross compiler build I could try? Thanks, Pavel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Export symbols with aliases with 64bit
Hi Václav, Алексей, none of your suggestions seems to be useful. Perhaps it is worthy to mention that I am trying to compile the most recent stable versions, in case of glib it is 2.34.3, which is much newer than for example precompiled binaries available at official gtk web site http://www.gtk.org/download/win64.php (2.26.1). I am afraid that if I for example take the long time to install MXE, I would end up with exactly the same problem. Btw., I have already successfully built many other packages, including gettext (although it was a bit tricky), image libraries (libpng, jasper, tiff) and with 32bit target also gdk-pixbuf and freetype. But thank you anyway, Pavel On Fri, 2012-12-21 at 09:31 +0100, Václav Šmilauer wrote: recently I am trying to cross compile some base GNU libraries for both 32bit and 64bit Windows host. The build system is Debian 6.0.6. I am using Ruben's personal build (xxx-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar). When building glib with the x86_64 target, I get the following error at some point of linking: Hi, I can't help you with this particular problem, but perhaps those pointers will be useful for you. There is the http://mxe.cc project, which automates building windows libs on linux hosts, and has pretty responsive mailing list. They basically stuffed downloads, configure options and patches into Makefiles, so you just type make glib, it compiles dependencies and glib using your cross-compiler. A number of mingw-cross-compiled libs is packaged for OpenSUSE, e.g. https://build.opensuse.org/package/show?package=glib2project=windows%3Amingw (you could use alien to convert to .deb packages), if you don't want to compile. There were two scripts compiling several libs (glib is one of them) on the list recently, though they were compiling on windows host - maybe they would be worth investigating, in attachments of http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6511 and http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6514 . HTH, Vaclav -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Export symbols with aliases with 64bit
OK, I've made a simple test and i686 compiler also refuses to export #defined symbols. So the problem must occur somewhere during configuration of glib. I'll keep investigating. Thanks to all for your support. Pavel On Fri, 2012-12-21 at 10:54 +0100, Václav Šmilauer wrote: I am afraid that if I for example take the long time to install MXE, I would end up with exactly the same problem. MXE installation is next to trivial. The version of glib they have now is 2.28.2, though (their patch is https://github.com/mxe/mxe/blob/master/src/glib-1-fixes.patch). Good luck, anyway. vaclav -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Export symbols with aliases with 64bit
On Fri, 2012-12-21 at 20:23 +0100, Erik van Pienbroek wrote: pavel schreef op vr 21-12-2012 om 08:46 [+0100]: When building glib with the x86_64 target, I get the following error at some point of linking: CC gspawn-win32.lo CC gwin32.lo cd .. /bin/bash ./config.status glib/glib.rc config.status: creating glib/glib.rc x86_64-w64-mingw32-windres glib.rc glib-win32-res.o CCLD libglib-2.0.la Cannot export g_dir_open: symbol not defined Cannot export g_dir_read_name: symbol not defined Did you already try to remove the glib.def file? When you do this, the file should get re-generated automatically. Its contents are supposed to be different between the win32 and win64 targets (because of historical reasons, upstream needs to retain binary API compatibility). That was the trick!!! Thanks very much. Pavel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] libgcc_s_sjsj-1.dll
Hi, why the latest release links the programs with the libgcc_s_sjsj-1.dll? Is it possible to avoid that? Thanks, Pavel -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libgcc_s_sjsj-1.dll
I have figured this out already. Thanks, Pavel On Tue, 2010-05-04 at 13:26 +0200, pavel wrote: Hi, why the latest release links the programs with the libgcc_s_sjsj-1.dll? Is it possible to avoid that? Thanks, Pavel -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] msxml3 problem
Hi team, I am making big progress with compiling 64bit Windows applications. So first of all thank you for the great job. I've tried two recent binaries. I could get running mingw-w64-bin-x86_64-mingw_20080320 neither on Intel processor (which I suppose is correct), nor on AMD processor. Nevertheless, I am absolutely happy with the mingw-w64-bin_i686-mingw_20080116 build, which works pretty well. I was able to compile the attached MenuTestMinGW64 code, which you can use as a sample, if you wish. It demonstrates how to create MDI application and how to use manifest file to enable Windows XP visual styles. I've also encountered few minor issues: 1. The x86_64-pc-mingw32-gcc-4.3.0.exe must be renamed (or better copied into a new file) to x86_64-pc-mingw32-gcc.exe, in order to run windres succesfully. 2. To compile stuff with VARIANTs, -D_FORCENAMELESSUNION must be added to the compiler flags, otherwise one cannot reference vt, lVal and other fields directly. The 32 bit version of MinGW, as well as the MS compiler seem to define this symbol by default. 3. The msxml.h defines several UIDs (e.g. IID_IXMLDOMNode, CLSID_DOMDocument) as external, however they are exposed neither by msxml3.dll (which is the msxml version dll present on 64bit system by default) nor by libmsxml3.a, distributed by MinGW64. To workaround that problem, I have created a small project, which generates new libmsxml3.a, defining the UIDs correctly. The library is missing definition of DLLMain and the four COM dll functions (DLLRegisterServer etc.), which I don't think is important. Nobody is supposed to call these methods directly. Thanks, Pavel libmsxml3.tar.gz Description: GNU Zip compressed data MenuTestMinGW64.tar.gz Description: GNU Zip compressed data - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
