Hi,
You can also do it with manifests. The example attached manifests allow
an executable in directory c:\bin to load libstdc++-6.dll and
libgcc_s_sjlj-1.dll from a subdirectory. Nothing is needed other than
the manifests. The subdirectory is not on the PATH.
The directory and file structure
Hi,
It is because you are cross compiling but not passing any target triplet.
There's an 'approach' I have always used which is just create copies of
the 27 executables prefixed x86_64-w64-mingw32 in bin.
(so you have both x86_64-w64-mingw32-g++.exe and g++.exe).
Then ensure the only mingw rela
Hi Rob, me again :-)
On 20/03/2012 02:04, Sisyphus wrote:
> Better if someone knows of a way to have Strawberry Perl stick to loading
> the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll
> files to load the 4.7.0 libgcc_s_sjlj-1.dll .
I think this is possible with manifests.
On 17/11/2011 07:52, Ozkan Sezer wrote:
> Please verify that:
> - The trunk and v2.x versions are identical to each other
> - All are fine and functional
I can confirm that trunk and stable are identical and that when built
functionality in my usage is identical to gdiplus as installed from
min
On 17/11/2011 07:52, Ozkan Sezer wrote:
> - lib32/gdiplus.def: GdipCreateHalftonePalette was missing the "@0" stdcall
>suffix, added it. gendef can output faulty information for functions
> returning
>void (and in some other cases as well), so checking manually is always a
>good idea.
On 16/11/2011 08:24, Ozkan Sezer wrote:
Are you sure that you ran autoreconf?
I did say I was new at autoconf :)
autoreconf -f
did the trick. (-f needed, I assume, as configure.ac file is untouched
in mingw-w64-crt folder. )
One nit about the makefile patch: Please append $(AM_CPPFLAGS)
On 13/11/2011 19:41, Kai Tietz wrote:
Sure, patch would be welcome.
I need some help with autoconf I think. (my first attempt)
patch at http://www.wxperl.co.uk/gdiplus-files.patch adds necessary
files and is straightforward.
Attached file gdiplus-autoconf.patch contains my changes to conf
Hi,
RegUnLoadKeyA
RegUnLoadKeyW
are still in lib64/kernel32.def.
Reg functions live in advapi32.def. These two were missed when other reg
functions were commented out.
Rgds
Mark
--
RSA(R) Conference 2012
Save $700 b
Hi,
You may wish to add the gdiplus headers from win32api / mingw.org
(win32api version 3.17)
I have success using them with v2 crt both 32 and 64 bit to build and
use wxWidgets.
The only changes I needed were to add a single definition to a header
and, of course, build the c object into libgd
Thanks for the prompt help. I can confirm that today's snapshot of
binutils, labelled release 2.22.51 now compiles for me fine with
configure \
--prefix=$(TOP_PREFIX) \
--build=$(BUILDHOST) \
--target=$(BUILDHOST) \
--disable-multilib \
--disable-
On 08/11/2011 09:26, Ozkan Sezer wrote:
> That patch has not been reverted from v2.x, it is there.
> If you reverted it on your own copies, we'd like to know
> what problems it caused for you.
My confusion. I am working with the 'stable' branch - i.e.
http://mingw-w64.svn.sourceforge.net/viewvc/
Hi,
I have been trying to compile binutils natively using
mingw-w64-stable-2.x-r4587. Original release 2.0 worked OK. After much
hair pulling, I realised the answer was the binutils code doesn't yet
cope with availability of _FILE_OFFEST_BITS on mingw so I just pass
--disable-largefile to conf
Hi,
I've built GD using MSYS for dependencies that need configure.
root for my libs and includes is c:/mylib
(so I have c:/mylib/include & c:/mylib/lib)
build static versions of zlib, libjpeg, libpng, libfreetype.
odd things required:
for zlib
add -DWIN64 to makefile FLAGS
move zlib.h & zco
Hi,
I recently struggled and failed to build same. Reduced to using an ms
tool chain to build a libpq.dll
However, I had not found Andrew's patch which is on the pgsql.hackers
list on 28th Jan
I looks straightforward enough that you should be able to adapt if not
apply directly to the 9.0.3 s
14 matches
Mail list logo
