ild1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/wine-mono-4.5.6-1
>CCLD pedump.exe
> ../../libgc/.libs/libmonogc.a(win32_threads.o): In function
> `GC_delete_thread':
> /builddir/build/BUILD/wine-mono-4.5.6/build-cross-x86_64/libgc/../../mono/libgc/win32_threads.c:196:
>
On 01/21/2015 09:01 AM, Jacek Caban wrote:
> I just uploaded new Wine Gecko beta packages. This time it's based on
> Firefox 36 beta branch, so it should be pretty stable. To test it please
> use the attached patch. That's all you need, Wine will download Gecko
> automatically. Packages are also av
On 01/03/2015 01:43 PM, Erik van Pienbroek wrote:
> mingw-libmicrohttpd-0.9.34-3
> ** Package failed to build while it succeeded during the previous mass
> rebuild **
> Package owner: mooninite
> Time to build: 9 seconds
> Build
> logs:http://build1.vanpienbroek.nl/fedora-
On 01/02/2015 03:46 AM, Jacek Caban wrote:
> In general the problem is hard to solve. About any new wine-gecko
> release needs fixes on mingw-w64 side. That's why the only thing that I
> can guarantee when I do the release is that it works with recent master
> version of mingw-w64. We're going to h
On 12/15/2014 10:25 AM, Adrien Nader wrote:
> Just to be sure, you mean 4.x and therefore all the other "experimental"
> features?
Yes, I suspect you would call it 4.x as the 3.x branch would require
substantial
changes.
--
Hello,
The current stable release branch is not able to build the wine-gecko project
while the latest git checkout is. There are 5 new files and a dozen headers
with
missing or incorrect definitions that wine-gecko expects.
When will the next stable branch release be made against what is in gi
On 12/04/2014 11:22 AM, Michael Cronenworth wrote:
> Now I'm encountering a bug with mingw-headers:
> http://fpaste.org/156673/14177133/
After discussing with Kai, he is working on fixing this issue.
Only one issue remains.
/builddir/build/BUILD/mingw-wine-gecko-2.34/wine-mozilla-2
On 12/04/2014 01:46 AM, Adrien Nader wrote:
> I have the following in gthr-default.h:
>#define __GTHREADS 1
>#define __GTHREADS_CXX0X 1
>
>#include
>
> Can you check you have it too?
Yes, it does.
> Also, typically, these issues are best debugged with the output of
> 'gcc -E'/'g++ -E
Hello,
I am attempting to build wine-gecko 2.34 for Fedora, but I'm having an issue
with winpthreads that doesn't make sense on first glance.
gcc - 4.9.2
crt, headers, winpthreads - latest git checkout (2014-12-03)
Build log: https://kojipkgs.fedoraproject.org//work/tasks/1017/8291017/build.log
Michael Cronenworth wrote:
> I noticed that localtime_r()/gmtime_r()/ctime_r() are present in winpthreads
> when
> they were not in the old-pthreads implementation. These routines are already
> available through time.h. Why are they also present in pthread.h?
I realize this
Hello,
I noticed that localtime_r()/gmtime_r()/ctime_r() are present in winthreads
when
they were not in the old-pthreads implementation. These routines are already
available through time.h. Why are they also present in pthread.h?
Thanks,
Michael
-
On 08/12/2013 11:23 AM, Jacek Caban wrote:
> This doesn't answer your general question, but for wine-gecko, I fixed
> it upstream, see:
> https://bugzilla.mozilla.org/show_bug.cgi?id=876416
> I may provide a backport in release branches, let me know which ones do
> you need.
Thanks. Fedora uses 2.
On 08/06/2013 05:12 PM, Michael Cronenworth wrote:
> I'm attempting to build a project that uses both PostgreSQL (libpq.dll) and
> CuRL
> (libcurl.dll), but I have run into a issue when both are linked into the same
> executable. I have a simple test case that I am attaching
On 08/07/2013 01:35 PM, LRN wrote:
> What does "might" mean there? Like, you may get a dependency, or you may
> not? It doesn't sound like you ALWAYS get a dependency.
> Previously you WOULD get the dependency if you had code that required
> it, and WOULD NOT get it otherwise.
> Now you get it rega
On 08/07/2013 01:16 PM, LRN wrote:
> So...what changed? Why is libgcc now mandatory for any library
> (including empty dlls)? Is that a problem in my toolchain only, or is
> everyone experiencing it?
Yes, and the change is intended.
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120
---
I'm attempting to build a project that uses both PostgreSQL (libpq.dll) and CuRL
(libcurl.dll), but I have run into a issue when both are linked into the same
executable. I have a simple test case that I am attaching that demonstrates the
problem.
The resulting binary will not run. Windows or Wine
16 matches
Mail list logo
