Brandon Casey wrote:
> It's hard for me to think of unicode as
> being low-level when it adds so much overhead to string handling.
Isn't (a part of) the unicode handling needed for correctly processing
paths under Windows? As I remember it, Windows-native calls take either
ASCII or a slightly m
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 a
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 GOULDIN
nings. Should I post diffs to this list?
>
> Thanks,
> Jonathan
>
> On 3/5/07, *Jake Goulding* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Tor Lillqvist wrote:
> > I'm not sure. This can be considered as an API change even if
>
> gbooleanexpected)
> {
>gboolean match;
> -
> +
> + if (string[0] == '%' && string[1] == '\0')
> + string = "%%";
> +
>verbose ("matching \"%s\" against \"%s\" \t", string, pattern);
>
>mat
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
gnome.org/mailman/listinfo/gtk-devel-list
>
>
--
JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]
Vivísimo [Search Done Right]
1710 Murray Avenue
Pittsburgh, PA 15217 USA
tel: +1.412.422.2499 x105
fax: +1.412.422.2495
vivisimo.com clusty.com
___
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
--
JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]
Vivísimo [Sear
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' : conve
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
; thorough analysis and came to the conclusion that this causes less
> problems than going to 64-bit longs.)
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org <mailto:gtk-devel-list@gnome.org>
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
ize_t.
It would be A Bad Thing to change the function declarations that cause
this I assume, as it would break ABI compatibility. However, for
function-local variables that make this mistake, should it be fine to
fix this? Or is it more appropriate to cast strlen to an int?
Jake Goulding wrote:
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:
>
> $ gc
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
byte
orm, but I know the standard doesn't guarantee it. GCC on linux has
a long as 64-bits. As far as I can tell, there is no 64-bit GCC for
Windows (yet?) to compare against.
How *wrong* would it be to define g[u]long as forcibly 64-bit on a
64-bit platform?
Jake Goulding wrote:
> I think
This would certainly explain all sorts of the warnings (not all, of course).
Jake Goulding wrote:
> 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
>
t the whole compilation output
> listing up on the web somewhere.)
>
> --tml
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
--
JAKE GOULD
ion was added with win64 in mind but not
> tested at that time. It probably needs to be an int64 there.
>
>
>> There are whole piles of warnings about signed/unsigned comparisons and
>> type size issues:
>>
>> warning C4311: 'type cast' : pointer trunc
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 a
> > 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.
running each of the test executables in the tests directory and
getting a 0 exit code for each a reasonable sanity check that everything
compiled correctly and is working?
--
JAKE GOULDING
Software Engineer
[EMAIL PROTECTED]
Vivísimo [Search Done Right]
1710 Murray Avenue
Pittsburgh, PA
s to fix, which could be merged to trunk but much less
> to glib-2-8.
>
>
Maybe I am just being dense here, but am I right in interpreting this to
mean: if I fix things to get a 64-bit build, those fixes could more
easily be merged back into the trunk, where as they would be less like
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
rted', but
any help is appreciated!
Thanks again!
-jake
Hans Breuer wrote:
On 17.03.2006 22:40, Jake Goulding wrote:
Hey all:
I've had some trouble in compiling and subsequently using glib
(2.8.6) on a Windows machine.
I am building using nmake and the MSVC toolset. My proced
Hey all:
I've had some trouble in compiling and subsequently using glib (2.8.6)
on a Windows machine.
I am building using nmake and the MSVC toolset. My procedure is such:
unpack glib into a directory containing gettext and libiconv.
cd build/win32/dirent
nmake -f makefile.msc
cd ../../../
nm
25 matches
Mail list logo
