On Wed, 30 Jan 2008, Owen Taylor wrote:
I'm not sure what you you are asking here. What I was saying is that
changing vtable members is more likely to break things than changing
function prototypes.
Ok, but then, every prototype change can be a vtable change, given a
custom vtable that has a
On Tue, 2008-01-29 at 15:12 +0100, Tim Janik wrote:
2008-01-29 14:58:31 Tim Janik [EMAIL PROTECTED]
* glib/gmem.[hc]: changed size argument type from gulong to gsize as
discussed on gtk-devel-list:
On Mon, 5 Mar 2007, Owen Taylor wrote:
On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:
goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to
'gulong', possible loss of data
change-allocated.array.data = g_renew (gchar *,
change-allocated.array.data,
does struct timeval use 32 or 64 bit fields on win64?
Is uses long, so 32 bits.
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
under Windows Server 2003 64-bit.
I hit the following issues:
gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
This is caused by an if/else fallthrough in gbacktrace.h. Adding the
following lines
I'll wait to hear about the proper place to put these... but here are
the mess of patches I currently apply against 2.12.9 to get something
working under Windows 64-bit.
I tried to split all the patches into clearly-defined sections, but
there is the chance that some overlap occurs. I simply
Jake Goulding writes:
Some comments inline below:
+#if defined(_MSC_VER) defined (_M_X64)
It would be better to separate things that are compiler-dependent and
things that are platform dependent. If and when gcc becomes available
for 64-bit Windows, _MSC_VER won't be defined when using it.
So bugzilla is again available to me. Any tips on where to file this bug?
Jake Goulding wrote:
As soon as we get a bug for this (I don't seem
to be able to access bugzilla.gnome.org right now...) I'll post the
patch and let you take a look at it.
--
JAKE GOULDING
Software Engineer
[EMAIL
I just wanted to post on this thread again to see where things stand.
Jake, are you working on this still, and planning on sending in any patches?
If not, I may begin to take a shot at getting current branch code to compile
on Win64. I have the mono runtime semi-ported to Win64, so glib is what
Jonathan Chambers writes:
Should I post diffs to this list?
It's better to open a bug in bugzilla and attach diffs to it.
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
My apologies for being lax on this. glib is part of our whole underlying
platform of dependencies, so I ended up working on some other libraries
for a bit.
The big thing is the parameters to the allocation functions. My gut is
to change them to be gsize as that is pedantically correct, and
Just wanted to note that I am interested in this topic as well, as I am
trying to port mono (which depends on glib) to Win64. I just contacted Tor
about this a week ago offline. I saw this thread searching the web, and just
joined the list.
Jake, if you want/need any help with anything let me
Also, I ran into a similar problem with some date functions (gmtime
expects a 64-bit number as time_t is 64-bit)...
It's almost like there should be a full-width type, one that is 32 bits
on a 32-bit platform, and 64 bits on 64-bit.
Thoughts?
Jake Goulding wrote:
That does leave me with the
Very unfortunately no. You can use the capital case windows defines,
INT_PTR, etc, or ship a version of stdint.h to use in VS (
http://www.azillionmonkeys.com/qed/pstdint.h).
- Jonathan
On 3/5/07, Tor Lillqvist [EMAIL PROTECTED] wrote:
It's almost like there should be a full-width type, one
Sure. Please excuse the following formatting...
gbookmarkfile.c(1838) : warning C4267: 'function' : conversion from
'size_t' to 'gulong', possible loss of data
all_data_dirs = g_new0 (gchar *, g_strv_length ((gchar
**)system_data_dirs) + 2);
gfileutils.c(565) : warning C4267: 'function' :
Tor Lillqvist wrote:
I'm not sure. This can be considered as an API change even if the type
is the same size and signedness as the old one on the existing
plaforms. intprt_t and uintprt_t also don't exist on all
platforms. Maybe preprocessor macros is the only way out, i.e. having
a macro
Of course, that would have made more sense... :-)
http://www.myxopho.be/glib-win64-compile.log
And grepped for warning:
http://www.myxopho.be/glib-win64-warnings.log
Tor Lillqvist wrote:
You wouldn't have the file names and line numbers for those
warnings...? (Maybe you could put the whole
I think a large amount of errors stem from the fact that it is assumed
that sizeof(long) == sizeof(void *)
Both from a 64-bit AMD machine...
Linux:
char: 1
short: 2
int: 4
long: 8
long long: 8
void *: 8
size_t: 8
Win64:
char: 1
short: 2
int: 4
long: 4
long long: 8
void *: 8
HANDLE: 8
size_t: 8
I think a large amount of errors stem from the fact that it is assumed
that sizeof(long) == sizeof(void *)
=, I think, but yes. You need to make sure configure defines gsize
as unsigned
long long, and gssize as long long.
You might also want to check...
* the ptrdiff_t type. If it has a
Morten Welinder wrote:
=, I think, but yes. You need to make sure configure defines gsize
as unsigned
long long, and gssize as long long.
Well, gsize is actually fine. There is a native size_t type that is 8
bytes. long is the issue here, as it is only 4 bytes. long long is 8
bytes, as
On Mar 3, 2007, at 5:02 PM, Jake Goulding wrote:
Morten Welinder wrote:
* if NULL is an integer type. No, really. If it is defined as just
0 or 0L, you are in for a world of hurt.
It should be simplest to override the definition in that case.
I'm not even sure where or how I could check
Duh... of course. I always forget about -E (which is conveniently the
same for MSVCs cl.exe)
So, yeah, it is 0 cast to a void *. I figured it would be good, as most
of the tests ran fine, but always good to double check. :-D
muppet wrote:
Use the preprocessor to expand it for you:
$ gcc
Also, there are a lot of assumptions that the return value of strlen is
an int... Obviously, the chance of a string exceeding the 32-bit
boundary is fairly rare, and you certainly wouldn't want to call strlen
on a string that big, but the manpage says what it says, and strlen
returns a size_t.
I think I have made some progress... at least the following libraries
have been built:
./build/win32/dirent/dirent.lib
./glib/glib-2.0.lib
./glib/glib-2.12s.lib
./glib/gnulib/gnulib.lib
./gmodule/gmodule-2.0.lib
./gobject/gobject-2.0.lib
./gobject/gobject-2.12s.lib
./gthread/gthread-2.0.lib
Is
I think I have made some progress... at least the following libraries=20
have been built:
build/win32/dirent/dirent.lib
glib/gnulib/gnulib.lib
(These are just auxiliary libraries that are linked in the glib DLL.)
glib/glib-2.0.lib
gmodule/gmodule-2.0.lib
gobject/gobject-2.0.lib
I think I have made some progress... at least the following libraries
have been built:
build/win32/dirent/dirent.lib
glib/gnulib/gnulib.lib
(These are just auxiliary libraries that are linked in the glib DLL.)
Right, but are nonetheless needed for the rest of glib. :-D
On 02.03.2007 22:49, Jake Goulding wrote:
On 02.03.2007 22:29, Tor Lillqvist wrote:
The tests don't necessarily test everything, but this does indeed
sound promising.
Well, I didn't say that I *did* run them and get good outputs, I just
wanted to make sure that was what the expected
Hans Breuer writes:
I think a series of patches to fix these warnings would be gladly accepted.
Unless we are still talking about GLib 2.8.6 here, in which case
patches are useful only if the same problem still exists in trunk or
2.12.
--tml
___
Ah, I guess I forgot to mention my attack plan here...
I am working off of the latest stable version (2.12.9) as we will
want the most stable for our product. I figure that I can apply most
(if not all) of the changes to the trunk. After I get the stable
version, I'll probably give a swing
Here is the full list of warnings from the glib directory. Please let me
know if you agree with my sorting into two groups.
Needs to be fixed:
warning C4028: formal parameter 2 different from declaration
warning C4113: 'GCond *(__cdecl *)()' differs in parameter lists from
'GCond *(__cdecl
Jake Goulding wrote:
Unfortunately, our particular use of glib requires static libraries for
everything (we static link on all the platforms our software is shipped
on, to minimize runtime issues). I asked this on the list at some point
in the past, and I think these are static libraries
You wouldn't have the file names and line numbers for those
warnings...? (Maybe you could put the whole compilation output
listing up on the web somewhere.)
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
under Windows Server 2003 64-bit.
I hit the following issues:
gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
This is caused by an if/else fallthrough in gbacktrace.h. Adding the
following lines skipped
On 01.03.2007 21:40, Jake Goulding wrote:
Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
under Windows Server 2003 64-bit.
I hit the following issues:
gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
This is caused by an if/else fallthrough in
Thanks for the prompt response Hans.
Has GLib been successfully compiled in 64-bit mode under Windows?
Didn't hear about that.
Do you have a rough idea of the amount of work that it would take to get
this working? I don't mind doing the work, but I'm not entirely familiar
with
Jake Goulding writes:
Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
under Windows Server 2003 64-bit.
I certainly am interested in hearing about GLib on 64-bit Windows, but
I don't bother to keep the sources to such old versions on my disk any
longer. I don't see
36 matches
Mail list logo
