Opened 8 years ago

Closed 4 years ago

#10572 closed enhancement (fixed)

compiler/binutils wrapper

Reported by: vbraun Owned by: GeorgSWeber
Priority: major Milestone: sage-6.4
Component: build Keywords: compiler gcc wrapper rpath spkg
Cc: drkirkby, jdemeyer, wjp, burcin, jpflori, tscrim Merged in:
Authors: Volker Braun, Jean-Pierre Flori Reviewers: Jean-Pierre Flori
Report Upstream: N/A Work issues:
Branch: 1df9ecd (Commits) Commit: 1df9ecd34079780609a95aa0b79168ed376d83da
Dependencies: Stopgaps:

Description (last modified by jpflori)

This ticket implements a wrapper for the compiler that lets us rewrite compiler options on the fly. The goal is to fix:

  1. Clashes between system and Sage's libraries due to LD_LIBRARY_PATH abuse.
  2. Relocation issues, i.e., "dead" (hard-coded) RPATHs in binaries (shared libraries and executables) created by Sage, upon moving the installation (which includes installing a pre-built / binary distribution).
  3. Broken compiler versions / tool chains; work around by messing with (e.g.) optimization flags, depending on the present compiler and its known issues.

The wrapper is implemented in pure C++ and does not depend on any Sage component. At the moment it only wraps gcc and does not do anything for other compilers.

Code repository https://bitbucket.org/vbraun/compilerwrapper

Use tarball at:

Attachments (8)

install (10.5 KB) - added by vbraun 8 years ago.
spkg/install with the wrapper spkg added
deps (22.2 KB) - added by vbraun 8 years ago.
spkg/standard/deps with the added gcc wrapper spkg
gccwrapper-install.patch (271 bytes) - added by vbraun 8 years ago.
diff for spkg/install
gccwrapper-deps.patch (1.2 KB) - added by vbraun 8 years ago.
diff for spkg/standard/deps
trac_10572_gccwrapper_root.patch (1.7 KB) - added by vbraun 8 years ago.
Patch to SAGE_ROOT repo (use only this patch)
trac_10572_compilerwrapper_root.patch (1.4 KB) - added by vbraun 6 years ago.
Updated patch
path.patch (2.1 KB) - added by jpflori 6 years ago.
PATH
trac_10572-sage_orig_path.patch (1.0 KB) - added by jpflori 5 years ago.
Cygwin path patch

Download all attachments as: .zip

Change History (82)

comment:1 Changed 8 years ago by vbraun

  • Cc drkirkby jdemeyer added
  • Description modified (diff)

comment:2 Changed 8 years ago by wjp

  • Cc wjp added

Changed 8 years ago by vbraun

spkg/install with the wrapper spkg added

Changed 8 years ago by vbraun

spkg/standard/deps with the added gcc wrapper spkg

Changed 8 years ago by vbraun

diff for spkg/install

Changed 8 years ago by vbraun

diff for spkg/standard/deps

comment:3 Changed 8 years ago by vbraun

  • Description modified (diff)
  • Status changed from new to needs_review

comment:4 Changed 8 years ago by jdemeyer

Volker, what's your opinion on ulimiting the memory/CPU time of gcc just in case we are running a broken compiler which either uses infinite memory or runs forever.

comment:5 Changed 8 years ago by vbraun

In principle we could add limits, but then its hard to say precisely what they ought to be. I've seen gcc use >1gb of ram and take quite a long time and still produce the correct output. We could use something like (total available ram)/(#parallel makes)-256MB but then thats hard to implement and assumes that all parallel makes use the same amount of ram. And detecting the overall amount of ram is again very system-dependent. I think that GCC hanging and/or eating all memory is a rather rare failure mode for gcc, so at this point we shouldn't spend that much effort on it.

comment:6 Changed 8 years ago by jdemeyer

  • Status changed from needs_review to needs_work

It seems that pynac no longer compiles properly with the new version of your wrapper (it worked with some older version), see http://sage.math.washington.edu/home/jdemeyer/release/sage-4.6.2.test0/pynac-0.2.1.log.

Just try sage -f pynac-0.2.1 and see whether you can reproduce this problem.

comment:7 Changed 8 years ago by vbraun

Fixed by the new spkg (same location, make sure to delete $SAGE_ROOT/spkg/optional/gccwrapper-1.0.spkg if you reinstall). I recompiled all spkgs (by erasing $SAGE_ROOT/spkg/installed/* without errors.

Turns out that configure calls gcc with some invalid options to figure out the version, and then expects a certain kind of error. I changed the wrapper to pass a single argument gcc -option directly through.

comment:8 Changed 8 years ago by jdemeyer

  • Keywords gccwrapper spkg added
  • Status changed from needs_work to needs_review

With the latest, I do indeed manage to compile Sage on sage.math.washington.edu. I plan to test it on the buildbot one of the next days.

comment:9 Changed 8 years ago by wjp

How would this behave if you make a binary distribution of sage, and then move that to another system with gcc installed in a different location? Would (for example) loading cython files still work through the wrapper then?

comment:10 Changed 8 years ago by jdemeyer

  • Status changed from needs_review to needs_work

needs_work given the buildbot tests.

comment:11 Changed 8 years ago by vbraun

Willem: A binary distribution should be compiled with the distribution's compiler, so we don't necessarily have to do anything as the compiler ought to be in the same place. But its probably better to either recompile the gcc wrapper on the new system or, if that fails, deactivate it ("$SAGE_LOCAL/bin/wrapper off"). We can work this out in a followup ticket where we also remove the LD_LIBRARY_PATH hacks.

Jeroen: I've updated the spkg to fix compilation on OSX. Turns out the updated ATLAS build script tripped over the wrapper on OSX. I guess I should have seen that coming as I wrote that script, but oh well... Investigating Solaris now.

comment:12 Changed 8 years ago by vbraun

The Solaris linker accepts -R but not -rpath, groan. The updated gccwrapper spkg fixes this. Compile proceeds past the previous error, but due to the amazing slowness it won't finish anytime soon... :-)

comment:13 Changed 8 years ago by vbraun

Built successfully on t2!

comment:14 Changed 8 years ago by drkirkby

I think this is a particularly bad idea. Also be aware that whilst Sage has only ever been built with gcc, there are advantages in building it with the Sun compiler. In fact, in the case of R, it will be necessary on Solaris x86 to build that component with the Sun compiler for a 64-bit build. The R manual states R has never been built 64-bit on Solaris x86 with the GNU compiler.

What happens if the compiler is not gcc?

So please don't go making assumptions about compilers and linkers. Bear in mind Solaris system may have gcc configured to use either the GNU or Sun linker.

This whole idea of the ticket gets a -1 from me. It will make further porting efforts more difficult.

Dave

comment:15 Changed 8 years ago by drkirkby

I just see that the documentation say

"The cc wrapper actually calls gcc. This should already be the case as cc just installs as symlink cc -> gcc. But sometimes this link is dropped in manual gcc installs."

How about when gcc and cc and entirely different programs?

drkirkby@hawk:~$ cc
usage: cc [ options] files.  Use 'cc -flags' for details
drkirkby@hawk:~$ gcc
gcc: no input files
drkirkby@hawk:~$ 

Seriously, I would drop the whole idea.

Sorry I did not pick up on this ticket earlier. My dad died in mid January, so Sage has not been high on my priority list.

Dave

comment:16 Changed 8 years ago by jdemeyer

I think your negative attitude towards this ticket is probably a misunderstanding. I believe that the gccwrapper does not only work with gcc (the name compiler-wrapper might have been a better choice).

I think this can actually make porting a lot easier instead of harder. Because compiler-specific issues can be dealt with just once, namely in the gccwrapper. For example, most of the SAGE64-stuff could be handled by the wrapper, instead of the individual spkgs.

comment:17 Changed 8 years ago by jdemeyer

A completely different issue: since there isn't really an upstream for this spkg, I think it would make a lot of sense to put the whole src/ directory under revision control. I believe this has been done also for genus2reduction which doesn't have an upstream either.

comment:18 Changed 8 years ago by jdemeyer

Sorry Dave, I spoke too soon. Reading the source I do indeed see

  switch (prog) {
  case WRAPPED_GCC:        cmd = path(GCC_PATH_PREFIX)/"gcc";  break;
  case WRAPPED_CC:         cmd = path(GCC_PATH_PREFIX)/"gcc";  break;
  case WRAPPED_C99:        cmd = path(GCC_PATH_PREFIX)/"c99";  break;
  case WRAPPED_C89:        cmd = path(GCC_PATH_PREFIX)/"c89";  break;
  case WRAPPED_CPLUSPLUS:  cmd = path(GCC_PATH_PREFIX)/"c++";  break;
  case WRAPPED_GPLUSPLUS:  cmd = path(GCC_PATH_PREFIX)/"g++";  break;
  case WRAPPED_LD:         cmd = path(LD_PATH_PREFIX)/"ld";    break;
  case WRAPPED_WRAPPER:
  default:
    assert(false); return;
  }

with a hardcoded gcc in there.

I would use the autoconf-detected binaries for the compiler/linker there. But the idea of this ticket certainly gets a +1 from me.

comment:19 Changed 8 years ago by vbraun

You can simply not use the wrapper if you have any other compiler, and rpath/runpaths will remain broken as they are right now. In particular, any distribution that wants to include Sage would just use their own compiler without wrapper and install libraries in the library search path. And upgrade their compiler if it dies while compiling pari :-)

I wrote autoconf macros to detect the linker used (Gnu/Sun?/OSX), so it should work with either linker. Anything else is a bug that I'll be happy to fix.

In principle, other compilers could be supported by their own compiler wrapper. Since we currently can't use any other compiler, I haven't written any other wrapper. If the compiler/linker provides another way to set the rpath, then we don't need any wrapper of course.

Another possibility is to write a translator from the gcc compiler switches to some 3rd party compiler, and then use that other compiler without Sage knowing about it. I haven't tried this, but it might be easier than fixing all spkgs on rare hardware.

The point of translating cc->gcc is that this symlink was missing on one of the itanium machines on skynet (iras). I fixed that bug and checked that no other component of Sage tries to call cc. While thats clearly a broken gcc install, it arguably doesn't hurt to override it in the wrapper if you know that you are using gcc. Though you make a good case for not overriding cc at all, since it might be the Solaris compiler. One question is whether we can rely on the names of the compiler executables to be all different, or whether there are conflicts. I know that gcc and icc don't clash, but Solaris' cc is bound to be the same name as some other compiler?

comment:20 Changed 8 years ago by drkirkby

There's a fair amount of Sage which will build with the Sun compiler, and I hope to increase that, so please don't do anything that will screw up if cc is not gcc.

Note there are two shell scripts $SAGE_LOCAL/bin/testcc.sh and $SAGE_LOCAL/bin/testcxx.sh which actually check what the compilers are, and does this withougt making assumptions based on their name. They compile a simple program (written inline) which checks what preprocessor variables are defined.

I certainly would not assume a failure to link cc to gcc was a bug on any machine.

With my fathers funeral in a few days, I'm not really in the mode for detailed analysis of this, but my initial feelings are I would leave well alone.

Dave

comment:21 Changed 8 years ago by jdemeyer

Volker: what do you think of my suggestion, to use the autoconf-detected C/C++ compiler instead of a hardcoded gcc? The idea of having hardcoded compiler names gets -1 from me.

comment:22 Changed 8 years ago by vbraun

  • Description modified (diff)
  • Keywords compiler added; gccwrapper removed
  • Milestone changed from sage-4.6.2 to sage-4.7
  • Status changed from needs_work to needs_review
  • Summary changed from gcc/binutils wrapper to compiler/binutils wrapper

I've renamed it to "compilerwrapper" to be more inclusive. Now it only installs the symlinks / translates options if the wrapper was built with gcc (and hence wraps gcc). If we ever add support for another compiler, it would then simply install its own (different) set of symlinks. I built the compilerwrapper spkg on mark/skynet with Sun Studio by setting CC=cc and CXX=CC and it works as expected (i.e. wraps nothing).

Changed 8 years ago by vbraun

Patch to SAGE_ROOT repo (use only this patch)

comment:23 Changed 8 years ago by vbraun

  • Description modified (diff)

comment:24 Changed 8 years ago by fbissey

I have to say I am very supportive of the idea of using rpath. Shouldn't we also have a patch to sage_scripts to eliminate (or reduce if not possible to completely eliminate) LD_LIBRARY_PATH in sage-env? After all, that's the goal here.

comment:25 follow-up: Changed 8 years ago by vbraun

I'm still trying to solve one issue with the rpaths. The problem is that Sage does not distinguish build preparation (configure) from the actual build. If we set relative rpaths, then configure requires LD_LIBRARY_PATH set because the configure scripts will build and execute binaries in random directories in order to test prerequisites. If we had separate prepare/build phases, then we could run configure with absolute rpaths and then switch to relative rpaths for the final build.

The problem with LD_LIBRARY_PATH is, of course, that sometimes it screws up parts of the toolchain. We had that with GMP/MPIR before, and now PPL.

comment:26 Changed 8 years ago by fbissey

And someone had a problem building doc the other day because system gd was masked by sage's gd. There was a problem with building ecl which was fixed as a colateral of another problem. The list will only grow.

comment:27 Changed 8 years ago by burcin

  • Cc burcin added

comment:28 in reply to: ↑ 25 Changed 8 years ago by leif

Replying to vbraun:

The problem with LD_LIBRARY_PATH is, of course, that sometimes it screws up parts of the toolchain. We had that with GMP/MPIR before, and now PPL.

Simple solution: Rename Sage's libraries, or put critical ones (like GMP, MPFR, MPC, PPL etc., also readline on some systems) into a different directory.

comment:29 Changed 8 years ago by vbraun

Leif, while you are at it rewriting all spkg's to work with the renamed libraries, could you also convert the custom hacked build scripts to autotools? ;-)

comment:30 Changed 7 years ago by gostrc

I believe http://trac.sagemath.org/sage_trac/ticket/11391 is related to this issue. Has there been any progress on this issue? because currently sage 4.8 is unable to compile on my system due to ticket #11391.

Last edited 6 years ago by leif (previous) (diff)

comment:31 Changed 6 years ago by vbraun

  • Description modified (diff)

Changed 6 years ago by vbraun

Updated patch

comment:32 Changed 6 years ago by vbraun

Ok, maybe a new attempt is in order.

I'll try to be more gradual. For now, keep LD_LIBRARY_PATH but use the compilerwrapper to rewrite rpaths. I added the feature to overwrite LD_LIBRARY_PATH with SAGE_OLD_LD_LIBRARY_PATH before calling gcc/ld, so at least the nasty library version clashes in the compiler are avoided.

We need to figure out what to do if sage builds its own gcc since only one gcc can live in $SAGE_LOCAL/bin. I would be in favor of compiling our own gcc with some pre/postfix as $SAGE_LOCAL/bin/gcc-sage. The compilerwrapper can then easily switch between this gcc and the host one, if desired. Thoughts?

comment:33 Changed 6 years ago by leif

  • Cc jpflori added

First, change the component to "optional packages"?

Jean-Pierre might have something to say as well, since it seems on Cygwin64 clashes of (system's) GCC's DLLs with Sage's (in $SAGE_LOCAL/bin/ !) get more frequent (so I suggested to him to create wrapper scripts analogous to sage-native-execute, but also setting up / using "SAGE_ORIG_PATH", not just *LIBRARY_PATH).

(And Cygwin doesn't support RPATH at all, does it?)

comment:34 in reply to: ↑ description Changed 6 years ago by leif

Replying to vbraun:

The wrapper is implemented in pure C++ and does not depend on any Sage component. At the moment it only wraps gcc and does not do anything for other compilers.

The main problem I see is that this requires a working C++ compiler even if we (just) want to bootstrap Sage's GCC (although GCC 4.8 and later require a C++ compiler to build anyway).

comment:35 Changed 6 years ago by vbraun

I don't think we'll ever bootstrap sage without a half-way working C++ compiler. As you said, gcc is now written in C++. At least the compilerwrapper doesn't need any optimizations, so even moderately broken compilers should be fine.

Apparently Cygwin inherits the DLL hell from Windows. Not sure what we can do about it except building our own cygwin base distro.

comment:36 follow-up: Changed 6 years ago by vbraun

On second thought, it seems that PATH equals LD_LIBRARY_PATH on Cygwin. So we could just strip out Sage from $PATH before calling gcc. Would that suffice?

comment:37 Changed 6 years ago by leif

SPKG.txt needs to get updated... ;-)

IMHO also the ticket's description; there are at least two rather orthogonal problems the compiler wrapper is supposed to fix:

  1. Clashes between system and Sage's libraries.
  1. Relocation issues, i.e., "dead" (hard-coded) RPATHs in binaries (shared libraries and executables) created by Sage, upon moving the installation (which includes installing a pre-built / binary distribution).
  1. (Even more unrelated to both of the above:) Broken compiler versions / tool chains; work around by messing with (e.g.) optimization flags, depending on the present compiler and its known issues.

comment:38 follow-up: Changed 6 years ago by vbraun

  • Description modified (diff)

Leif: I don't think there is any point in making this an optional spkg. If the wrapper not installed before you compile the first dynamically-linked binary then it is useless.

Updated the description.

comment:39 in reply to: ↑ 36 ; follow-up: Changed 6 years ago by jpflori

Replying to vbraun:

On second thought, it seems that PATH equals LD_LIBRARY_PATH on Cygwin. So we could just strip out Sage from $PATH before calling gcc. Would that suffice?

On Cygwin both have some use... But mostly PATH is used in place of LD_LIBRARY_PATH indeed.

comment:40 Changed 6 years ago by jpflori

It would surely be nice to have some variable to trigger the installation of this (hopefully standard) package, just like we do for Sage's GCC, and another one to trigger its actual use (if installed). I would be quite happy to still be able to mess with my compilers and not to have something getting in the way.

comment:41 in reply to: ↑ 39 Changed 6 years ago by jpflori

Replying to jpflori:

Replying to vbraun:

On second thought, it seems that PATH equals LD_LIBRARY_PATH on Cygwin. So we could just strip out Sage from $PATH before calling gcc. Would that suffice?

On Cygwin both have some use... But mostly PATH is used in place of LD_LIBRARY_PATH indeed.

(and for the usual usage of PATH on Linux of course.)

comment:42 follow-up: Changed 6 years ago by vbraun

Once you have it installed you can user wrapper on / wrapper off to enable/disable it.

comment:43 Changed 6 years ago by vbraun

Apparently Cygwin uses LD_LIBRARY_PATH for dlopen() at runtime but not for loading shared libraries when the program starts. So its pretty much useless for us, right?

comment:44 Changed 6 years ago by jpflori

I had problems with that once because LD_LIBRARY_PATH was not set on Cygwin. I think it was when building or using the Python's ctypes module, see #14380.

comment:45 in reply to: ↑ 42 Changed 6 years ago by jpflori

Replying to vbraun:

Once you have it installed you can user wrapper on / wrapper off to enable/disable it.

That's not very practical for example to prevent its use after typing "make"

comment:46 follow-up: Changed 6 years ago by vbraun

How about if SAGE_INSTALL_GCC=no then don't install the wrapper, otherwise do install it. In particular, unset => install compiler wrapper by default, and gcc only if host gcc is too broken.

Last edited 6 years ago by vbraun (previous) (diff)

comment:47 Changed 6 years ago by jpflori

That could do the trick though I would prefer to have dedicated options like SAGE_INSTALL_WRAPPER and SAGE_USE_WRAPPER both on by default andindependent of SAGE_INSTALL_GCC.

comment:48 Changed 6 years ago by vbraun

Thats what I'm precisely trying to avoid, having millions of environment variables to configure everything under the sun is just crazyness. Its hard enough to remember whether its SAGE_INSTALL_GCC or SAGE_GCC_INSTALL. Also, whats the use case of installing gcc but not the wrapper, then we need further logic to prefix gcc if there is a wrapper and not prefix gcc if there is no wrapper. Which just means that it won't always work since nobody will test all combinations.

comment:49 follow-up: Changed 6 years ago by jpflori

It's nice to be able to test some crazy combination and having the possibility to do so by setting one or two envvars rather than hacking into the code.

And SAGE_INSTALL_GCC will not treflect what it does anymore.

For the prefixed gcc issue, just prefix it all the time and if there is no wrapper installed then create symlinks.

comment:50 in reply to: ↑ 49 ; follow-up: Changed 6 years ago by vbraun

Replying to jpflori:

It's nice to be able to test some crazy combination and having the possibility to do so by setting one or two envvars rather than hacking into the code.

I disagree, its a drain on the development process to try to support nonsensical combinations without any benefit. Some user will fall into the spike-filled traps and then complain (rightfully) why some combination of envionment variables causes everything to crash and burn.

And SAGE_INSTALL_GCC will not treflect what it does anymore.

We should have called it SAGE_INSTALL_GCC. The compilerwrapper was also originally called gccwrapper until somebody on this ticket pointed out the stupidity of it.

For the prefixed gcc issue, just prefix it all the time and if there is no wrapper installed then create symlinks.

Then, later, you install the compilerwrapper. Even later you disable the wrapper. Bang, your compiler is now gone. I'm sure this will be a crowd-pleaser.

comment:51 in reply to: ↑ 50 Changed 6 years ago by jpflori

Replying to vbraun:

Replying to jpflori:

It's nice to be able to test some crazy combination and having the possibility to do so by setting one or two envvars rather than hacking into the code.

I disagree, its a drain on the development process to try to support nonsensical combinations without any benefit. Some user will fall into the spike-filled traps and then complain (rightfully) why some combination of envionment variables causes everything to crash and burn.

And SAGE_INSTALL_GCC will not treflect what it does anymore.

We should have called it SAGE_INSTALL_GCC. The compilerwrapper was also originally called gccwrapper until somebody on this ticket pointed out the stupidity of it.

For the prefixed gcc issue, just prefix it all the time and if there is no wrapper installed then create symlinks.

Then, later, you install the compilerwrapper. Even later you disable the wrapper. Bang, your compiler is now gone. I'm sure this will be a crowd-pleaser.

Isn't that "nonsensical", cf. 38?

comment:52 in reply to: ↑ 38 Changed 6 years ago by leif

Replying to vbraun:

If the wrapper not installed before you compile the first dynamically-linked binary then it is useless.

If / when GCC builds itself, it won't get used anyway (only during initial bootstrapping).

Last edited 6 years ago by leif (previous) (diff)

comment:53 Changed 6 years ago by leif

We certainly shouldn't use the same (and established) environment variable for different and unrelated purposes.

comment:54 in reply to: ↑ 46 Changed 6 years ago by leif

Replying to vbraun:

How about if SAGE_INSTALL_GCC=no then don't install the wrapper, otherwise do install it. In particular, unset => install compiler wrapper by default, and gcc only if host gcc is too broken.

One use case of the compiler wrapper is to work around (system!) compiler bugs, so unconditionally not installing it if SAGE_INSTALL_GCC=no doesn't make much sense, at least if it's used to prevent installing Sage's GCC (which is the current and intended meaning).

comment:55 follow-up: Changed 6 years ago by vbraun

Its true that gcc won't build itself with the wrapper, but then we build gcc right at the beginning before we build any troublesome libraries. And the first stage doesn't need optimizations, to even moderately broken compilers should be fine.

We definitely should think about using a special case from an already existing environment variable to avoid creating too many obscure configuration options that we can never actually test. JP wants a setting so that he can play with potentially broken compilers, and setting SAGE_INSTALL_GCC=no is what you logically would want to set in this use case.

The basic fact is that only one program can be installed as $SAGE_LOCAL/bin/gcc So you don't have 4 independent choices of sage-gcc yes/no and compilerwrapper yes/no.

comment:56 in reply to: ↑ 55 ; follow-up: Changed 6 years ago by jpflori

Replying to vbraun:

Its true that gcc won't build itself with the wrapper, but then we build gcc right at the beginning before we build any troublesome libraries. And the first stage doesn't need optimizations, to even moderately broken compilers should be fine.

You have to build the wrapper at the very beginning of the build process to be sure to avoid issues on Cygwin.

We definitely should think about using a special case from an already existing environment variable to avoid creating too many obscure configuration options that we can never actually test. JP wants a setting so that he can play with potentially broken compilers, and setting SAGE_INSTALL_GCC=no is what you logically would want to set in this use case.

The basic fact is that only one program can be installed as $SAGE_LOCAL/bin/gcc So you don't have 4 independent choices of sage-gcc yes/no and compilerwrapper yes/no.

comment:57 in reply to: ↑ 56 Changed 6 years ago by vbraun

Replying to jpflori:

You have to build the wrapper at the very beginning of the build process to be sure to avoid issues on Cygwin.

Agreed. What I'm trying to say is: Despite the compiler wrapper being installed first, gcc will build itself internally without wrapper. But that is fine since gcc knows what it is doing (and we haven't thrown any bricks in its way yet via LD_LIBRARY_PATH)

comment:58 Changed 6 years ago by jpflori

I've attached a patch to fix a little typo and take care of PATH as well, feel free to integrate it upstream.

Changed 6 years ago by jpflori

PATH

comment:59 Changed 6 years ago by vbraun

Done, added to repo & spkg in the ticket.

comment:60 Changed 6 years ago by jpflori

Thanks.

In fact we also need to patch the Sage repo to define SAGE_ORIG_PATH there IIRC. Unfortunately I don't have access to the disk where I developped this part right now. The patch should be up later today.

comment:61 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

Changed 5 years ago by jpflori

Cygwin path patch

comment:62 Changed 5 years ago by jpflori

Finally added a needed patch for Cygwin which removes Sage stuff from PATH.

comment:63 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:64 Changed 5 years ago by tscrim

  • Cc tscrim added

comment:65 Changed 5 years ago by jpflori

  • Authors changed from Volker Braun to Volker Braun, Jean-Pierre Flori
  • Branch set to u/jpflori/ticket/10572
  • Commit set to f9f826ab1265d843db7d48f74dec831928ecdba8
  • Description modified (diff)
  • Reviewers set to Jean-Pierre Flori

I've gitified the ticket without making it a standard package (basically, Volker's hg patch). I think should definitely make it optional at least.

And I give positive review to what Volker done, except for maybe not making the package standard, at least now...


New commits:

f9f826aGitify compiler/binutils wrapper.

comment:66 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:67 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:68 Changed 4 years ago by git

  • Commit changed from f9f826ab1265d843db7d48f74dec831928ecdba8 to 1df9ecd34079780609a95aa0b79168ed376d83da

Branch pushed to git repo; I updated commit sha1. New commits:

9588786Merge remote-tracking branch 'trac/develop' into ticket/10572
1df9ecdTrivial scripts update for compilerwrapper.

comment:69 Changed 4 years ago by jpflori

Volker: Any thoughts on this ticket?

I'll be tempted to positively review it as I've been using it quite often and would definitely need it if I use some of my time for the Cygwin's ports for the h2020 thing.

comment:70 Changed 4 years ago by jpflori

  • Status changed from needs_review to positive_review

This still is useful for me and looks fine. lgtm

comment:71 follow-up: Changed 4 years ago by vbraun

I think its good to have it as an optional/experimental package, let's see if it turns out to be useful.

The SPKG.txt is incorrect in that the upstream repo is git now, but that is trivial.

I don't think its the final answer to our LD_LIBRARY_PATH / relocation woes, I'm working with the hashdist developers on a bullet-proof solution.

comment:72 in reply to: ↑ 71 Changed 4 years ago by jpflori

Replying to vbraun:

I think its good to have it as an optional/experimental package, let's see if it turns out to be useful.

The SPKG.txt is incorrect in that the upstream repo is git now, but that is trivial.

Is it? I actually had a look to check if you updated the code but did not even notice it was not bitbucket anymore... or just ended up on the old bitbucket repo, who knows.

I don't think its the final answer to our LD_LIBRARY_PATH / relocation woes, I'm working with the hashdist developers on a bullet-proof solution.

Sure, but at least it lets Sage build (quite) easily on platforms where PATH/LD_LIBRARY_PATH will always be a mess like Windows.

comment:73 Changed 4 years ago by vbraun

It is still on bitbucket, but bitbucket supports both hg and git nowadays...

comment:74 Changed 4 years ago by vbraun

  • Branch changed from u/jpflori/ticket/10572 to 1df9ecd34079780609a95aa0b79168ed376d83da
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.