bugGNU Octave - Bugs: bug #65460, mxe: build failure due to static?...

 
 

bug #65460: mxe: build failure due to static? library libssp_nonshared.la.

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Wed 13 Mar 2024 04:46:12 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Duplicate Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 20 Mar 2024 07:43:54 AM UTC, comment #33: 

@Markus:
Thank you for your help and patience.

I ran the test suite on Windows and saw no unusual results, just the usual suspects: run.m (which when tested individually always passes) and one in graphics.cc that is most probably due to a local patch by me.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 20 Mar 2024 07:06:50 AM UTC, comment #32: 

Thank you. That was very useful. `LIBS` and the SUNDIALS flags are looking good now afaict.

> BTW remarkable that this build break only happens in mxe-octave; on Linux (native) Octave builds & runs fine.


That is probably because it just so happens that no static libraries get pulled in by the (native) SUNDIALS dependencies on Fedora (or on Debian/Ubuntu).
I'm more surprised that this didn't happen for MXE Octave MinGW cross-builds on the buildbots or for me on Ubuntu...

Closing this as a symptom for the actual bug that is described in bug #65476.

Thank you very much for running the tests.

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Mar 2024 08:59:07 PM UTC, comment #31: 

Attached is a build log of Octave-10 that has just been crossbuilt. It should be from fully up-to-date Octave-10.0.0 with a few local mods, TTBOMK nothing related to the build system, and update to bytecode-interpreter branch, and fully up-to-date mxe-octave.

I hope it is useful

(file #55867)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 19 Mar 2024 06:10:50 PM UTC, comment #30: 

BTW remarkable that this build break only happens in mxe-octave; on Linux (native) Octave builds & runs fine. In both Fedora and mxe-octave, gcc is at 13.2.x.
In the offending Sundials fix from March 6 (bug #65392) I've spotted no specific Windows code.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 19 Mar 2024 05:52:52 PM UTC, comment #29: 

Sorry no, that box has limited space left and mxe-octave and various other Octave source and build trees take heaps of it (could have been a factor in my confusion).
Just home from work, I'll start a next crossbuild and will upload the log of that, would that be OK?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 19 Mar 2024 04:03:21 PM UTC, comment #28: 

Don't worry. Happy to help.

Do you still have the build log (default-octave) from that successful build attempt? Could you please upload it here?

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Mar 2024 03:12:18 PM UTC, comment #27: 

Thanks, you are right, by following the patches in m4/acinclude.m4 at various stages I saw that the dist tarball was fine but in a last step mxe-octave must have picked up another tarball - the patch was missing in tmp-default-octave.

With that issue fixed (wrong symlink in this debug setup), default-octave now gets built fine (that is, it says '[done]' and started building openblas), however using an older mxe-octave revision. But looking at the later csets I think it'll work.

Sorry for the confusion at my side and thanks for your accurate assessment.

Just to be sure I'll again restart the build with an up-to-date mxe-octave and will report back later.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 19 Mar 2024 10:40:06 AM UTC, comment #26: 

`LIBS` still contains the SUNDIALS libraries in the build log:

  LIBS:                          -lsundials_ida -lsundials_nvecserial -lklu -lblas -lxerbla  -L"/home/philip/devel/octdev/mxe/mxe_64b_20240318H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240318H/usr/x86_64-w64-mingw32/qt6/lib" -L/home/philip/devel/octdev/mxe/mxe_64b_20240318H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0 -L/home/philip/devel/octdev/mxe/mxe_64b_20240318H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/philip/devel/octdev/mxe/mxe_64b_20240318H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lssp_nonshared -lssp -lmsvcrt -lkernel32 -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lshlwapi -lgdi32 -lpthread -lm


Also the hg id of the tarball (ce6d586e18c4) exists in the remote repository, and it doesn't end with a plus sign (+). So, likely no local changes.

Are you sure you built from the Octave tarball that was created after you applied the patch from the other report?


Markus Mützel <mmuetzel>
Group administrator
Tue 19 Mar 2024 10:01:49 AM UTC, comment #25: 

build log & config.log attached

(file #55863, file #55864)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 19 Mar 2024 06:47:55 AM UTC, comment #24: 

Could you please upload the build log of the latest attempt with the patch from the other report? (Probably `default-octave`)

> Could ccache interfere?


I'm not sure if you're actually using ccache if you're not building the `all` target...

Markus Mützel <mmuetzel>
Group administrator
Mon 18 Mar 2024 08:25:45 PM UTC, comment #23: 

No joy.

FTR, what I did:
. copy latest clone of default octave to a subdir dev/
. import patch (file #55859)
. bootstrap
. run configure in another directory
. in that build dir, make -j15 && make check && make all dist
. feed the octave-10.0.0 dist archive to mxe-octave (with all dependencies til (not until) default-octave already built).
==> same error

I have mxe-octave at revision b98eb1ee6ba5 ('merge release to default' - the revision at about the time I could crossbuild Octave-10.0.0 for the last time. Actually the build tree I had then was at a much earlier revision)

Any better procedure? I might very well be blind to something obvious.

Could ccache interfere?

It's a long-winding process as first bootstrapping / patching / configuring / building a dist archive (native Linux) and then running mxe-octave on it is slow.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 18 Mar 2024 06:55:04 PM UTC, comment #22: 

I'll have a try

Philip Nienhuis <philipnienhuis>
Group Member
Mon 18 Mar 2024 04:41:03 PM UTC, comment #21: 

Does it work if you use file #55859 (from the other bug report) instead of backing out that changeset?

Markus Mützel <mmuetzel>
Group administrator
Mon 18 Mar 2024 01:10:09 PM UTC, comment #20: 

Backing out the relevant cset from bug #65476 (https://hg.savannah.gnu.org/hgweb/octave/rev/baf7621aa073) made no difference here.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 18 Mar 2024 09:27:57 AM UTC, comment #19: 


> Might be related <the fix for> to bug #65476?

That would about match the time that crossbuilding stopped working for me (my latest successful "regular" build (=including my local mods) was on March 3).
Also fits in with dev Octave time mentioned in comment #13.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 18 Mar 2024 08:10:55 AM UTC, comment #18: 

Might be related to bug #65476?

Markus Mützel <mmuetzel>
Group administrator
Sun 17 Mar 2024 11:45:21 PM UTC, comment #17: 

An mxe-octave build tree that was updated only to a cset of several weeks ago could build octave-10 fine. After updating mxe-octave to current I saw something resembling that same failure you got.
Maybe it is due to some windows-specific code in Octave itself rather than mxe-octave.

So now I wiped about everything, re-cloned default octave & mxe-octave and will try to get Octave-10 crossbuilt tonight.
We'll see tomorrow morning how far it got.

BTW: I spotted a possible typo in mxe-octave Makefile.in at L.624, 'SKIP_CHECHSUM' rather than 'SKIP_CHECKSUM' - but then again there's no 'SKIP_CHECKSUM' (nor 'SKIP_CHECHSUM') anywhere else in Makefile.in. I'm wondering what the stanza around that line is supposed to do.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2024 09:31:42 PM UTC, comment #16: 

Ok, I see a build failure too using default:


libtool:   error: Could not determine the host path corresponding to
libtool:   error:   '/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0'
libtool:   error: Continuing, but uninstalled executables may not work.
libtool:   error: Could not determine the host path corresponding to
libtool:   error:   '/home/jade/mxe-octave/build-qt6/usr/x86_64-w64-mingw32/qt6/lib:/home/jade/mxe-octave/build-qt6/usr/x86_64-w64-mingw32/qt6/bin:/home/jade/mxe-octave/build-qt6/usr/x86_64-w64-mingw32/lib:/home/jade/mxe-octave/build-qt6/usr/x86_64-w64-mingw32/bin:/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0:/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib:/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../bin:/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib:/home/jade/mxe-octave/build-qt6/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin'


The host paths seem to exist for me

John Donoghue <lostbard>
Group Member
Sun 17 Mar 2024 04:09:57 PM UTC, comment #15: 

I"ll slowly grind my way up through mxe-octave and dev Octave hgid´s until I find where it breaks. I have to do this in between other work and real life so it may take some time ...

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2024 03:59:23 PM UTC, comment #14: 

Hmmm that mxe-octave id is wrong, it's actually a much older hgid of several weeks back. I'll try again...

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2024 03:55:51 PM UTC, comment #13: 

With up-to-date mxe-octave (1f7d018803cd), a build of dev-Octave from Mar 4 (hgid 980bd18d962c) gets compiled & built. So it looks like it's something in Octave as latest mxe-octave seems fine.
I'll manually try more recent Octave hgid"s but it's a slow process.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2024 02:00:42 PM UTC, comment #12: 

Its been a while since I did a full rebuild, on fedora fox, but just started it so will see if I have issues

Linux fedora 6.7.9-200.fc39.x86_64


cnfigureing as :

 ../configure --with-pkg-dir=../pkg --enable-octave=default --enable-64 --enable-fortran-int64 --enable-binary-packages --with-ccache --enable-devel-tools --enable-system-octave --disable-system-opengl --enable-qt=6


and make nsis-installer JOBS=4

it will take a while

John Donoghue <lostbard>
Group Member
Fri 15 Mar 2024 10:52:15 PM UTC, comment #11: 

After bootstrapping and configuring, Octave dist archives could be made again but I'm unsure if it is related to this build error. What you write has undoubtedly merit but on my Mageia (previously Mandrake and Mndriva) installations that I've been building Octave on for 15-20 years I can´t remember to ever have had to re-bootstrap after system upgrades.

A fresh clone of dev Octave and mxe-octave still didn´t work on both my Fedora and Mageia boxes. I get the same error messages about libssp_nonshared, although as you wrote, the actual error may happen much earlier.
I configured mxe-octave with 64-bit Fortran indexing (Fedora) and without (Mageia) but the build breaks at the same place.

I¨m at loss on how to proceed further and get this solved.
AFAICT it's probably something in mxe-octave as Linux builds have no issues and run fine.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 15 Mar 2024 10:50:39 AM UTC, comment #10: 

I assume that your autotools (and/or libtool) might have been updated during that major system upgrade. Did you run the bootstrap script after that?

Markus Mützel <mmuetzel>
Group administrator
Fri 15 Mar 2024 09:19:42 AM UTC, comment #9: 

(wild guess) maybe it is related to something in my build box (Fedora 39). Currently even 'make dist' for Octave native builds doesn't work. I got a few loads of large system upgrades lately on that box.

I'll try the whole Octave build sequence (first Linux then mxe-octave) on my other box first (Mageia 9), but that is a slow Core i5 so it'll probably take overnight.

Thanks so far

Philip Nienhuis <philipnienhuis>
Group Member
Thu 14 Mar 2024 05:38:59 PM UTC, comment #8: 


> I didn't use 'make all nsis-installer JOBS=15' (didn´t note the "all" option.  But AFAICS now that also just leads to building default-octave.


IIRC, `make all` builds a couple of targets that aren't built otherwise.

Markus Mützel <mmuetzel>
Group administrator
Thu 14 Mar 2024 11:08:03 AM UTC, comment #7: 


> And you showed a different command before

???
The configure command is always the same (comment #2), the build command that gave me the error is

make nsis-installer JOBS=15

(yes the one in comment #2)
(for an existing re-used mxe-octave build tree this is preceded by me by a command to wipe the default-octave entries in installed packages/ )
Yesterday night I started a clean mxe-octave build tree but that gave the exact same issues, so that's the log I uploaded. I supposed octave's config.log would have been included in it (wrong!).
config.log (bzip2-ed) from ,mxe./tmp-default-octave/octave-10.0.0/.build attached.

I didn't use 'make all nsis-installer JOBS=15' (didn´t note the "all" option.  But AFAICS now that also just leads to building default-octave.

(file #55837)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 14 Mar 2024 10:50:10 AM UTC, comment #6: 

JOBS=1 or JOBS=15 makes no difference.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 14 Mar 2024 10:22:38 AM UTC, comment #5: 


> That's what I did and what the log pertains to


I asked for the commands that you used when you got that error. And you showed a different command before.
Is the configure command that you showed in comment #2 the one that you actually used? Or did you actually use different configure flags, too?

> You mean config.log of mxe-octave?


I meant the `config.log` file of the failing Octave build.

Markus Mützel <mmuetzel>
Group administrator
Thu 14 Mar 2024 09:05:01 AM UTC, comment #4: 


> Does it make a difference if you build with `make all nsis-installer JOBS=15`?

That's what I did and what the log pertains to, Trying now with JOBS=1 (slow...).

You mean config.log of mxe-octave? attached as well as config.status

(file #55835, file #55836)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 14 Mar 2024 08:20:34 AM UTC, comment #3: 

Uploading a .zip archive with the log here to keep it for longer.
It looks like `-lssp_nonshared` is added via the Fortran link flags.
Could you please upload the config.log file?


ISTR that I had some issues when I didn't build the `all` target in the past. (Don't recall how exactly that made trouble.)
Does it make a difference if you build with `make all nsis-installer JOBS=15`?


(file #55834)

Markus Mützel <mmuetzel>
Group administrator
Thu 14 Mar 2024 08:12:04 AM UTC, comment #2: 

Sure, log is a bit big (7+ Mb), so I've uploaded it here:
https://prn183.stackstorage.com/s/fxpA0mKgrRUrZq9C
(link valid until March, 20)
(and that site had maintenance so it took a bit long)
It is from a clean build tree from yesterday.

mxe-octave was configured with:
 ./configure --enable-octave=default --enable-64 --enable-fortran-int64 --enable-binary-packages --with-ccache --enable-devel-tools --enable-system-octave --disable-system-opengl --enable-qt=6

and build was tried using:
make nsis-installer JOBS=15

My last successful crossbuild (at that moment fully up-to-date) was at March 3.

I'll also try a build with JOBS=1, ISTR to have seen some sort of race conditions before but can´t remember if it was Octave or mxe-octave.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Mar 2024 05:34:12 PM UTC, comment #1: 

That doesn't happen on any of the buildbots.

How did you configure MXE Octave? Which command did you use to build?

Also, the part of the log that you showed doesn't contain the actual build error. So, it's hard to tell if those warnings actually cause an issue.

Could you please upload the complete log of a build from a clean tree?

Markus Mützel <mmuetzel>
Group administrator
Wed 13 Mar 2024 04:46:12 PM UTC, original submission:  

Since Monday I get crossbuild failures:

:
/bin/sh ./libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++  -pthread -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual  -g -O2 -no-undefined   -municode -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib  -Wl,-rpath-link,"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/qt6/lib" -o src/octave-cli.exe src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o libinterp/liboctinterp.la liboctave/liboctave.la libgnu/libgnu.la  -lsundials_ida -lsundials_nvecserial -lklu -lblas -lxerbla  -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/qt6/lib" -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0 -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lssp_nonshared -lssp -lmsvcrt -lkernel32 -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lshlwapi -lgdi32 -lpthread -lm

*** Warning: This system cannot link to static lib archive /home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/libssp_nonshared.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
:

:
/bin/sh ./libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++  -pthread -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual  -g -O2 -no-undefined   -municode -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib  -Wl,-rpath-link,"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/qt6/lib" -o src/octave-cli.exe src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o libinterp/liboctinterp.la liboctave/liboctave.la libgnu/libgnu.la  -lsundials_ida -lsundials_nvecserial -lklu -lblas -lxerbla  -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/lib" -L"/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/x86_64-w64-mingw32/qt6/lib" -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0 -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lssp_nonshared -lssp -lmsvcrt -lkernel32 -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lshlwapi -lgdi32 -lpthread -lm

*** Warning: This system cannot link to static lib archive /home/philip/devel/octdev/mxe/mxe_64b_20240131H/usr/lib/gcc/x86_64-w64-mingw32/13.2.0/libssp_nonshared.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
:

:
libtool: link: ( cd "libgui/.libs" && rm -f "liboctgui.la" && ln -s "../liboctgui.la" "liboctgui.la" )
make[4]: Leaving directory '/home/philip/devel/octdev/mxe/mxe_64b_20240131H/tmp-default-octave/octave-10.0.0/.build'
make[3]: *** [Makefile:28202: install-recursive] Error 1
make[3]: Leaving directory '/home/philip/devel/octdev/mxe/mxe_64b_20240131H/tmp-default-octave/octave-10.0.0/.build'
make[2]: *** [Makefile:28509: install] Error 2
make[2]: Leaving directory '/home/philip/devel/octdev/mxe/mxe_64b_20240131H/tmp-default-octave/octave-10.0.0/.build'
make[1]: *** [/home/philip/devel/octdev/mxe/mxe_64b_20240131H/Makefile:1006: build-only-default-octave] Error 2
make[1]: Leaving directory '/home/philip/devel/octdev/mxe/mxe_64b_20240131H'

The verbatim above is from an older mxe build tree but a newly cloned and started one gave exactly the same issues.
On Linux Octave builds and runs fine, so I suppose it must be related to recent mxe-octave changes.

Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55867:  mxe-default-octave-log.zip added by philipnienhuis (365KiB - application/zip)
file #55863:  config.log.zip added by philipnienhuis (135KiB - application/zip)
file #55864:  default-octave-log.zip added by philipnienhuis (210KiB - application/zip)
file #55837:  config.log.bz2 added by philipnienhuis (94KiB - application/x-bzip)
file #55835:  config.log added by philipnienhuis (12KiB - text/x-log)
file #55836:  config.status added by philipnienhuis (26KiB - application/octet-stream)
file #55834:  default-octave.zip added by mmuetzel (231KiB - application/x-zip-compressed)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-20 mmuetzel StatusIn Progress Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #65476
    2024-03-19 philipnienhuis StatusNeed Info In Progress
    2024-03-19 philipnienhuis Attached File- Added mxe-default-octave-log.zip, #55867
    2024-03-19 philipnienhuis Attached File- Added config.log.zip, #55863
        Attached File- Added default-octave-log.zip, #55864
    2024-03-14 philipnienhuis Attached File- Added config.log.bz2, #55837
    2024-03-14 philipnienhuis Attached File- Added config.log, #55835
        Attached File- Added config.status, #55836
    2024-03-14 mmuetzel Attached File- Added default-octave.zip, #55834
    2024-03-13 mmuetzel StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-ee12.
    Corresponding source code