[Developer][GLib] Document GLib development workflow when using conda environment on GTK-based Linux systems

[asfimport]

I periodically deal with annoying errors like:

checking for GLIB - version >= 2.32.4... 
*** 'pkg-config --modversion glib-2.0' returned 2.58.3, but GLIB (2.56.4)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error: GLib isn't available
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target 'install'.  Stop.
Traceback (most recent call last):
	2: from /home/wesm/code/arrow/c_glib/test/run-test.rb:30:in `<main>'
	1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- gi (LoadError)

The problem is that I have one version of glib on my Linux system while another in the activated conda environment, it seems that there is a conflict even though $PKG_CONFIG_PATH is set to ignore system directories

https://gist.github.com/wesm/e62bf4517468be78200e8dd6db0fc544

Reporter: Wes McKinney / @wesm

_{Note: This issue was originally created as ARROW-7893. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
I haven't run into this issue for a while, so I'm not clear how urgent this is

[asfimport]

Wes McKinney / @wesm:
I found out the solution to this. The problem occurs when using pkg-config installed by conda rather than the pkg-config provided by the host Linux system. If someone is developing using glib provided by conda then using the conda-provided pkg-config should work.

So the fact that pkg-config is in https://github.com/apache/arrow/blob/master/ci/conda_env_cpp.yml is what's causing the problem. Running conda remove pkg-config resolved the issue I cited above. I'm not sure what can be documented better about this but it's at least some conclusion

[asfimport]

Kouhei Sutou / @kou:
LD_LIBRARY_PATH=${CONDA_ROOT}/lib is needed for resolving the error.
If we don't have the LD_LIBRARY_PATH, the system libglib-2.0.so not the conda libglib-2.0.so is referred.

Normally, do normal conda users set LD_LIBRARY_PATH?

[asfimport]

Wes McKinney / @wesm:
They don't, so this may be something quirky about my personal development environment, then.

[asfimport]

Uwe Korn / @xhochy:
@kou  Can you give me a pointer at which stage the library is loaded, i.e. where LD_LIBRARY_PATH does come into action? Then I can have a look at the conda packaging.

[asfimport]

Kouhei Sutou / @kou:
Sure.
It's the configure stage in https://github.com/apache/arrow/tree/master/c_glib#how-to-build-by-users . In configure, the GLib detection does the followings:

1. Find GLib by pkg-config
2. Build a program that verifies the found GLib version
3. Run the program (LD_LIBRARY_PATH is needed here)

See also: https://gitlab.gnome.org/GNOME/glib/-/blob/master/m4macros/glib-2.0.m4#L92-165

The GLib version verification isn't ran with Meson. We don't need to set LD_LIBRARY_PATH with Meson.
https://github.com/apache/arrow/tree/master/c_glib#how-to-build-by-users also describes how to build with Meson.

[asfimport]

Todd Farmer / @toddfarmer:
This issue was last updated over 90 days ago, which may be an indication it is no longer being actively worked. To better reflect the current state, the issue is being unassigned. Please feel free to re-take assignment of the issue if it is being actively worked, or if you plan to start that work soon.