#5254: [with patch, needs review] Mac app bundle: check for relocation at
startup
since the bundle version does not trigger the move check
--------------------------+-------------------------------------------------
Reporter: mabshoff | Owner: mabshoff
Type: defect | Status: new
Priority: critical | Milestone: sage-3.3
Component: distribution | Resolution:
Keywords: |
--------------------------+-------------------------------------------------
Comment (by mabshoff):
Replying to [comment:1 GeorgSWeber]:
> Hi Michael,
Hi Georg,
> I couldn't trigger the Maxima failure (don't know why),
The original poster in that thread had some other issues, too, but I could
certainly hit it when I used a dmg build on another box where my home
directory was different. If the original Sage build is still in place it
should "just work" since the old install is being picked up.
> but I could see that the Sage app bundle's "/local/lib/sage-current-
location.txt" wasn't updated as it should. The new script I attached does
fix this and should handle environmental settings cleaner on a broader
scale. I didn't know where you want me to put it (certainly not inside
some "tar.gz"), so I uploaded it plain as-is.
Cool.
> You said in sage-devel (Google thread) that you had a fix for dir names
with spaces -- I don't see where, but anyway that fix of yours should
apply as before.
The fix isn't up yet and it is mostly in the "I think I know how to fix
this stage", so no tested code yet. Notice that at #5261 there are all the
other issues I would like to sort out.
> One important thing I noted: The README.txt in the .dmg dates from Sage
2.9.2 and should definiteley either be updated, or killed. Probably you
have to adjust sage-sdist and sage-bdist a bit to stop remnants of this
(e.g. "$SAGE_ROOT/sage-README-osx.txt") from lurking around.
Ok, please open a critical ticket against 3.3 to update the OSX readme.
> One other thing:
>
> +1 to your idea to name the app bundle "Sage.x.y.z" instead of "Sage".
What do you think of putting in the name also the dependency "Intel vs.
PPC" resp. "32Bit vs. 64Bit"? (It's not a "universal binary" we deliver,
do we?)
Yep, please add that as a comment to #5261 so it doesn't get lost. We
don't do universal since there are issues with the build all over the
place, i.e. gmp doesn't support it. MPIR might at some point in the
future, but that leaves other issues to be fixed.
I can imagine to fix this in three ways:
* Make everything build universal by adjusting and fixing all build
systems in Sage's spkg (giant amount of work)
* use lipo to join all binaries and libraries after building them locally
(I have played with this)
* add a wrapper script that starts the appropriate sage since we could
have sage-x86, sage-x86-64, sage-ppc and sage-ppc64 sitting inside the DMG
all in parallel. This causes its own set of issues (how do you upgrade
something like that? Will people download the 1.2GB?), but if there is
interest given that we now have the DMG + App bundle in place this would
be the quickest way to get a universal binary going (Once we have fixed
the last couple pesky bugs for 64 bit OSX support :)
Anyway, if you feel this point warrants discussion and/or interest please
open a new thread on sage-devel.
> Cheers, gsw
Thanks for fixing this, I am *swamped* :)
Cheers,
Michael
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5254#comment:2>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
