Answered basically the same on the downstream bug report:

The _utf8() variants should only exist in 32 bit binaries.
Code calling the non _utf8() variants when compiled against a glib newer than
2.18 (iirc) automatically use the _utf8() dll entry points. The non _utf8()
dll entry points are (or where) provided for backward compatibility. In
other words, to support binaries compiled against a glib version older
than 2.18 (again, iirc). At least, that was the idea back when this
was implemented.

This compatibility problem never existed with 64 bit binaries as there
never where no non-utf8 using binaries using libglib and friends in
existence (either mingw-w64 didn't exist yet or the gtk+ stack did not
yet support it, who knows...) so the _utf8() variants should simply
not exist there.

(In reply to comment #1)
> This compatibility problem never existed with 64 bit binaries as there
> never where no non-utf8 using binaries using libglib and friends in
> existence (either mingw-w64 didn't exist yet or the gtk+ stack did not
> yet support it, who knows...) so the _utf8() variants should simply
> not exist there.



I don't understand what you mean there.

Before the patch, I can see:

-#ifdef G_OS_WIN32
-#define g_get_user_name g_get_user_name_utf8
-#define g_get_real_name g_get_real_name_utf8
-#define g_get_home_dir g_get_home_dir_utf8
-#define g_get_tmp_dir g_get_tmp_dir_utf8
-#define g_find_program_in_path g_find_program_in_path_utf8
...

So this was clearly redefined if G_OS_WIN32. But G_OS_WIN32 is true for 64bit build as well..

I would really like to see the change I proposed applied, so that both 32bit and 64bit expose the same symbols:
-#if defined (G_OS_WIN32) && !defined (_WIN64)
+#if defined (G_OS_WIN32)

Dieter and I have both clearly made the same mistake in misunderstanding the situation:

The _utf8 version is always available on Windows (this much is very clear from the defines inside of the G_OS_WIN32 ifdef in the header).

The question is about the old codepage versions of the functions.  Those ones were the ones that were made unavailable on Win64 because they had only ever been there for compat reasons.

So what I thought it was like:

  utf8 API on UNIX:          g_get_home_dir()
  Codepage API on win64:     n/a
  utf8 API on win64:         g_get_home_dir()
  Codepage API on win32:     g_get_home_dir()
  utf8 API on win32:         g_get_home_dir_utf8()

But what was really true:

  utf8 API on UNIX:          g_get_home_dir()
  Codepage API on win64:     n/a
  utf8 API on win64:         g_get_home_dir_utf8()
  Codepage API on win32:     g_get_home_dir()
  utf8 API on win32:         g_get_home_dir_utf8()

and what I changed it to:

  utf8 API on UNIX:          g_get_home_dir()
  Codepage API on win64:     n/a
  utf8 API on win64:         g_get_home_dir()
  Codepage API on win32:     n/a
  utf8 API on win32:         g_get_home_dir(), alias g_get_home_dir_utf8()

because I previously thought that win64 never used the _utf8() thing.

I should have changed it to:

  utf8 API on UNIX:          g_get_home_dir()
  Codepage API on win64:     n/a
  utf8 API on win64:         g_get_home_dir(), alias g_get_home_dir_utf8()
  Codepage API on win32:     n/a
  utf8 API on win32:         g_get_home_dir(), alias g_get_home_dir_utf8()

ie: no difference on the introduction of aliases for win32 vs. win64.

This is what the patch proposed here does (assuming the context is what I believe it to be), so please commit it.

Thanks for the report!

Created attachment 241580 [details] [review]
win32: add back missing _utf8 symbols on x64 builds

The _utf8 functions have been wrongly removed from GLib on x64.

(In reply to comment #3)
> I should have changed it to:
> 
>   utf8 API on UNIX:          g_get_home_dir()
>   Codepage API on win64:     n/a
>   utf8 API on win64:         g_get_home_dir(), alias g_get_home_dir_utf8()
>   Codepage API on win32:     n/a
>   utf8 API on win32:         g_get_home_dir(), alias g_get_home_dir_utf8()
> 
> ie: no difference on the introduction of aliases for win32 vs. win64.
> 
This would break binary compatibility (ABI) for win32. You would break
every program compiled against the former GLib version.

> This is what the patch proposed here does (assuming the context is what I
> believe it to be), so please commit it.
> 
Please don't. It used to be and IMHO should stay that way:

utf8 API on UNIX:             g_get_home_dir()
Codepage API on win64:     n/a
utf8 API on win64:           g_get_home_dir()
Codepage API on win32:  g_get_home_dir()
utf8 API on win32:           g_get_home_dir_utf8()

Every win32 program compiled against the new enough
GLib version will thus use g_get_home_dir_utf8(). But
every older program will still work with the "code page
API" using the filename convention of the CRT.

Attachment 241580 [details] pushed as b972018 - win32: add back missing _utf8 symbols on x64 builds


The codepage API was already removed before the 2.36.0 release, so the
damage is already done there.  I have it on good authority that there is
no actual damage though, as GLib has broken binary compatibility several
times since the old codepage API was exposed.

(In reply to comment #3)
> I should have changed it to:
> 
>   utf8 API on UNIX:          g_get_home_dir()
>   Codepage API on win64:     n/a
>   utf8 API on win64:         g_get_home_dir(), alias g_get_home_dir_utf8()
>   Codepage API on win32:     n/a
>   utf8 API on win32:         g_get_home_dir(), alias g_get_home_dir_utf8()

Argh, we did manage to flip around the win64 case there. My fault,
apologies for the confusion. The above is obviously correct.

Did you mean to reopen the bug or was that an accident?

(In reply to comment #8)
> Did you mean to reopen the bug or was that an accident?

Accident. Most weird, set it back to RESOLVED FIXED...