[PATCH] Add PCB.

[PATCH] Add PCB.

[Ricardo Wurmus]

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

Hi Guix,

the attached patch applies after the one adding gEDA/gaf[1], which is
still awaiting review.

In packaging PCB I noticed that our Mesa package loads a few libraries
with dlopen() but does not use absolute paths to store items.  In the
case of PCB, dlopen("libudev.so.0") fails and causes "pcb" die on
startup with a segfault.  To prevent this until the Mesa package is
fixed I wrapped the executable.

~~ Ricardo

[1]: https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00205.html


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-PCB.patch --]
[-- Type: text/x-patch, Size: 3641 bytes --]

From 7701a6791aea5308acd60142890b121c572da528 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado@elephly.net>
Date: Fri, 6 Mar 2015 21:11:01 +0100
Subject: [PATCH] gnu: Add PCB.

* gnu/packages/engineering.scm (pcb): New variable.
---
 gnu/packages/engineering.scm | 61 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index f907c9f..90d09c6 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -25,16 +25,22 @@
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
   #:use-module (gnu packages base)
+  #:use-module (gnu packages bison)
   #:use-module (gnu packages boost)
+  #:use-module (gnu packages flex)
   #:use-module (gnu packages fontutils)
+  #:use-module (gnu packages gd)
+  #:use-module (gnu packages gl)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages guile)
+  #:use-module ((gnu packages linux) #:select (eudev)) ; FIXME: for pcb
   #:use-module (gnu packages maths)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages qt)
+  #:use-module (gnu packages tcl)
   #:use-module (srfi srfi-1))
 
 (define-public librecad
@@ -145,3 +151,58 @@ gsch2pcb: A tool to forward annotation from your schematic to layout using PCB;
 some minor utilities.")
     (license license:gpl2+)))
 
+(define-public pcb
+  (package
+    (name "pcb")
+    (version "20140316")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "http://ftp.geda-project.org/pcb/pcb-" version "/pcb-"
+                    version ".tar.gz"))
+              (sha256
+               (base32
+                "0l6944hq79qsyp60i5ai02xwyp8l47q7xdm3js0jfkpf72ag7i42"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:phases
+       (alist-cons-after
+        'unpack 'use-wish8.6
+        (lambda _
+          (substitute* "configure"
+            (("wish85") "wish8.6")))
+        (alist-cons-after
+         'install 'wrap
+         (lambda* (#:key inputs outputs #:allow-other-keys)
+           ;; FIXME: Mesa tries to dlopen libudev.so.0 and fails.  Pending a
+           ;; fix of the mesa package we wrap the pcb executable such that
+           ;; Mesa can find libudev.so.0 through LD_LIBRARY_PATH.
+           (let* ((out (assoc-ref outputs "out"))
+                  (path (string-append (assoc-ref inputs "udev") "/lib")))
+             (wrap-program (string-append out "/bin/pcb")
+               `("LD_LIBRARY_PATH" ":" prefix (,path)))))
+         %standard-phases))))
+    (inputs
+     `(("dbus" ,dbus)
+       ("mesa" ,mesa)
+       ("udev" ,eudev) ;FIXME: required by mesa
+       ("glu" ,glu)
+       ("gd" ,gd)
+       ("gtk" ,gtk+-2)
+       ("gtkglext" ,gtkglext)
+       ("desktop-file-utils" ,desktop-file-utils)
+       ("shared-mime-info" ,shared-mime-info)
+       ("tk" ,tk)))
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("intltool" ,intltool)
+       ("bison" ,bison)
+       ("flex" ,flex)))
+    (home-page "http://pcb.geda-project.org/")
+    (synopsis "Design printed circuit board layouts")
+    (description
+     "GNU PCB is an interactive tool for editing printed circuit board
+layouts.  It features a rats-nest implementation, schematic/netlist import,
+and design rule checking.  It also includes an autorouter and a trace
+optimizer; and it can produce photorealistic and design review images.")
+    (license license:gpl2+)))
-- 
2.1.0

Re: [PATCH] Add PCB.

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> In packaging PCB I noticed that our Mesa package loads a few libraries
> with dlopen() but does not use absolute paths to store items.  In the
> case of PCB, dlopen("libudev.so.0") fails and causes "pcb" die on
> startup with a segfault.  To prevent this until the Mesa package is
> fixed I wrapped the executable.

OK.  Feel free to fix MESA eventually.  :-)

> From 7701a6791aea5308acd60142890b121c572da528 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Fri, 6 Mar 2015 21:11:01 +0100
> Subject: [PATCH] gnu: Add PCB.
>
> * gnu/packages/engineering.scm (pcb): New variable.

LGTM!

Ludo’.

Re: [PATCH] Add PCB.

[Taylan Ulrich Bayırlı/Kammer]

ludo@gnu.org (Ludovic Courtès) writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> In packaging PCB I noticed that our Mesa package loads a few libraries
>> with dlopen() but does not use absolute paths to store items.  In the
>> case of PCB, dlopen("libudev.so.0") fails and causes "pcb" die on
>> startup with a segfault.  To prevent this until the Mesa package is
>> fixed I wrapped the executable.
>
> OK.  Feel free to fix MESA eventually.  :-)

Is anyone working on this?  Otherwise I'll look into it because I
noticed mplayer2 has the same issue.

Some basic help is appreciated by the way.  How do we generally handle
dlopen() uses in Guix?

Does our rpath stuff not fix the issue, and why?

When the argument is a literal string, I suppose we can patch it to be
an absolute pathname.  And when it's parameterized?  E.g. when a program
uses a private wrapper function around dlopen(), then I guess I should
track all uses of that wrapper function?

How about when the program dlopen()s a library of its own?  Should it be
made an absolute path to the package's output directory?

Taylan

Re: [PATCH] Add PCB.

[Mark H Weaver]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>> In packaging PCB I noticed that our Mesa package loads a few libraries
>>> with dlopen() but does not use absolute paths to store items.  In the
>>> case of PCB, dlopen("libudev.so.0") fails and causes "pcb" die on
>>> startup with a segfault.  To prevent this until the Mesa package is
>>> fixed I wrapped the executable.
>>
>> OK.  Feel free to fix MESA eventually.  :-)
>
> Is anyone working on this?  Otherwise I'll look into it because I
> noticed mplayer2 has the same issue.
>
> Some basic help is appreciated by the way.  How do we generally handle
> dlopen() uses in Guix?
>
> Does our rpath stuff not fix the issue, and why?

dlopen doesn't consult rpaths.

> When the argument is a literal string, I suppose we can patch it to be
> an absolute pathname.

Yes, when we can do this, it is usually the preferred approach.

> And when it's parameterized?  E.g. when a program
> uses a private wrapper function around dlopen(), then I guess I should
> track all uses of that wrapper function?

Ideally, yes.  However, it may not always be possible.

> How about when the program dlopen()s a library of its own?  Should it be
> made an absolute path to the package's output directory?

Ideally, yes.

     Thanks!
       Mark

Re: [PATCH] Add PCB.

[Ludovic Courtès]

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

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

[...]

>> When the argument is a literal string, I suppose we can patch it to be
>> an absolute pathname.
>
> Yes, when we can do this, it is usually the preferred approach.

Agreed, except in cases where we want to retain the flexibility of
dynamic bindings, typically for plug-ins.

In the case of MESA, I think we probably want to use an absolute file
name.

Thanks,
Ludo’.