Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#11084 closed defect (fixed)

Singular 3-1-1-4.p6 fails to build with gcc 4.6.0.

Reported by: drkirkby Owned by: GeorgSWeber
Priority: blocker Milestone: sage-4.7
Component: build Keywords:
Cc: Merged in: sage-4.7.rc0
Authors: David Kirkby, Jeroen Demeyer Reviewers: Alexander Dreyer, Jeroen Demeyer
Report Upstream: None of the above - read trac for reasoning. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by drkirkby)

After trying to build Sage with gcc 4.6.0 on OpenSolaris, I find it fails when building Singular, despite Singular (and all of Sage) builds with gcc-4.5.0. The same issue occurs on various other systems.

In file included from ../kernel/ring.h:13:0,
                 from ../kernel/ideals.h:11,
                 from ipshell.h:12,
                 from tesths.cc:20:
../kernel/polys-impl.h:177:0: warning: "pPolyAssumeReturn" redefined [enabled by default]
../kernel/polys-impl.h:176:0: note: this is the location of the previous definition
mpsr_Tok.cc: In function 'void mpsr_ttGen()':
mpsr_Tok.cc:551:29: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
Undefined			first referenced
 symbol  			    in file
uniFactorizer(CanonicalForm const&, Variable const&, bool const&) /export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/local/lib/libsingcf.a(facFqFactorize.o)
ld: fatal: symbol referencing errors. No output written to gentable1
collect2: ld returned 1 exit status
make[4]: *** [iparith.inc] Error 1
Undefined			first referenced
 symbol  			    in file
uniFactorizer(CanonicalForm const&, Variable const&, bool const&) /export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/local/lib/libsingcf.a(facFqFactorize.o)
ld: fatal: symbol referencing errors. No output written to gentable2
collect2: ld returned 1 exit status
make[4]: *** [mpsr_Tok.inc] Error 1
make[4]: Target `install' not remade because of errors.
make[4]: Leaving directory `/export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/spkg/build/singular-3-1-1-4.p4/src/Singular'
make[3]: *** [install] Error 1
make[3]: Leaving directory `/export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/spkg/build/singular-3-1-1-4.p4/src'
make[2]: *** [/export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/local/bin/Singular-3-1-1] Error 2
make[2]: Leaving directory `/export/home/drkirkby/sage-new-gcc/sage-4.7.alpha2/spkg/build/singular-3-1-1-4.p4/src'
Unable to build Singular.

real	3m22.783s
user	6m14.242s
sys	0m22.671s
sage: An error occurred while installing singular-3-1-1-4.p4

A full log is attached.

A revised package, which reduces the optimisation level, which at least allows this to build on OpenSolaris may be found at

New spkg, based on #9497: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-1-4.p8.spkg

This needs further testing on other platforms.

Other problems related to gcc 4.6.0 can be found on #11216

Attachments (3)

singular-3-1-1-4.p4.log (350.5 KB) - added by drkirkby 10 years ago.
Failed build of Singular 3-1-1-4.p4 as part of Sage 4.7.alpha2 on a Sun Ultra 27 running OpenSolaris? 06/2009
11084-Reduce_optimisation_level_in_Singular.patch (2.3 KB) - added by drkirkby 10 years ago.
Reduces optimisation. For review purposes only.
singular-3-1-1-4.p6-p8.diff (4.4 KB) - added by jdemeyer 10 years ago.
Diff for the singular spkg, for reviewing only

Download all attachments as: .zip

Change History (50)

Changed 10 years ago by drkirkby

Failed build of Singular 3-1-1-4.p4 as part of Sage 4.7.alpha2 on a Sun Ultra 27 running OpenSolaris? 06/2009

comment:1 Changed 10 years ago by drkirkby

  • Component changed from build to solaris
  • Owner changed from GeorgSWeber to drkirkby
  • Type changed from PLEASE CHANGE to defect

I've set the component to "solaris" as that is the only confirmed system on which this fails to build. Can someone change the component to "build" if this fails on Linux or OS X.

Dave

comment:2 Changed 10 years ago by vbraun

  • Component changed from solaris to build
  • Owner changed from drkirkby to GeorgSWeber

Also fails on Fedora 15 alpha which uses gcc-4.6

comment:3 Changed 10 years ago by burcin

  • Report Upstream changed from Not yet reported upstream; Will do shortly. to Reported upstream. Little or no feedback.

comment:4 Changed 10 years ago by AlexanderDreyer

Maybe a demangling issue? See my comment here: http://groups.google.com/group/libsingular-devel/browse_thread/thread/508c352214392315?hl=en My best,

Alexander

comment:5 follow-up: Changed 10 years ago by vbraun

On a related note, our goal should probably be to update Singular to the newest upstream. IIRC I was able to build the latest upstream with gcc-4.6, but only the standalone singular. I was unable to build libsingular, though.

comment:6 in reply to: ↑ 5 Changed 10 years ago by drkirkby

Replying to vbraun:

On a related note, our goal should probably be to update Singular to the newest upstream. IIRC I was able to build the latest upstream with gcc-4.6, but only the standalone singular. I was unable to build libsingular, though.

We should really try to get this solved before the 24th May 2011, since Fedora 15 is released then, and Sage will fail to build on a fairly popular linux distribution.

http://fedoraproject.org/wiki/Releases/15/Schedule

comment:7 follow-up: Changed 10 years ago by AlexanderDreyer

comment:8 in reply to: ↑ 7 Changed 10 years ago by drkirkby

  • Priority changed from major to critical

Replying to AlexanderDreyer:

I reported that upstream: http://www.singular.uni-kl.de:8002/trac/ticket/332

Thank you.

Burcin has already reported it on the mailing list, but there has been no response from any developers. Having it submitted to the bug database, as you have done, can only be a good thing.

I've updated this to 'critical' as I think it's a pretty important bug to solve. Not that the priories seem to mean very much - e.g. #9739 has been opened for 8 months and has been a blocker for 5 months.

Dave

comment:9 Changed 10 years ago by drkirkby

I've reported on the singular list that the latest version still fails with gcc 4.6.0. I later tried to post this:


With gcc 4.5.0 the same version builds ok on the same computer, so it does appear to be an issue with gcc 4.6.0.

I would suggest it would be worth trying to build this with Sun Studio (which is a free download)

http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index.html

on a Linux system. The Sun (Oracle) compiler is much stricter than the GNU compilers, so will show up problems that current versions of GCC may not. It goes without saying this will not build with Sun Studio. (I tried this on a Solaris system, but you should get the same on a Linux machine).

Dave


but it was rejected as it was thought to be spam. I guess it contains a link, but I don't think it's too much like spam.

Dave

comment:10 follow-up: Changed 10 years ago by AlexanderDreyer

In principle not a bad idea, but due to some implementation tricks making Singular to compile von Solaris studio would be a full port.

As I pointed out on libSingular-devel, there is a demangling issue for some C++ function names on gcc 4.6. (Maybe tied to optimization options.)

comment:11 in reply to: ↑ 10 ; follow-up: Changed 10 years ago by drkirkby

Replying to AlexanderDreyer:

In principle not a bad idea, but due to some implementation tricks making Singular to compile von Solaris studio would be a full port.

It suspect it would only need to be converted to standard C and/and C++.

As I pointed out on libSingular-devel, there is a demangling issue for some C++ function names on gcc 4.6. (Maybe tied to optimization options.)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 10 years ago by AlexanderDreyer

It suspect it would only need to be converted to standard C and/and C++.

Indeed, but this is ot done overnight.

And: it won't fix this bug here. The lines of source code, that cause trouble are standard, this problem seems to accur during the compiler's optimization.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 10 years ago by drkirkby

Replying to AlexanderDreyer:

It suspect it would only need to be converted to standard C and/and C++.

Indeed, but this is ot done overnight.

True.

And: it won't fix this bug here. The lines of source code, that cause trouble are standard, this problem seems to accur during the compiler's optimization.

IIRC, Singular uses -O3, which is a bit risky. Perhaps the optimiation level can be dropped to -O2, which is much safer. If I'm mistaken, and it is -O2, then I don't have any suggestions.

comment:14 Changed 10 years ago by drkirkby

  • Description modified (diff)
  • Summary changed from Singular 3-1-1-4.p4 fails to build with gcc 4.6.0 on OpenSolaris. to Singular 3-1-1-4.p4 fails to build with gcc 4.6.0.

I've removed the "on OpenSolaris" from the title, as this is not specific to that platform, so the ticket title should reflect this.

comment:15 in reply to: ↑ 13 Changed 10 years ago by drkirkby

  • Authors set to David Kirkby
  • Status changed from new to needs_info
  • Work issues set to Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0.

Replying to drkirkby:

IIRC, Singular uses -O3, which is a bit risky. Perhaps the optimiation level can be dropped to -O2, which is much safer.

Reduced optimisation probably solves the problem. Changing to -O2 allows Singular to build with gcc 4.6.0 on at least OpenSolaris, but I have not yet verified if the doctests pass. I will start a fresh build of Sage, then run all the long doctests.

If one looks in spkg-install, one find that compiling at -O3 has caused problems in the past, so on one platform -O0 is used.

So I suspect this is solved. I've placed a package at

http://boxen.math.washington.edu/home/kirkby/patches/singular-3-1-1-4.p5.spkg

We will need to verify if this builds and passes the tests properly on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0 before I will mark this for review. For now I'm setting to "needs info"

Dave

PS.

I reported about an hour ago to the Singular developers that I believe they are using reserved words in Singular too (http://www.singular.uni-kl.de:8002/trac/ticket/333).

comment:16 Changed 10 years ago by drkirkby

  • Description modified (diff)

Changed 10 years ago by drkirkby

Reduces optimisation. For review purposes only.

comment:17 follow-up: Changed 10 years ago by AlexanderDreyer

  • Report Upstream changed from Reported upstream. Little or no feedback. to None of the above - read trac for reasoning.
  • Status changed from needs_info to needs_review

This seems to be the right solution: looking at Singular's original settings I just realized that most of Singular is not compiled with -O3 already. (This is the reason why plain Singular doesn't fail to build. The overall optimization level is set in the spkg, so its merely a bug of the package.) Maybe a better solution would be not to *increase* optimization and stay with the original settings.

Building/installing of the skpg is fine for me. Let's see whether the tests succeed.

comment:18 Changed 10 years ago by AlexanderDreyer

  • Reviewers set to AlexanderDreyer
  • Status changed from needs_review to positive_review

The tests suceeded, so positive review.

comment:19 in reply to: ↑ 17 ; follow-up: Changed 10 years ago by jdemeyer

Replying to AlexanderDreyer:

This seems to be the right solution

I completely disagree. Dropping the optimization is at best a workaround. IMHO it can never be "the right solution". It means that either the compiler or the code has a bug. Maybe dropping the optimization to -O2 covers up any issues, but I think one should really investigate what the true problem is.

I am very strongly against saying to never increase the optimization level to -O3. If some later upstream version has fixed this problem, we should increase the optimization level back to -O3.

comment:20 in reply to: ↑ 19 ; follow-up: Changed 10 years ago by drkirkby

Replying to jdemeyer:

Replying to AlexanderDreyer:

This seems to be the right solution

I completely disagree. Dropping the optimization is at best a workaround.

Agreed.

IMHO it can never be "the right solution". It means that either the compiler or the code has a bug. Maybe dropping the optimization to -O2 covers up any issues, but I think one should really investigate what the true problem is.

Well, a lot of the code in Sage is very difficult to navigate. Sage developers did not write it. Much is incomprehensible. Most gives a lot of compiler warnings. Sorting out if a gcc bug or a bug in the code is difficult. Then if it is a bug in the code, finding where is often very very difficult. One could spend ages on it.

I am very strongly against saying to never increase the optimization level to -O3. If some later upstream version has fixed this problem, we should increase the optimization level back to -O3.

Given this code has caused many issues on many platforms with optimization issues, then I think not increasing it is worthwhile. It should also be realised that -O3 does not necessarily run faster than -O2. The higher optimization level invokes more speculative optimisations, which may cause the code to run slower. See this point from a GCC developer.

http://gcc.gnu.org/ml/gcc-help/2010-07/msg00190.html


The -O3 optoin should be safe for correct code. An important difference between -O2/-O3 and -O1 is that -O2 and -O3 enable strict aliasing and strict overflow. Those options provide better optimization for correct code, but are far more likely to cause unexpected code generation for incorrect code. See the -fstrict-aliasing and -fstrict-overflow options.

The main difference between -O3 and -O2 is that -O3 enables more speculative optimizations. These should not miscompile your code, but they may cause your program to run more slowly.


So in summary

  • The upstream developers use -O2
  • Both -O2 and -O3 can cause problems with bad code.
  • -O3 can be slower than -O2
  • Previous attempts to use -O3 have caused problems on numerous platforms
    • Fedora
    • OpenSUSE on Itanium
    • gcc on any platform
  • Just for good measure, the code can't be compiled with the Sun compiler, as it has hard-coded uses gcc-specific flags, so we can't even get a second opinion about doggy lines of code.
  • Finding whether it's a gcc bug or a bug in Singular would take quite a bit of effort, and IMHO would be better spent elsewhere.

There seems to be little appetite among the Sage community for investigating (and possibly fixing) the thousands of compiler warnings - some of which look potentially serious to me. To me at least, permitting -O3 on code which has caused numerous issues in the past is unwise.

Dave

comment:21 in reply to: ↑ 20 Changed 10 years ago by AlexanderDreyer

This seems to be the right solution

I completely disagree. Dropping the optimization is at best a workaround.

Of course, I meant a solution for now (let's call this workaround).

I also wanted to point out, that upstream Singular uses different optimization levels for different parts of the system. Some parts are actually compiled with -O3 (not the one which causes problems). So I had wanted to suggest, that the spkg should not increase the optimization level over the levels, respectively, intended by the upstream developers. (It's known that -O3 sometimes yields performance issues.)

For some reason the Sage-package forces a unified optimization setting for all parts of Singular. Avoiding this would be the best of course.

BTW: I'm pretty sure, the issue is a compiler bug: It complies without problems, but the linker looks for a (C++) function, whose mangled name doesn't fit what the linker expects.

comment:22 Changed 10 years ago by jdemeyer

Some administrative comment: there is already a new Singular spkg at #9497 (which will probably be merged in sage-4.7.alpha5), so you should rebase this ticket to the spkg at #9497.

comment:23 follow-up: Changed 10 years ago by jdemeyer

David, would you agree with the compromise to weaken your wording about the -O3 issue? I.e. replace "Please do not push the optimisation to -O3. This has caused too many problems." by something along the lines of "Currently, building Singular with -O3 fails using gcc 4.6.0. Therefore, we compile using -O2."

comment:24 Changed 10 years ago by vbraun

I dug around for the missing symbol a bit and the issue is in const propagation where some function should get compiled into a const and a non-const version, but apparently one of them is missing when linking everything. I'm not sure if its a compiler bug or a misuse of const-ness that causes it.

With lower optimization gcc probably doesn't emit two distinct versions of the function. So the bug should only affect whether the code compiles or not, but never give wrong results.

comment:25 Changed 10 years ago by jdemeyer

  • Status changed from positive_review to needs_work
  • Work issues changed from Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0. to Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0.; rebase to #9497

comment:26 Changed 10 years ago by jdemeyer

  • Priority changed from critical to blocker
  • Work issues changed from Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0.; rebase to #9497 to Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0.; rebase to #9497

comment:27 Changed 10 years ago by AlexanderDreyer

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

I put the merged spkg here: http://boxen.math.washington.edu/home/dreyer/spkg/singular-3-1-1-4.p7.spkg Unfortunately, somebody else will need to review it now.

comment:28 Changed 10 years ago by jdemeyer

  • Milestone changed from sage-4.7 to sage-4.7.1

comment:29 Changed 10 years ago by drkirkby

Positive review.

Is there a good reason this can't be merged into 4.7 now? Then all the gcc 4.6.0 issues will be resolved. #11159 does mention that gcc 4.6.0 will not build Sage and addresses an issue about GNU tar on Os X. But quite honestly if this is merged, and #11159 is not, then the is just a minor documentation error about GNU tar on OS X. I feel the gcc 4.6.0 issue is far more important than a minor error in the documentation. Or another ticket can be created to remove the comments about gcc 4.6.0 not building Sage.

Dave

comment:30 Changed 10 years ago by drkirkby

  • Status changed from needs_review to positive_review

comment:31 follow-up: Changed 10 years ago by jdemeyer

  • Description modified (diff)
  • Summary changed from Singular 3-1-1-4.p4 fails to build with gcc 4.6.0. to Singular 3-1-1-4.p6 fails to build with gcc 4.6.0.
  • Work issues changed from Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0.; rebase to #9497 to Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0

Are we really supposed to overwrite CFLAGS instead of appending CLFAGS when SAGE64 is set?

From spkg-install:

if [ "x$SAGE64" = xyes ]; then
    echo "Building a 64-bit version of Singular"
    CFLAGS="-O2 -g -m64 "
    CXXFLAGS="-O2 -g -m64"
    CPPFLAGS="-O2 -g -m64"
    LDFLAGS="-m64 "; export LDFLAGS
    if [ "x`uname`" = xSunOS ] ; then
      CC="$CC -m64"
      export CC
      CXX="$CXX -m64"
      export CXX
    fi
fi

comment:32 Changed 10 years ago by jdemeyer

  • Description modified (diff)
  • Status changed from positive_review to needs_work

New spkg (not overwriting of CFLAGS when SAGE64 is set): http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-1-4.p8.spkg

comment:33 Changed 10 years ago by jdemeyer

  • Status changed from needs_work to needs_review

comment:34 in reply to: ↑ 23 ; follow-up: Changed 10 years ago by drkirkby

Replying to jdemeyer:

David, would you agree with the compromise to weaken your wording about the -O3 issue? I.e. replace "Please do not push the optimisation to -O3. This has caused too many problems." by something along the lines of "Currently, building Singular with -O3 fails using gcc 4.6.0. Therefore, we compile using -O2."

I will make it less strong, but I feel it needs to be a bit stronger than just mention gcc 4.6.0.

How about

The original Singular source code builds part of Singular with -O2 and part with -O3. On several occasions Sage has forced the optimisation of the complete package to -O3, but this has caused various problems (tickets x, y, and x) either with specific compilers or on specific platforms. If you feel tempted to increase the optimiation to -O3, ask on the Singular mailing (whatever@…) list for advice and discuss in on sage-devel first. Also note that -O3 can be slower than -O2 in some instances.

Does that seem reasonable?

comment:35 in reply to: ↑ 31 ; follow-up: Changed 10 years ago by drkirkby

Replying to jdemeyer:

Are we really supposed to overwrite CFLAGS instead of appending CLFAGS when SAGE64 is set?

No, that is an error, though it is a separate issue to the subject of the ticket. But it is easy to fix.

Dave

comment:36 in reply to: ↑ 35 Changed 10 years ago by jdemeyer

Replying to drkirkby:

Replying to jdemeyer:

Are we really supposed to overwrite CFLAGS instead of appending CLFAGS when SAGE64 is set?

No, that is an error, though it is a separate issue to the subject of the ticket. But it is easy to fix.

In that case, please review my spkg http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-1-4.p8.spkg.

comment:37 in reply to: ↑ 34 ; follow-ups: Changed 10 years ago by jdemeyer

Replying to drkirkby:

Replying to jdemeyer:

David, would you agree with the compromise to weaken your wording about the -O3 issue? I.e. replace "Please do not push the optimisation to -O3. This has caused too many problems." by something along the lines of "Currently, building Singular with -O3 fails using gcc 4.6.0. Therefore, we compile using -O2."

I will make it less strong, but I feel it needs to be a bit stronger than just mention gcc 4.6.0.

How about

The original Singular source code builds part of Singular with -O2 and part with -O3. On several occasions Sage has forced the optimisation of the complete package to -O3, but this has caused various problems (tickets x, y, and x) either with specific compilers or on specific platforms. If you feel tempted to increase the optimiation to -O3, ask on the Singular mailing (whatever@…) list for advice and discuss in on sage-devel first. Also note that -O3 can be slower than -O2 in some instances.

Does that seem reasonable?

It's not unreasonable, but a lot of fuzz about nothing. What do you think of the following comment from my spkg:

# By default, parts of Singular are compiled with -O2 and parts
# with -O3.  If we do set any CFLAGS, this always overrides the
# default CFLAGS set by upstream.  In order to be compatible, we
# set the optimization to -O2.

I think it's most important to explain why we use -O2. Since there is a good reason to use -O2, of course one should not randomly increase the -O level.

comment:38 in reply to: ↑ 37 Changed 10 years ago by drkirkby

Replying to jdemeyer:

I think it's most important to explain why we use -O2. Since there is a good reason to use -O2, of course one should not randomly increase the -O level.

But my point is that this package does appear to have had the optimisation randomly increased several times, which for Singular is a particularly bad idea, as it has caused numerous problems. Your wording gives no hint of the dangers. We are not being compatible for the sake of it - we are doing so as it is dangerous to do otherwise.

Dave

comment:39 in reply to: ↑ 37 Changed 10 years ago by jdemeyer

How about adding a phrase like this:

# By default, parts of Singular are compiled with -O2 and parts
# with -O3.  If we do set any CFLAGS, this always overrides the
# default CFLAGS set by upstream.  In order to be compatible, we
# set the optimization to -O2.  Increasing the optimization level
# to -O3 has caused various problems in the past either with
# specific compilers or on specific platforms.

comment:40 Changed 10 years ago by jdemeyer

New package, use -O2 optimization level also for ia64 systems (testing on iras shows that this now works): http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-1-4.p8.spkg

comment:41 follow-up: Changed 10 years ago by drkirkby

  • Status changed from needs_review to positive_review

That looks ok to me.

Could this not go into 4.7? It seems to me we have fixes for all the gcc 4.6.0 issues. If Sage will build on some platforms with gcc 4.6.0, we have a lot more chance of finding any remaining issues on other platforms.

comment:42 Changed 10 years ago by drkirkby

  • Authors changed from David Kirkby to David Kirkby, Jeroen Demeyer
  • Reviewers changed from AlexanderDreyer to AlexanderDreyer, Jeroen Demeyer

comment:43 in reply to: ↑ 41 Changed 10 years ago by jdemeyer

  • Milestone changed from sage-4.7.1 to sage-4.7

Replying to drkirkby:

Could this not go into 4.7?

I'm willing to try...

comment:44 Changed 10 years ago by jdemeyer

  • Merged in set to sage-4.7.rc0
  • Resolution set to fixed
  • Reviewers changed from AlexanderDreyer, Jeroen Demeyer to Alexander Dreyer, Jeroen Demeyer
  • Status changed from positive_review to closed
  • Work issues Testing on Linux, OS X, Solaris 10 (both x86 and SPARC) with gcc 4.6.0 deleted

comment:45 Changed 10 years ago by jdemeyer

I have also closed #6240 because of this ticket.

comment:46 Changed 10 years ago by drkirkby

  • Description modified (diff)

Changed 10 years ago by jdemeyer

Diff for the singular spkg, for reviewing only

comment:47 Changed 10 years ago by jdemeyer

Please see #11278 for a blocker follow-up, any ideas more than welcome...

Note: See TracTickets for help on using tickets.