#11760: 'sage-location' shouldn't "initialize" .pc (pkg-config) files more than
once
-----------------------+----------------------------------------------------
Reporter: leif | Owner:
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-4.7.2
Component: scripts | Keywords: pkgconfig libpng Duplicate definition
SAGE_ROOT
Work_issues: | Upstream: N/A
Reviewer: | Author: Leif Leonhardy
Merged: | Dependencies:
-----------------------+----------------------------------------------------
Changes (by newvalueoldvalue):
* status: new => needs_review
* author: => Leif Leonhardy
Old description:
> The logic of "initializing" `.pc` files exactly once is currently broken,
> which at the moment "only" causes trouble with libpng if `pkg-config` is
> installed.
>
> The main reason is that `sage-location` doesn't really check whether a
> `.pc` file already contains a definition of `SAGE_ROOT`, and
> unconditionally replaces any occurrences of `$SAGE_ROOT` (i.e., its
> current value) by `${SAGE_ROOT}`, then adding a (in the case of
> `update_pkgconfig_files()`, ''replacing'' the first) line defining
> `SAGE_ROOT` to have the current value.
>
> The specific problem with libpng (see e.g. #11686, which was originally
> intended to just again fix a ''completely unrelated'' issue with the
> matplotlib spkg) arises since it installs ''both'' a `libpng12.pc` file
> ''and a symbolic link'' `libpng.pc`, the latter pointing to the former.
> `sage-location` now "initializes" all of Sage's `.pc` files, not checking
> whether a `.pc` file is just a symbolic link to another one, nor checking
> whether a file already got modified as mentioned above.
>
> Note that the "initialization" doesn't take place ''during'' a build, but
> when Sage is started for the first time, also when e.g. running tests,
> such that problems with modified `.pc` files occur later, when one tries
> to (re)install some package(s), which includes ''upgrading'' Sage.
>
> In the long run, `sage-location` shouldn't (have to) deal with `.pc`
> files at all, but we IMHO need a '''quick fix''' until we have a better,
> more general solution to ''all'' issues with `pkg-config`. (There are a
> couple of other issues; cf. for example #10202, #9668, #11687, #11681.)
> Therefore ''this'' ticket isn't intended to fix any of the other issues.
New description:
The logic of "initializing" `.pc` files exactly once is currently broken,
which at the moment "only" causes trouble with libpng if `pkg-config` is
installed.
The main reason is that `sage-location` doesn't really check whether a
`.pc` file already contains a definition of `SAGE_ROOT`, and
unconditionally replaces any occurrences of `$SAGE_ROOT` (i.e., its
current value) by `${SAGE_ROOT}`, then adding a (in the case of
`update_pkgconfig_files()`, ''replacing'' the first) line defining
`SAGE_ROOT` to have the current value.
The specific problem with libpng (see e.g. #11686, which was originally
intended to just again fix a ''completely unrelated'' issue with the
matplotlib spkg) arises since it installs ''both'' a `libpng12.pc` file
''and a symbolic link'' `libpng.pc`, the latter pointing to the former.
`sage-location` now "initializes" all of Sage's `.pc` files, not checking
whether a `.pc` file is just a symbolic link to another one, nor checking
whether a file already got modified as mentioned above.
Note that the "initialization" doesn't take place ''during'' a build, but
when Sage is started for the first time, also when e.g. running tests,
such that problems with modified `.pc` files occur later, when one tries
to (re)install some package(s), which includes ''upgrading'' Sage.
In the long run, `sage-location` shouldn't (have to) deal with `.pc` files
at all, but we IMHO need a '''quick fix''' until we have a better, more
general solution to ''all'' issues with `pkg-config`. (There are a couple
of other issues; cf. for example #10202, #9668, #11687, #11681.) Therefore
''this'' ticket isn't intended to fix any of the other issues.
----
Apply
[attachment:trac_11760-avoid_multiple_defs_of_SAGE_ROOT.scripts.patch] to
the Sage '''scripts repository'''.
--
Comment:
Couldn't resist to also do some clean-up.
Actual (trivial) fix starting on line 178.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11760#comment:4>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
