Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 8539] read_persistent function

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 8539] read_persistent function
  • Date: Fri, 22 Apr 2005 11:59:46 -0700 (PDT)

http://bugs.sourcemage.org/show_bug.cgi?id=8539





------- Additional Comments From seth AT tautology.org 2005-04-22 11:59 -------
I would like to make a change to gcc that would most make sense asked
once: where to expect the linker, in /lib or /lib64, but gcc is split.
Granted, I can't make this change using this API piece until much later
and perhaps it makes more sense as a section-level persistent variable
if that's an idea worth pursuing, but if we didn't use the current
spell, the use of this API piece would be virtually useless and
bug-prone.

If I said I want the linker in lib for amd64 for gcc, g++ could easily
check to see what the previous gcc had set, but only if the previous gcc
had shared itself. If somebody casts g++ much later than gcc on a new
setup, it would error with "you don't have access to this variable" or
something like that and debugging would be a pain.

In my situation I think I'll just check for what linker the gcc binary
was created under (which I believe will be the correct location because
of the bootstrapping, but I'll have to test), put that in as a
section-level function, and then use that to determine what later casts
of gcc split spells will do.

I'm also not sure what the semantics of this function covers: does it
cover what the spell is intended to build as (cast has been configured
but the spell hasn't been hit in the queue yet) or what the spell built
as. The former is clearly more complicated than the latter.


--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




Archive powered by MHonArc 2.6.24.

Top of Page