1. 18 May, 2022 1 commit
    • Philip Withnall's avatar
      glib: Add SPDX license headers automatically · 70ee43f1
      Philip Withnall authored
      Add SPDX license (but not copyright) headers to all files which follow a
      certain pattern in their existing non-machine-readable header comment.
      This commit was entirely generated using the command:
      git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      Helps: #1415
  2. 26 Jan, 2022 3 commits
    • Loïc Le Page's avatar
      Enable full-static build on Windows · 42c77c7a
      Loïc Le Page authored
      Glib cannot be built statically on Windows because glib, gobject and gio
      modules need to perform specific initialization when DLL are loaded and
      cleanup when unloaded. Those initializations and cleanups are performed
      using the DllMain function which is not called with static builds.
      Issue is known for a while and solutions were already proposed but never
      merged (see: #692). Last
      patch is from version 2.36.x and since then the
      "constructor/destructor" mechanism has been implemented and used in
      other part of the system.
      This patch takes back the old idea and updates it to the last version of
      glib to allow static compilation on Windows.
      WARNING: because DllMain doesn't exist anymore in static compilation
      mode, there is no easy way of knowing when a Windows thread finishes.
      This patch implements a workaround for glib threads created by calling
      g_thread_new(), so all glib threads created through glib API will behave
      exactly the ...
    • Loïc Le Page's avatar
    • Loïc Le Page's avatar
      Uniformize G_PLATFORM_WIN32 and G_OS_WIN32 in glib-init.c · 4fdbfcc9
      Loïc Le Page authored
      According to build system (meson.build file), G_PLATFORM_WIN32 and G_OS_WIN32
      are synonym. This commit just unify the usage of this define to prepare
      for the static build conditional compilation code.
  3. 06 Jan, 2021 1 commit
  4. 02 Oct, 2020 1 commit
    • Simon McVittie's avatar
      glib-init: Statically assert more facts about standard types · bd1e2a98
      Simon McVittie authored
      This is a step towards #1484. We officially require a C99 toolchain,
      so we can statically assert that our artisanal hand-crafted integer
      types are compatible with the ones we would like to recommend people
      use instead.
      If there are *still* platforms where <stdint.h> is problematic, these
      static assertions can act as an early-warning that future GLib releases
      will make a C99-compliant <stdint.h> a hard requirement, in ways that
      are less straightforward to avoid (see #1484 and !1300
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  5. 06 Mar, 2019 1 commit
    • LRN's avatar
      W32: Add a simple exception handler · 025a3467
      LRN authored
      Install a Vectored Exception Handler[0]. Its sole purpose is to catch
      some exceptions (access violations, stack overflows, illegal
      instructions and debug breaks - by default, but it can be made to catch
      any exception for which a code is known) and run a debugger in response.
      This allows W32 glib applications to be run without a debugger,
      but at the same time allows a debugger to be attached in case
      something happens.
      The debugger is run with a new console, unless an environment variable
      is set to allow it to inherit the console of the crashing process.
      The short list of handleable exceptions is there to ensure that
      this handler won't run a debugger to "handle" utility exceptions,
      such as the one that is used to communicate thread names to a debugger.
      The handler is installed to be called last, and shouldn't interfere
      with any user-installed handlers.
      There's nothing fancy about the way it runs a debugger (it doesn't even
      support unicode in paths), and it deliberately avoids using glib code.
      The handler will also print a bit of information about the exception
      that it caught, and even more information for well-known exceptions,
      such as access violation.
      The whole scheme is similar to AeDebug[1] and, in fact, the signal-event
      gdb command was originally implemented for this very purpose.
      [0]: https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling
      [1]: https://docs.microsoft.com/en-us/windows/desktop/debug/configuring-automatic-debugging
  6. 18 Dec, 2018 1 commit
  7. 20 Jun, 2018 1 commit
    • LRN's avatar
      W32: add std stream redirection envvar options · 460cc723
      LRN authored
      This commit adds two W32-only environmental variable checks:
      * G_WIN32_ALLOC_CONSOLE, if set to 1, will force glib to create
        a new console if the process has no console by itself.
        This option is for GUI apps that are launched from GUI
        processes, in which case there's no console anywhere near them.
      * G_WIN32_ATTACH_CONSOLE, if set to a comma-separated list of
        standard stream names (stdint, stdout, stderr), will reopen
        a given std stream and tie it to the console (using existing console
        or parent console).
        This works either with the other option (to create a console),
        or if the app is launched from a console process (often the
        case for developers).
        The redirection is done with freopen(), dup() and dup2().
        If everything goes well, C file descriptors 0, 1 or 2 will
        be bound to stdin, stdout and stderr respectively (only for
        streams listed in the envrionmental variable), and so will
        be stdio streams by the same names.
      With these it's possible to see the output of g_log*() functions
      when running GTK4 applications, which are linked as GUI applications,
      and thus do not get a console by default.
      Fixes issue #1304
  8. 31 May, 2018 1 commit
    • Christoph Reiter's avatar
      Remove unused ENABLE_GC_FRIENDLY_DEFAULT and its build option · 118332dd
      Christoph Reiter authored
      ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
      while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
      With commit 943a18b5 (6 years ago) things were changed to always set it
      according to the content of G_DEBUG in glib_init(), making the default unused.
      Since nobody complained since then just remove the macro and the build option.
  9. 24 May, 2017 1 commit
    • swilmet's avatar
      glib/: LGPLv2+ -> LGPLv2.1+ · f9faac76
      swilmet authored
      All glib/*.{c,h} files have been processed, as well as gtester-report.
      12 of those files are not licensed under LGPL:
      Some of them are generated files, some are licensed under a BSD-style
      license and win_iconv.c is in the public domain.
      Sub-directories inside glib/:
      	deprecated/: processed in a previous commit
      	glib-mirroring-tab/: already LGPLv2.1+
      	gnulib/: not modified, the code is copied from gnulib
      	libcharset/: a copy
      	pcre/: a copy
      	tests/: processed in a previous commit
  10. 22 Nov, 2016 3 commits
    • Christian Hergert's avatar
      introspection: use (nullable) or (optional) instead of (allow-none) · 18a33f72
      Christian Hergert authored
      If we have an input parameter (or return value) we need to use (nullable).
      However, if it is an (inout) or (out) parameter, (optional) is sufficient.
      It looks like (nullable) could be used for everything according to the
      Annotation documentation, but (optional) is more specific.
    • Simon McVittie's avatar
      glib-init: statically assert that int is exactly 32 bits long · be4fd3d0
      Simon McVittie authored
      The GVariant documentation says you can assume that types of no more
      than 32 bits may be assumed to be promoted to int by the usual
      promotions. If we're going to document that, we should statically
      assert that it's true, i.e. sizeof (int) >= sizeof (int32_t).
      All reasonable modern platforms are either ILP32 (32-bit platforms),
      LP64 (64-bit Linux, *BSD etc.), or LLP64 (64-bit Windows): there have
      been ILP64 platforms in the past, but ILP64 has the compelling
      disadvantage that {signed char, short, int} can't possibly provide
      all of {int8_t, int16_t, int32_t} unless int is 32 bits long.
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
      Signed-off-by: Simon McVittie's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters
    • Simon McVittie's avatar
      glib-init: statically assert that "small" enums are all int-sized · 52276300
      Simon McVittie authored
      ISO C allows compilers to make enums smaller than int if their
      enumerated values would all fit in the range of a smaller type.
      In practice, I suspect that in relevant compilers, all enums whose
      values fit in the range INT32_MIN to INT32_MAX (inclusive) are the same
      size as int. ISO C allows compiler to break that assumption, but those
      that do would break code that works fine in other compilers, making the
      compiler look bad, for no significant benefit. I conjecture that such
      compilers are not popular.
      Let's statically assert that my assumption holds. If all goes well,
      GLib will continue to compile on every relevant platform; if it
      fails to compile on some platform as a result of this change, then
      there are probably a lot of naive uses of enums that need auditing
      for this assumption.
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
      Signed-off-by: Simon McVittie's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Allison Lortie
  11. 26 Apr, 2016 1 commit
    • LRN's avatar
      Add g_system_thread_set_name() implementation for W32 threads · e1188564
      LRN authored
      This works by using semi-documented[1] exception to tell the debugger
      that a thread needs to have its name changed.
      If this exception is not caught and handled by something, it will crash
      the process, so we need to set up our own handler in case there's no
      debugger attached or the debugger can't handle this type of exception.
      Since SEH is not supported by gcc on i686 (at the moment), we need to use VEH
      instead. For completeness the MSVC-oriented code still uses SEH, although
      there is no reason why it shouldn't work with the VEH variant used by MinGW.
      VEH handler has to be set up somewhere (g_thread_win32_init () works nicely)
      and removed once it's not needed (g_thread_win32_process_detach () is added
      expressly for that purpose). Note that g_thread_win32_process_detach() is
      only called when glib is unloaded by FreeLibrary(), not when glib-using
      process is terminating.
      This exception is known to work with WinDbg, and adding support for it into
      GDB proved to be feasible (GDB patch will be sent upstream, eventually).
      [1] https://msdn.microsoft.com/en-us/library/xcb2z8hs%28v=vs.71%29.aspx
  12. 14 Mar, 2016 1 commit
  13. 08 Oct, 2015 2 commits
  14. 12 Sep, 2015 1 commit
  15. 23 Jul, 2014 1 commit
  16. 06 Feb, 2014 2 commits
  17. 01 Feb, 2014 1 commit
  18. 31 Jan, 2014 1 commit
  19. 20 Jan, 2014 1 commit
  20. 20 Oct, 2013 1 commit
  21. 09 Apr, 2013 1 commit
  22. 15 Nov, 2012 1 commit
  23. 14 Mar, 2012 2 commits
  24. 05 Mar, 2012 1 commit
  25. 14 Dec, 2011 1 commit
  26. 16 Nov, 2011 1 commit
  27. 13 Nov, 2011 1 commit
  28. 12 Nov, 2011 1 commit
  29. 25 Oct, 2011 1 commit
  30. 04 Oct, 2011 2 commits