gobject-introspection typelibs and shared libraries

gobject-introspection typelibs and shared libraries

[Federico Beffa]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

Hi,

currently the typelib files used by gobject-introspection can't find
shared libraries and require setting LD_LIBRARY_PATH.  I would like to
propose to adopt the attached patch from the nix folk which should fix
that and refer to shared libraries by absolute path.

Regards,
Fede

[-- Attachment #2: absolute_shlib_path.patch --]
[-- Type: text/x-patch, Size: 920 bytes --]

--- ./giscanner/utils.py.orig	2014-08-14 22:05:05.055334080 +0200
+++ ./giscanner/utils.py	2014-08-14 22:05:24.687497334 +0200
@@ -110,17 +110,11 @@
     if dlname is None:
         return None
 
-    # Darwin uses absolute paths where possible; since the libtool files never
-    # contain absolute paths, use the libdir field
-    if platform.system() == 'Darwin':
-        dlbasename = os.path.basename(dlname)
-        libdir = _extract_libdir_field(la_file)
-        if libdir is None:
-            return dlbasename
-        return libdir + '/' + dlbasename
-    # From the comments in extract_libtool(), older libtools had
-    # a path rather than the raw dlname
-    return os.path.basename(dlname)
+    dlbasename = os.path.basename(dlname)
+    libdir = _extract_libdir_field(la_file)
+    if libdir is None:
+        return dlbasename
+    return libdir + '/' + dlbasename
 
 
 def extract_libtool(la_file):

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> currently the typelib files used by gobject-introspection can't find
> shared libraries and require setting LD_LIBRARY_PATH.

I don’t know much about all this; could you give some context?  What’s a
typelib files exactly?

> I would like to propose to adopt the attached patch from the nix folk
> which should fix that and refer to shared libraries by absolute path.

Is the output of gir-scanner(?) used on the linker command line?
Normally, our ld-wrapper handles adding a RUNPATH for any library listed
as -l on the linker command line.

Thanks,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Sun, Dec 7, 2014 at 9:48 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> currently the typelib files used by gobject-introspection can't find
>> shared libraries and require setting LD_LIBRARY_PATH.
>
> I don’t know much about all this; could you give some context?  What’s a
> typelib files exactly?

gobject-introspection is a tool to create bindings to C libraries for
other languages. To make the system flexible it creates an
intermediate object. typelib files are a binary store on disk of this
intermediate object.

https://developer.gnome.org/gi/stable/overview.html

>
>> I would like to propose to adopt the attached patch from the nix folk
>> which should fix that and refer to shared libraries by absolute path.
>
> Is the output of gir-scanner(?) used on the linker command line?
> Normally, our ld-wrapper handles adding a RUNPATH for any library listed
> as -l on the linker command line.

It is one of the tools used to create the typelib files from the C
libraries, but I do not know all the details. It is one of the tools
used for example by gtk+, pango, atk, gkd-pixbuf to generate the
content of the .../lib/girepository-1.0 directory. Given that it is
written in python, I do not think that it is used on the linker
command line.

The problem I've found is that the typelib files include the name of
required shared libraries (.so), but not the absolute path. Therefore
I was forced to set the LD_LIBRARY_PATH.

I was actually googling to find out how to instruct an application
where to look for the typelib files, when I saw this email

http://lists.science.uu.nl/pipermail/nix-dev/2014-September/014309.html

and thought that we could borrow the approach.

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Sun, Dec 7, 2014 at 9:48 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> currently the typelib files used by gobject-introspection can't find
>>> shared libraries and require setting LD_LIBRARY_PATH.
>>
>> I don’t know much about all this; could you give some context?  What’s a
>> typelib files exactly?
>
> gobject-introspection is a tool to create bindings to C libraries for
> other languages. To make the system flexible it creates an
> intermediate object. typelib files are a binary store on disk of this
> intermediate object.
>
> https://developer.gnome.org/gi/stable/overview.html

OK.

> The problem I've found is that the typelib files include the name of
> required shared libraries (.so), but not the absolute path. Therefore
> I was forced to set the LD_LIBRARY_PATH.

Yes, I see in the diagram on the page above that libraries are actually
dlopened, with the name that appears in the typelib file.

Thus the patch you proposed is the right thing, I think.  Before
committing, could you add a comment a the top of the file explaining
that the file names contained in typelib files are meant to be dlopen’d,
hence this patch?  Also please credit the original author of the patch.

> I was actually googling to find out how to instruct an application
> where to look for the typelib files, when I saw this email
>
> http://lists.science.uu.nl/pipermail/nix-dev/2014-September/014309.html
>
> and thought that we could borrow the approach.

Definitely.

Do we also need to do something for GI_TYPELIB_PATH?  Perhaps this
should be in the ‘native-search-paths’ field of gobject-introspection?
(It would be good to push both changes at once, if appropriate, to
reduce rebuilds.)

Thanks for the explanations, and for addressing this!

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Mon, Dec 8, 2014 at 10:22 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Yes, I see in the diagram on the page above that libraries are actually
> dlopened, with the name that appears in the typelib file.
>
> Thus the patch you proposed is the right thing, I think.  Before
> committing, could you add a comment a the top of the file explaining
> that the file names contained in typelib files are meant to be dlopen’d,
> hence this patch?  Also please credit the original author of the patch.

Actually, I see that this part of gobject-introspection was slightly
edited from our version 1.38.0 to later ones. Nix uses 1.40.0 and the
newest is 1.42.0. So I'm planning to upgrade to the latest.

> Do we also need to do something for GI_TYPELIB_PATH?  Perhaps this
> should be in the ‘native-search-paths’ field of gobject-introspection?

I think that we do not need to set GI_TYPELIB_PATH in
gobject-introspection, but in in the packages making use of it.

Fede

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Mon, Dec 8, 2014 at 1:21 PM, Federico Beffa <beffa@ieee.org> wrote:
> Actually, I see that this part of gobject-introspection was slightly
> edited from our version 1.38.0 to later ones. Nix uses 1.40.0 and the
> newest is 1.42.0. So I'm planning to upgrade to the latest.

The patch applies and build succeeds for 1.40.0 and 1.42.0. However,
some test fail. Nix disables the test phase. Are you OK disabling the
tests and going with 1.42.0.

(I've tried to apply a similar patch to our current version 1.38.0,
but with only the change copied from the patch I posted the build
phase fails.)

>
>> Do we also need to do something for GI_TYPELIB_PATH?  Perhaps this
>> should be in the ‘native-search-paths’ field of gobject-introspection?
>
> I think that we do not need to set GI_TYPELIB_PATH in
> gobject-introspection, but in in the packages making use of it.

I've run the tests with and without

    (native-search-paths
     (list (search-path-specification
            (variable "GI_TYPELIB_PATH")
            (directories '("lib/girepository-1.0")))))
    (search-paths native-search-paths)

(and with/without (search-path ...), but it makes no difference.  This
probably due to the fact that there is no lib/girepository-1.0
directory in the source tree and the tests are run before
installation. I therefore think that this is not needed here.  It will
be needed with packages making use of gobject-introspection or other
libraries providing typelib files.

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Mon, Dec 8, 2014 at 10:22 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Yes, I see in the diagram on the page above that libraries are actually
>> dlopened, with the name that appears in the typelib file.
>>
>> Thus the patch you proposed is the right thing, I think.  Before
>> committing, could you add a comment a the top of the file explaining
>> that the file names contained in typelib files are meant to be dlopen’d,
>> hence this patch?  Also please credit the original author of the patch.
>
> Actually, I see that this part of gobject-introspection was slightly
> edited from our version 1.38.0 to later ones. Nix uses 1.40.0 and the
> newest is 1.42.0. So I'm planning to upgrade to the latest.

Good.

>>> Do we also need to do something for GI_TYPELIB_PATH?  Perhaps this
>>> should be in the ‘native-search-paths’ field of gobject-introspection?
>>
>> I think that we do not need to set GI_TYPELIB_PATH in
>> gobject-introspection, but in in the packages making use of it.
>
> I've run the tests with and without
>
>     (native-search-paths
>      (list (search-path-specification
>             (variable "GI_TYPELIB_PATH")
>             (directories '("lib/girepository-1.0")))))
>     (search-paths native-search-paths)

You added these fields to ‘gobject-introspection’ itself, right?  That’s
where it belongs.

> (and with/without (search-path ...), but it makes no difference.  This
> probably due to the fact that there is no lib/girepository-1.0
> directory in the source tree and the tests are run before
> installation.

This will only make a difference when building packages that depend on
gobject-introspection, and that also depend on packages having a
lib/girepository-1.0 sub-directory.

(Compare to how CPATH is handled for GCC.)

> I therefore think that this is not needed here.  It will be needed
> with packages making use of gobject-introspection or other libraries
> providing typelib files.

Exactly.  So it’s better to push a patch that adds it right after the
patch that fixes g-ir-scanner.

Thanks,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Mon, Dec 8, 2014 at 9:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Exactly.  So it’s better to push a patch that adds it right after the
> patch that fixes g-ir-scanner.

I've pushed the two changes and see that it breaks several packages
depending on gobject-introspection.
Looking randomly at some of the failures I see that pango and
gdk-pixbuf fail to build (and many other failures are a consequence of
one of these two). So I've tried to build pango with
gobject-introspection 1.42.0 without any change (no patch, no
native-search-path) and without the patch, but with
native-search-path. However, it always fails to build.

So, I've updated pango to the latest 1.36.8 and it builds with the new
and patched gobject-introspection and I see that the gir files of the
former include the full path of dynamic libraries.

I've then updated pix-buf to the latest and it builds fine, but have 2
out of 74 test failures.

What do you prefer? Revert to gobject-introspection 1.38.0, or got
down the version dependency hell?

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Tue, Dec 9, 2014 at 8:30 PM, Federico Beffa <beffa@ieee.org> wrote:
> I've then updated pix-buf to the latest and it builds fine, but have 2
> out of 74 test failures.

gdk-pixbuf 2.31.2 (latest) fails 2 tests, but 2.31.1 passes all of them.

Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I've pushed the two changes and see that it breaks several packages
> depending on gobject-introspection.
> Looking randomly at some of the failures I see that pango and
> gdk-pixbuf fail to build (and many other failures are a consequence of
> one of these two). So I've tried to build pango with
> gobject-introspection 1.42.0 without any change (no patch, no
> native-search-path) and without the patch, but with
> native-search-path. However, it always fails to build.
>
> So, I've updated pango to the latest 1.36.8 and it builds with the new
> and patched gobject-introspection and I see that the gir files of the
> former include the full path of dynamic libraries.
>
> I've then updated pix-buf to the latest and it builds fine, but have 2
> out of 74 test failures.

Oh oh, OK.

> What do you prefer? Revert to gobject-introspection 1.38.0, or got
> down the version dependency hell?

If you think it will require some more time, then it may be less
disturbing to set up a branch for those changes, and revert the
offending commit in master while the branch is being stabilized.  WDYT?

We can set up Hydra to build the branch, so we have feedback, if you
want.

Thanks for investigating,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa <beffa@ieee.org> writes:

> On Tue, Dec 9, 2014 at 8:30 PM, Federico Beffa <beffa@ieee.org> wrote:
>> I've then updated pix-buf to the latest and it builds fine, but have 2
>> out of 74 test failures.
>
> gdk-pixbuf 2.31.2 (latest) fails 2 tests, but 2.31.1 passes all of them.

This is a bug in 2.31.2, where they forgot to include a test image in
the tarball.  See:

  https://mail.gnome.org/archives/commits-list/2014-December/msg01800.html

     Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa <beffa@ieee.org> writes:
> What do you prefer? Revert to gobject-introspection 1.38.0, or got
> down the version dependency hell?

I've started working on this.  It turns out we have to go down quite a
rabbit hole.  Among other things, 'eudev' must be updated, and we will
lose 'udev' entirely.  I'll see how deep the rabbit hole goes and report
back.

      Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Federico Beffa <beffa@ieee.org> writes:
>> What do you prefer? Revert to gobject-introspection 1.38.0, or got
>> down the version dependency hell?
>
> I've started working on this.  It turns out we have to go down quite a
> rabbit hole.  Among other things, 'eudev' must be updated [...]

It turns out that even the most recent release of 'eudev' (2.1.1) fails
to work with gobject-introspection 1.42.0.  I looked in their git repo,
and didn't see any commits addressing this issue.

I think we should revert the gobject-introspection update for now.

What do you think?

      Mark

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Federico Beffa <beffa@ieee.org> writes:
>>> What do you prefer? Revert to gobject-introspection 1.38.0, or got
>>> down the version dependency hell?
>>
>> I've started working on this.  It turns out we have to go down quite a
>> rabbit hole.  Among other things, 'eudev' must be updated [...]
>
> It turns out that even the most recent release of 'eudev' (2.1.1) fails
> to work with gobject-introspection 1.42.0.  I looked in their git repo,
> and didn't see any commits addressing this issue.

What relation do these two packages have?

> I think we should revert the gobject-introspection update for now.
>
> What do you think?

Yes, let’s create a branch with all the update work the two of you have
done, and revert the upgrade in master.

Thanks,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Wed, Dec 10, 2014 at 9:48 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> I think we should revert the gobject-introspection update for now.
>>
>> What do you think?
>
> Yes, let’s create a branch with all the update work the two of you have
> done, and revert the upgrade in master.

I've reverted the change in my repository. However, I have a prior
commit (for the package cffi for which I submitted a patch) and have
no idea how to only push the latest commit.

Would you suggest the appropriate command, or, if you had a look at
the patch for cffi, can I submit both commits?

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Wed, Dec 10, 2014 at 9:48 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> I think we should revert the gobject-introspection update for now.
>>>
>>> What do you think?
>>
>> Yes, let’s create a branch with all the update work the two of you have
>> done, and revert the upgrade in master.
>
> I've reverted the change in my repository. However, I have a prior
> commit (for the package cffi for which I submitted a patch) and have
> no idea how to only push the latest commit.

Basically you’d need to rewrite history, which is easy with Magit, or
otherwise can be achieved with ‘git rebase -i’.

> Would you suggest the appropriate command, or, if you had a look at
> the patch for cffi, can I submit both commits?

The CFFI looks good to me, so yes.

Thanks!

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Wed, Dec 10, 2014 at 1:56 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Yes, let’s create a branch with all the update work the two of you have
>>> done, and revert the upgrade in master.

I've created a branch named wip-gobject-introspection with the patch
and version 1.42.0.  I've also pushed version updates for pango and
gdk-pixbuf compatible with the former.

Would be nice to have hydra build that, so that we can see what's failing.

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa <beffa@ieee.org> writes:

> On Wed, Dec 10, 2014 at 1:56 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Yes, let’s create a branch with all the update work the two of you have
>>>> done, and revert the upgrade in master.
>
> I've created a branch named wip-gobject-introspection with the patch
> and version 1.42.0.  I've also pushed version updates for pango and
> gdk-pixbuf compatible with the former.
>
> Would be nice to have hydra build that, so that we can see what's failing.

I went down this road, and found that a great many things fail.  I don't
remember finding a single package that uses gobject-introspection that
worked without updating.

I got stuck on eudev.  The newest version doesn't work, and I didn't see
anything in their git repo to fix it either.

Before moving forward on this, can you find a way to build eudev with
gobject-introspection-1.42.0?

Also, I'm currently working on upgrading almost every package in
xorg.scm, as well as glib and dbus.  I'll push it as a branch in the
next day or two.  It probably makes the most sense to build your branch
on top of mine.

Thanks for working on this!

    Regards,
      Mark

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I've created a branch named wip-gobject-introspection with the patch
> and version 1.42.0.  I've also pushed version updates for pango and
> gdk-pixbuf compatible with the former.

Perfect.

Mark H Weaver <mhw@netris.org> skribis:

> I went down this road, and found that a great many things fail.  I don't
> remember finding a single package that uses gobject-introspection that
> worked without updating.
>
> I got stuck on eudev.  The newest version doesn't work, and I didn't see
> anything in their git repo to fix it either.
>
> Before moving forward on this, can you find a way to build eudev with
> gobject-introspection-1.42.0?
>
> Also, I'm currently working on upgrading almost every package in
> xorg.scm, as well as glib and dbus.  I'll push it as a branch in the
> next day or two.  It probably makes the most sense to build your branch
> on top of mine.

Great.  Let’s make sure things keep moving forward, and we’ll see
how it goes.

Thanks to both of you!

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

On Wed, Dec 17, 2014 at 9:57 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> I've created a branch named wip-gobject-introspection with the patch
>> and version 1.42.0.  I've also pushed version updates for pango and
>> gdk-pixbuf compatible with the former.

[...]

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I went down this road, and found that a great many things fail.  I don't
>> remember finding a single package that uses gobject-introspection that
>> worked without updating.
>>
>> I got stuck on eudev.  The newest version doesn't work, and I didn't see
>> anything in their git repo to fix it either.
>>
>> Before moving forward on this, can you find a way to build eudev with
>> gobject-introspection-1.42.0?

The attached patch fixes the build of eudev with the newer
gobject-introspection. It turns out that g-ir-scanner looks for the C
compiler as either 'cc' or as the environment variable 'CC'.  So, the
fix was easy in retrospective :-).

The question is: do we want to make a 'cc' symlink to 'gcc' in the
'gcc' package? This is something that many distributions do.  If we
don't, we may have to make a patch similar to the attached one for
several packages (or patch 'gobject-introspection' to look for 'gcc'
by default). Personally I would prefer the symlink approach.

>>
>> Also, I'm currently working on upgrading almost every package in
>> xorg.scm, as well as glib and dbus.  I'll push it as a branch in the
>> next day or two.  It probably makes the most sense to build your branch
>> on top of mine.

Now that your updates are in master, I've merged them into the branch
wip-gobject-introspection.
To help see what works and what not, it would be helpful to set up
hydra to build the wip-gobject-introspection branch.

WDYT?

Regards,
Fede

[-- Attachment #2: 0001-gnu-eudev-Add-pre-build-phase.patch --]
[-- Type: text/x-patch, Size: 1675 bytes --]

From 355bae94512391434bb6c7e14e8632451654380b Mon Sep 17 00:00:00 2001
From: Federico Beffa <beffa@fbengineering.ch>
Date: Tue, 13 Jan 2015 16:25:29 +0100
Subject: [PATCH] gnu: eudev: Add pre-build phase.

* gnu/packages/linux.scm (eudev): Add 'pre-build phase to fix compilation with
  'gobject-introspection' 1.42.0.
---
 gnu/packages/linux.scm | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 4599323..ad4e52c 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1407,9 +1407,21 @@ time.")
                   (("linux/btrfs\\.h")
                    "")))))
     (arguments
-     (substitute-keyword-arguments (package-arguments udev)
-       ((#:configure-flags flags)
-        `(cons "--enable-libkmod" ,flags))))
+     `(,@(substitute-keyword-arguments (package-arguments udev)
+           ((#:configure-flags flags)
+            `(cons "--enable-libkmod" ,flags)))
+       #:phases 
+       (alist-cons-before
+        'build 'pre-build
+        ;; The program 'g-ir-scanner' (part of the package
+        ;; 'gobject-introspection'), to generate .gir files, makes some
+        ;; library pre-processing.  During that phase it looks for the C
+        ;; compiler as either 'cc' or as defined by the environment variable
+        ;; 'CC' (with code in 'giscanner/dumper.py').
+        (lambda* (#:key inputs #:allow-other-keys)
+          (let ((gcc (string-append (assoc-ref inputs "gcc") "/bin/gcc")))
+            (setenv "CC" gcc)))
+        %standard-phases)))
     (home-page "http://www.gentoo.org/proj/en/eudev/")))
 
 (define-public lvm2
-- 
1.8.4

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> The question is: do we want to make a 'cc' symlink to 'gcc' in the
> 'gcc' package?

So far we’ve resisted the temptation, and it’s rarely been an issue.
:-)

> From 355bae94512391434bb6c7e14e8632451654380b Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Tue, 13 Jan 2015 16:25:29 +0100
> Subject: [PATCH] gnu: eudev: Add pre-build phase.
>
> * gnu/packages/linux.scm (eudev): Add 'pre-build phase to fix compilation with
>   'gobject-introspection' 1.42.0.

[...]

> +       (alist-cons-before
> +        'build 'pre-build
> +        ;; The program 'g-ir-scanner' (part of the package
> +        ;; 'gobject-introspection'), to generate .gir files, makes some
> +        ;; library pre-processing.  During that phase it looks for the C
> +        ;; compiler as either 'cc' or as defined by the environment variable
> +        ;; 'CC' (with code in 'giscanner/dumper.py').
> +        (lambda* (#:key inputs #:allow-other-keys)
> +          (let ((gcc (string-append (assoc-ref inputs "gcc") "/bin/gcc")))
> +            (setenv "CC" gcc)))

I suspect this may be simplified with just:

  (setenv "CC" "gcc")

Otherwise LGTM.

Thanks,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Tue, Jan 13, 2015 at 9:22 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> The question is: do we want to make a 'cc' symlink to 'gcc' in the
>> 'gcc' package?
>
> So far we’ve resisted the temptation, and it’s rarely been an issue.
> :-)

Could you elaborate on the down sides? (I'm not trying to insist, but to learn.)

Thanks,
Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Tue, Jan 13, 2015 at 9:22 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> The question is: do we want to make a 'cc' symlink to 'gcc' in the
>>> 'gcc' package?
>>
>> So far we’ve resisted the temptation, and it’s rarely been an issue.
>> :-)
>
> Could you elaborate on the down sides? (I'm not trying to insist, but to learn.)

Basically it’s good to stick to what GCC does, and GCC does not install
‘cc’.  There’s a subjective aesthetic downside: it’s good to spread the
‘g’.  And also, it turns out to work for 99% of the packages.

(I’m afraid this answer may disappoint you.  ;-))

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Wed, Jan 14, 2015 at 9:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> So far we’ve resisted the temptation, and it’s rarely been an issue.
>>> :-)
>>
>> Could you elaborate on the down sides? (I'm not trying to insist, but to learn.)
>
> Basically it’s good to stick to what GCC does, and GCC does not install
> ‘cc’.  There’s a subjective aesthetic downside: it’s good to spread the
> ‘g’.  And also, it turns out to work for 99% of the packages.

OK, I thought you were referring to technical reasons...

A different look at aesthetics: Back in the mid '90, when Linux was
still an underground curiosity, many UNIX admins were starting to
install GNU user-land applications. To avoid name clashes with the
vendor versions of programs they were prefixing all GNU applications
with a 'g'. So, the GNU version of 'ls' was named 'gls', 'awk' ->
'gawk', ...  Now on GNU/Linux systems there's no need for such
prefixing and, for consistency and to send a message, you may just
name the C compiler with the traditional name 'cc' which means: Hey,
this is the official system C compiler and of course, it's the GNU
one.

Regards,
Fede

Re: gobject-introspection typelibs and shared libraries

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> A different look at aesthetics: Back in the mid '90, when Linux was
> still an underground curiosity, many UNIX admins were starting to
> install GNU user-land applications. To avoid name clashes with the
> vendor versions of programs they were prefixing all GNU applications
> with a 'g'. So, the GNU version of 'ls' was named 'gls', 'awk' ->
> 'gawk', ...  Now on GNU/Linux systems there's no need for such
> prefixing and, for consistency and to send a message, you may just
> name the C compiler with the traditional name 'cc' which means: Hey,
> this is the official system C compiler and of course, it's the GNU
> one.

Yeah, and I see that GCC installs ‘c++’.

If there’s consensus to install the symlink, that’s fine with me (if we
take that route, I would also suggest submitting a patch upstream so GCC
installs the symlink.)

It’s a rebuild-the-world change, though, so it would be for the next
‘core-updates’ cycle.  In the meantime, it’s ‘gcc’.

WDYT?

Thanks,
Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Thu, Jan 15, 2015 at 10:42 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> A different look at aesthetics: Back in the mid '90, when Linux was
>> still an underground curiosity, many UNIX admins were starting to
>> install GNU user-land applications. To avoid name clashes with the
>> vendor versions of programs they were prefixing all GNU applications
>> with a 'g'. So, the GNU version of 'ls' was named 'gls', 'awk' ->
>> 'gawk', ...  Now on GNU/Linux systems there's no need for such
>> prefixing and, for consistency and to send a message, you may just
>> name the C compiler with the traditional name 'cc' which means: Hey,
>> this is the official system C compiler and of course, it's the GNU
>> one.
>
> Yeah, and I see that GCC installs ‘c++’.
>
> If there’s consensus to install the symlink, that’s fine with me (if we
> take that route, I would also suggest submitting a patch upstream so GCC
> installs the symlink.)
>
> It’s a rebuild-the-world change, though, so it would be for the next
> ‘core-updates’ cycle.  In the meantime, it’s ‘gcc’.
>
> WDYT?

To me that's the way it should be on a GNU system :-)

Thanks!
Fede

Re: gobject-introspection typelibs and shared libraries

[Andreas Enge]

On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote:
> If there’s consensus to install the symlink, that’s fine with me (if we
> take that route, I would also suggest submitting a patch upstream so GCC
> installs the symlink.)

I am not in favour of adding such a symlink on our own and would rather
keep with the standard builds as we usually do when there is no compelling
reason to do otherwise.

Andreas

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote:
>> If there’s consensus to install the symlink, that’s fine with me (if we
>> take that route, I would also suggest submitting a patch upstream so GCC
>> installs the symlink.)
>
>I am not in favour of adding such a symlink on our own and would rather
>keep with the standard builds as we usually do when there is no compelling
>reason to do otherwise.

That's interesting.

Consider that:

* such a symlink would have spared much frustration to Mark (see
earlier posts in this thread).

* It is likely that the update of 'gobject-introspection' to a newer
version would not have caused problems (see earlier posts in this
thread and https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00196.html).
And, from Ludovic's comment: "So far we’ve resisted the temptation.
...", I understand that there are a few other packages which would
benefit.

* Up to now nobody could point out any *technical* drawback. (And if
we find one later, we can always revert.)

Even if an action if beneficial to, say, 1 in 100 packages without
drawbacks to the other ones and the fix of that single package is
easy, it is still worth doing. I do not see a large number of people
contributing to this project. It is therefore important to minimize
the likelihood of a required manual intervention to fix problems.
Maintaining 1000's of software packages is time consuming!

It would be the *GUIX project* the one who would benefit if decisions
would be taken based on technical arguments and merits instead of
feelings or the mood of the day.

Fede

Re: gobject-introspection typelibs and shared libraries

[宋文武]

Federico Beffa <beffa@ieee.org> writes:

>>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote:
>>> If there’s consensus to install the symlink, that’s fine with me (if we
>>> take that route, I would also suggest submitting a patch upstream so GCC
>>> installs the symlink.)
>>
>>I am not in favour of adding such a symlink on our own and would rather
>>keep with the standard builds as we usually do when there is no compelling
>>reason to do otherwise.
>
> That's interesting.
>
> Consider that:
>
> * such a symlink would have spared much frustration to Mark (see
> earlier posts in this thread).
How about set $CC to 'gcc' in our 'gnu-build-system'?
>
> * It is likely that the update of 'gobject-introspection' to a newer
> version would not have caused problems (see earlier posts in this
> thread and https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00196.html).
> And, from Ludovic's comment: "So far we’ve resisted the temptation.
> ...", I understand that there are a few other packages which would
> benefit.
>
> * Up to now nobody could point out any *technical* drawback. (And if
> we find one later, we can always revert.)
>
> Even if an action if beneficial to, say, 1 in 100 packages without
> drawbacks to the other ones and the fix of that single package is
> easy, it is still worth doing. I do not see a large number of people
> contributing to this project. It is therefore important to minimize
> the likelihood of a required manual intervention to fix problems.
> Maintaining 1000's of software packages is time consuming!
>
> It would be the *GUIX project* the one who would benefit if decisions
> would be taken based on technical arguments and merits instead of
> feelings or the mood of the day.
>
> Fede

‘gcc’ vs. ‘cc’

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> * such a symlink would have spared much frustration to Mark (see
> earlier posts in this thread).

Again, there have been few cases where this has caused problems (on the
order of 10-20 packages out of 1000.)  I agree it’s better if we can
avoid these problems altogether, but it’s not a real threat either.  ;-)

What about doing this:

  1. Someone (Fede? :-)) opens a bug against GCC at
     <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
     link.

  2. In the next core-updates, we introduce (setenv "CC" "gcc"), as
     suggested by 宋文武, which is the least intrusive solution.  It
     will fix most uses I think, but not all (for instance, GLEW has
     “CC = cc” hard-coded in its Makefile, so it will still need
     patching; this is fine, IMO.)

WDYT?

Ludo’.

Re: ‘gcc’ vs. ‘cc’

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Sat, Jan 17, 2015 at 11:40:30AM +0100, Ludovic Courtès wrote:
     Federico Beffa <beffa@ieee.org> skribis:
     
     > * such a symlink would have spared much frustration to Mark (see
     > earlier posts in this thread).
     
     Again, there have been few cases where this has caused problems (on the
     order of 10-20 packages out of 1000.)  I agree it’s better if we can
     avoid these problems altogether, but it’s not a real threat either.  ;-)
     
     What about doing this:
     
       1. Someone (Fede? :-)) opens a bug against GCC at
          <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
          link.
     
       2. In the next core-updates, we introduce (setenv "CC" "gcc"), as
          suggested by 宋文武, which is the least intrusive solution.  It
          will fix most uses I think, but not all (for instance, GLEW has
          “CC = cc” hard-coded in its Makefile, so it will still need
          patching; this is fine, IMO.)
     
     WDYT?
     

If we choose to do that, then for consistency we should also 
do (setenv "LEX" "flex") and (setenv "YACC" "bison")  Possibly a few others too.
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ‘gcc’ vs. ‘cc’

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> If we choose to do that, then for consistency we should also 
> do (setenv "LEX" "flex") and (setenv "YACC" "bison")  Possibly a few others too.

Bah, this suggests that it’s a can of worms.

Maybe the symlink is better, then.

Ludo’.

Re: ‘gcc’ vs. ‘cc’

[Federico Beffa]

On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>   1. Someone (Fede? :-)) opens a bug against GCC at
>      <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
>      link.

Given that gcc is also used on many proprietary UNIX systems, in my
opinion, handling of the cc name is a system thing, not a gcc one.

Fede

Re: gobject-introspection typelibs and shared libraries

[Andreas Enge]

On Sat, Jan 17, 2015 at 10:46:35AM +0100, Federico Beffa wrote:
> It would be the *GUIX project* the one who would benefit if decisions
> would be taken based on technical arguments and merits instead of
> feelings or the mood of the day.

Why do you suggest that my message was inspired by feelings or the mood
of the day? In fact, it was rather by the principles and design choices
we have made (without necessarily writing them down) in the past.
Especially with little available work power, I think it is important that we
do not make too many modifications to the upstream packages; there are
distributions out there with a tendency to become more or less upstream
themselves... On the long run, this would be a nightmare to maintain.

On Sat, Jan 17, 2015 at 11:47:20AM +0100, Ludovic Courtès wrote:
> John Darrington <john@darrington.wattle.id.au> skribis:
> > If we choose to do that, then for consistency we should also
> > do (setenv "LEX" "flex") and (setenv "YACC" "bison")  Possibly a few others too.
> Bah, this suggests that it’s a can of worms.

I think this makes exactly my technical point above...

Now we can and do make exceptions. About the particular issue, I do not
have very strong feelings. I fail to see why '(setenv "CC" "gcc")'
in cases where it is necessary poses major problems; but having a symlink
would also be okay. But if we go for the latter, I think you should bring
it up with the gcc project first.

Andreas

Re: ‘gcc’ vs. ‘cc’

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>   1. Someone (Fede? :-)) opens a bug against GCC at
>>      <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
>>      link.
>
> Given that gcc is also used on many proprietary UNIX systems, in my
> opinion, handling of the cc name is a system thing, not a gcc one.

Right, makes sense.

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge <andreas@enge.fr> wrote:
> Why do you suggest that my message was inspired by feelings or the mood
> of the day? In fact, it was rather by the principles and design choices
> we have made (without necessarily writing them down) in the past.
> Especially with little available work power, I think it is important that we
> do not make too many modifications to the upstream packages; there are
> distributions out there with a tendency to become more or less upstream
> themselves... On the long run, this would be a nightmare to maintain.

I guess I misunderstood a little bit your email.

I think we are all on the same page on the fact that we want to
minimize modifications from upstream.

For the specifics of this case, I don't see any danger of becoming an
upstream reference because: (i) it is not a modification of a package,
but a trivial non invasive addition and (ii) many distributions
(including, e.g., Debian) already have a 'cc' command pointing to
'gcc'.

>
> On Sat, Jan 17, 2015 at 11:47:20AM +0100, Ludovic Courtès wrote:
>> John Darrington <john@darrington.wattle.id.au> skribis:
>> > If we choose to do that, then for consistency we should also
>> > do (setenv "LEX" "flex") and (setenv "YACC" "bison")  Possibly a few others too.
>> Bah, this suggests that it’s a can of worms.
>
> I think this makes exactly my technical point above...
>
> Now we can and do make exceptions. About the particular issue, I do not
> have very strong feelings. I fail to see why '(setenv "CC" "gcc")'
> in cases where it is necessary poses major problems; but having a symlink

Lets take 'gobject-introspection' as one illustrative example: we were
using a version which was compiling fine without the need for $CC.
Then, first Mark and then me tried to update to the latest version and
suddenly many packages were not building anymore with the new version
(but 'gobject-introspection' itself was still building fine). Mark
temporarily gave up (I guess because he had other priorities), but I
went further because I really needed the latest version to fix the
absolute path of dynamic libraries referred to in typelib/gir files.
To find the root cause I had to go and read the source of
'g-ir-scanner' with which I'm not at all familiar and which is made
out of many files. After a while I've found that 'g-ir-scanner' looks
for the environment variable CC and, if it is not defined, then it
used the hard coded command 'cc' to call the C compiler.

The moral of the story is that sometimes it is *difficult to find out*
that you need to define CC. Given that the traditional name of the C
compiler is 'cc' and not 'gcc', having that name defined could
sometimes save us time. Remember that not everybody only targets the
GNU C compiler. In the example above the upgrade would just have gone
smooth.

> would also be okay. But if we go for the latter, I think you should bring
> it up with the gcc project first.

I expressed my opinion on this here
https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00230.html

Hope this helps to clarify the reason for my suggestion.
Fede

Re: gobject-introspection typelibs and shared libraries

[Andreas Enge]

On Sun, Jan 18, 2015 at 10:39:52AM +0100, Federico Beffa wrote:
> On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge <andreas@enge.fr> wrote:
> > would also be okay. But if we go for the latter, I think you should bring
> > it up with the gcc project first.
> I expressed my opinion on this here
> https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00230.html

Yes, that was a good point (which crossed my message).

Andreas