bugGNU Octave - Bugs: bug #64709, Android Termux libtool issue

 
 

bug #64709: Android Termux libtool issue

Submitter:  Adam Labus <electricjozin>
Submitted:  Fri 22 Sep 2023 10:40:46 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Adam Labus Open/Closed:  * Closed
Release:  * 8.3.0 Operating System:  * Other
Fixed Release:  9.1.0 (current stable) Planned Release:  9.1.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 24 Oct 2023 12:46:51 PM UTC, comment #27: 

No further feedback during the last three weeks.
Assuming this is fixed from the Octave side.

If there are changes in Octave's build system that are still necessary to allow (cross-)building for an Android target, this report can be re-opened or a new report can be opened.

Closing report (for now).

Markus Mützel <mmuetzel>
Group administrator
Thu 05 Oct 2023 09:56:10 AM UTC, comment #26: 


> There is no port of gcc in termux... we use clang


I was just guessing from the output that you'd showed so far. It is using `g++`. But that might just be a symlink to `clang++` on your system...
In that case, try to explicitly add whatever runtime library provides that symbol on your system to `LIBS`.

And make sure that the linker that is found by the configure script is the one that you need to use for that target. (Still strange that you are setting the target triplet only in CPPFLAGS.)

In any case, that looks more like an issue in your build environment. Octave's build system probably shouldn't try to work around such issues.


Markus Mützel <mmuetzel>
Group administrator
Thu 05 Oct 2023 07:32:29 AM UTC, comment #25: 


comment #23:

> May be this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845
>
> I.e., libgcc_s.so doesn't pull in -lgcc for you?
>
> If that is the case, configuring with the following might be a workaround:


> ../configure --prefix=/data/data/com.termux/files/usr CPPFLAGS='-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33 --target=aarch64-linux-android33' LIBS="-lgcc"


>


And $PREFIX is the root directory of the termux chroot. Which is to say: that symbol is not on my whole system.

Adam Labus <electricjozin>
Thu 05 Oct 2023 07:24:11 AM UTC, comment #24: 


comment #23:

> May be this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845
>
> I.e., libgcc_s.so doesn't pull in -lgcc for you?
>
> If that is the case, configuring with the following might be a workaround:


> ../configure --prefix=/data/data/com.termux/files/usr CPPFLAGS='-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33 --target=aarch64-linux-android33' LIBS="-lgcc"


>


There is no port of gcc in termux... we use clang

Adam Labus <electricjozin>
Wed 04 Oct 2023 03:29:42 PM UTC, comment #23: 

May be this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845

I.e., libgcc_s.so doesn't pull in -lgcc for you?

If that is the case, configuring with the following might be a workaround:

../configure --prefix=/data/data/com.termux/files/usr CPPFLAGS='-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33 --target=aarch64-linux-android33' LIBS="-lgcc"


Markus Mützel <mmuetzel>
Group administrator
Wed 04 Oct 2023 01:14:59 PM UTC, comment #22: 

Yes indeed the patch fixes the compiling issue. The runtime missing symbol persists and I think because of something I did wrong regarding the api_level, the following only returns the 0 NOTYPE definitions of liboctave.so and liboctinterp.so

Command:

find $PREFIX -name '*.so' -exec sh -c "if readelf -Ws {} 2>&1 | grep '__aarch64_ldadd8_acq_rel'; then echo {}; fi" \;


Output:

15: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel                                              43086: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel                                             /data/data/com.termux/files/usr/lib/octave/8.3.0/liboctave.so
     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel                                              44756: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel
/data/data/com.termux/files/usr/lib/octave/8.3.0/liboctinterp.so


Adam Labus <electricjozin>
Wed 04 Oct 2023 10:10:30 AM UTC, comment #21: 

Thanks for the tests.

Does it work if you apply the following patch on top of the release tarball?
https://hg.savannah.gnu.org/hgweb/octave/raw-rev/be5db604940b

(Run `autoreconf -fi` and don't define getpwnam for the test.)

Markus Mützel <mmuetzel>
Group administrator
Wed 04 Oct 2023 09:15:18 AM UTC, comment #20: 

Sorry for the late update, I always do these things in the commute so I quickly lose track of things I did, thats why all the tests I ran are here: https://rentry.co/pcs9b

Adam Labus <electricjozin>
Wed 27 Sep 2023 01:05:43 PM UTC, comment #19: 

The following change might avoid the issue on your platform:
https://hg.savannah.gnu.org/hgweb/octave/rev/be5db604940b

Does that work for you?

Marking as read for test.

Markus Mützel <mmuetzel>
Group administrator
Wed 27 Sep 2023 10:48:45 AM UTC, comment #18: 

I wonder why `-C` didn't have an effect on the output of `nm`.

Anyway, the symbol that is exported by liboctave for you demangles, e.g., to this:

$ c++filt _ZN6octave3sys8password25android_polyfill_getpwnamERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE
octave::sys::password::android_polyfill_getpwnam(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&)


It looks like something replaces `getpwnam` with `android_polyfill_getpwnam`. But that doesn't seem to be happening for all compilation units. Maybe a preprocessor definition in some header that isn't included everywhere?

Might be this issue: https://github.com/termux/termux-packages/issues/15889

Does it help if you add `-Dgetpwnam=android_polyfill_getpwnam` to the CPPFLAGS for the configure script? (That's just a dirty workaround - not an actual fix.)

The actual fix would probably be to not include `pwd.h` directly in our source code. Instead, we might need to call these functions through C wrappers...

Markus Mützel <mmuetzel>
Group administrator
Wed 27 Sep 2023 05:29:27 AM UTC, comment #17: 

comment #15:

> What does the following command display?
>


> nm liboctave/system/.libs/libsystem_la-oct-password.o | grep getpwuid | c++filt


>



0000000000000238 T octave::sys::password::android_polyfill_getpwuid(unsigned int)
0000000000000310 T octave::sys::password::android_polyfill_getpwuid(unsigned int, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >&)
                 U getpwuid


comment #16:

> Thanks!
> I don't see anything obvious wrong with that.
>
> Those symbols should be exported by the liboctave library.
>
> In the build tree, could you please run the following command and show the results?


> nm -C liboctave/.libs/liboctave.so | grep getpwnam


>
> I see the following here (building natively for Linux):


> $ nm -C liboctave/.libs/liboctave.so | grep getpwnam
>                  U getpwnam@GLIBC_2.2.5
> 0000000000c38420 T octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
> 000000000021e57e t octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [clone .cold]
> 0000000000c383d0 T octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)


>
> Just a guess: Did you build from a clean build tree after autoreconf?


I did build clean yes. Doing the whole procedure again didnt help.


0000000000e194b8 T _ZN6octave3sys8password25android_polyfill_getpwnamERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE
0000000000e1959c T _ZN6octave3sys8password25android_polyfill_getpwnamERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEERS8_
                 U _ZN6octave3sys8password8getpwnamERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE
                 U getpwnam
                 U getpwnam_r


Adam Labus <electricjozin>
Tue 26 Sep 2023 07:58:18 PM UTC, comment #16: 

Thanks!
I don't see anything obvious wrong with that.

Those symbols should be exported by the liboctave library.

In the build tree, could you please run the following command and show the results?

nm -C liboctave/.libs/liboctave.so | grep getpwnam


I see the following here (building natively for Linux):

$ nm -C liboctave/.libs/liboctave.so | grep getpwnam
                 U getpwnam@GLIBC_2.2.5
0000000000c38420 T octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
000000000021e57e t octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [clone .cold]
0000000000c383d0 T octave::sys::password::getpwnam(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)


Just a guess: Did you build from a clean build tree after autoreconf?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Sep 2023 07:44:21 PM UTC, comment #15: 

What does the following command display?


nm liboctave/system/.libs/libsystem_la-oct-password.o | grep getpwuid | c++filt


John W. Eaton <jwe>
Group administrator
Tue 26 Sep 2023 06:10:39 PM UTC, comment #14: 

The log:

/bin/sh ./libtool  --tag=CXX   --mode=link g++ -fPIC -pthread -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual  -g -O2      -o src/octave-cli src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o libinterp/liboctinterp.la liboctave/liboctave.la libgnu/libgnu.la  -lpthread -lm
libtool: link: g++ -fPIC -fopenmp -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -o src/.libs/octave-cli src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o  libinterp/.libs/liboctinterp.so -L/data/data/com.termux/files/usr/lib/gcc/aarch64-linux-android/11.1.0/../../.. /data/data/com.termux/files/home/src/octave-8.3.0/.build/liboctave/.libs/liboctave.so -lhdf5 -lGraphicsMagick++ -lGraphicsMagick -lz -lfontconfig -lfreetype liboctave/.libs/liboctave.so -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -lspqr -larpack -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -lopenblas -lpcre2-8 -lgfortran libgnu/.libs/libgnu.a -L/data/data/com.termux/files/usr/lib -lreadline -liconv -lpthread -lm -fopenmp -pthread -Wl,-rpath -Wl,/data/data/com.termux/files/usr/lib/octave/8.3.0
ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwuid(unsigned int, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>&)
>>> referenced by libinterp/.libs/liboctinterp.so

ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwnam(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>&)
>>> referenced by libinterp/.libs/liboctinterp.so

ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwnam(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&)
>>> referenced by /data/data/com.termux/files/home/src/octave-8.3.0/.build/liboctave/.libs/liboctave.so

ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwuid(unsigned int)
>>> referenced by /data/data/com.termux/files/home/src/octave-8.3.0/.build/liboctave/.libs/liboctave.so
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:15739: src/octave-cli] Error 1
make[2]: Leaving directory '/data/data/com.termux/files/home/src/octave-8.3.0/.build'
make[1]: *** [Makefile:27671: all-recursive] Error 1
make[1]: Leaving directory '/data/data/com.termux/files/home/src/octave-8.3.0/.build'
make: *** [Makefile:11061: all] Error 2


(file #55171, file #55172)

Adam Labus <electricjozin>
Tue 26 Sep 2023 05:37:41 PM UTC, comment #13: 

Could you please upload `config.log` and `config.h` from your build directory?

Could you also please run make with `V=1` and show the complete linker command that is causing that error?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Sep 2023 03:55:00 PM UTC, comment #12: 


comment #11:

> I guess the reason for the missing symbol when linking is that libtool tries to link with `-nostdlib` but fails to explicitly link with the library that provides that symbol.
>
> Did `autoreconf -fi` make a difference?
>
> Does it help if you add bionic libc in LIBS?
>
> See, e.g., here for a similar issue:
> https://github.com/android/ndk/issues/1614
>
> And here for a potential workaround:
> https://github.com/termux/termux-packages/commit/562462e2296217e20c2a14fd8e8d9279486f14cb


Autoreconf causes the following make problem:

ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwuid(unsigned int, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>&)                                             >>> referenced by libinterp/.libs/liboctinterp.so                                                                               ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwnam(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>&)                     >>> referenced by libinterp/.libs/liboctinterp.so                                                                               ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwnam(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&)                                                     >>> referenced by /data/data/com.termux/files/home/src/octave/octave-8.3.0/.build/liboctave/.libs/liboctave.so                                                                                  ld.lld: error: undefined reference due to --no-allow-shlib-undefined: octave::sys::password::getpwuid(unsigned int)             >>> referenced by /data/data/com.termux/files/home/src/octave/octave-8.3.0/.build/liboctave/.libs/liboctave.so


Adam Labus <electricjozin>
Mon 25 Sep 2023 06:02:17 PM UTC, comment #11: 

I guess the reason for the missing symbol when linking is that libtool tries to link with `-nostdlib` but fails to explicitly link with the library that provides that symbol.

Did `autoreconf -fi` make a difference?

Does it help if you add bionic libc in LIBS?

See, e.g., here for a similar issue:
https://github.com/android/ndk/issues/1614

And here for a potential workaround:
https://github.com/termux/termux-packages/commit/562462e2296217e20c2a14fd8e8d9279486f14cb

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Sep 2023 05:48:08 PM UTC, comment #10: 


comment #8:

> Ah. And it's probably not enough to set the target only in the preprocessor flags. (Does that even do something?)
>
> Does configuring with something like this (untested) make a difference?


> ../configure --prefix=$PREFIX CPPFLAGS="-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33" --target=aarch64-linux-android33 --host=aarch64-linux-android33


>
> (Note the differing position of the closing double-quotes compared to what you showed in comment #0.)


The reason that the target flag is being passed to the preprocessor is because of bionic libc, because it's header files are full of version specific defines.

Anyways setting the target/host in both places has no effect on the issue.

Also if readelf found the symbol then whats the problem?

Adam Labus <electricjozin>
Mon 25 Sep 2023 04:54:36 PM UTC, comment #9: 

The following change should lead to an early error when trying to configure with `--disable-shared`:
https://hg.savannah.gnu.org/hgweb/octave/rev/2b44805fc139

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Sep 2023 10:35:56 AM UTC, comment #8: 

Ah. And it's probably not enough to set the target only in the preprocessor flags. (Does that even do something?)

Does configuring with something like this (untested) make a difference?

../configure --prefix=$PREFIX CPPFLAGS="-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33" --target=aarch64-linux-android33 --host=aarch64-linux-android33


(Note the differing position of the closing double-quotes compared to what you showed in comment #0.)

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Sep 2023 10:17:54 AM UTC, comment #7: 

That symbol should likely be provided by the standard libraries.

Does running `autoreconf -fi` before configuring make a difference?

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Sep 2023 05:30:31 AM UTC, comment #6: 


comment #2:

> .oct files are basically shared libraries that are loaded on runtime.
> I don't know if there is any way to load functions from static libraries at runtime.
>
> I'm also doubting whether it makes sense to link the entire interpreter (and liboctave + its dependencies) to each and every .oct file. So, it probably doesn't make sense to build a static library version of Octave.
>
> Which problems are you running into with shared libraries?
>



octave: no graphical display found
octave: disabling GUI features
CANNOT LINK EXECUTABLE "/data/data/com.termux/files/usr/bin/octave-cli-8.3.0": cannot locate symbol "__aarch64_ldadd8_acq_rel" referenced by "/data/data/com.termux/files/usr/lib/octave/8.3.0/liboctinterp.so.11.0.1"...


Running +verbatim+ readelf -Ws --dyn-syms -verbatim- on the shared library gives:


   ...
9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel                                              44756: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __aarch64_ldadd8_acq_rel
   ...


Adam Labus <electricjozin>
Sun 24 Sep 2023 06:05:09 PM UTC, comment #5: 

Does the following change look reasonable?

diff -r 2c47affeec43 configure.ac
--- a/configure.ac        Sun Sep 24 17:46:11 2023 +0200
+++ b/configure.ac        Sun Sep 24 20:01:59 2023 +0200
@@ -613,6 +613,7 @@
   SHARED_LIBS=yes
 else
   SHARED_LIBS=no
+  AC_MSG_ERROR([Building shared libraries is required!])
 fi
 AC_SUBST(SHARED_LIBS)


Markus Mützel <mmuetzel>
Group administrator
Sun 24 Sep 2023 05:31:37 PM UTC, comment #4: 

@Markus: Yes, you are correct that building a static version of Octave probably doesn't make sense and may not even work.  I don't think we should try to support it and I certainly have no interest in trying to make it work myself, but I don't object if someone wants to try and shows us how to make it work properly.  If that happens, we could consider patches.

I'd be fine with having the configure script simply fail if shared libraries are disabled.  We've discussed this possibility a number of times already (search the bug tracker for --disable-shared or --enable-static).  Anyone who really wants to attempt to make it work could easily make the necessary changes to avoid the error exit.

John W. Eaton <jwe>
Group administrator
Sun 24 Sep 2023 04:55:05 PM UTC, comment #3: 

Should we fail early (i.e., while running the configure script) if one of the flags is `--disable-shared` or `--enable-static`?

Do those flags affect how the Octave libraries are built? Or do they affect how dependencies are linked?

Markus Mützel <mmuetzel>
Group administrator
Sun 24 Sep 2023 04:52:09 PM UTC, comment #2: 

.oct files are basically shared libraries that are loaded on runtime.
I don't know if there is any way to load functions from static libraries at runtime.

I'm also doubting whether it makes sense to link the entire interpreter (and liboctave + its dependencies) to each and every .oct file. So, it probably doesn't make sense to build a static library version of Octave.

Which problems are you running into with shared libraries?

Markus Mützel <mmuetzel>
Group administrator
Fri 22 Sep 2023 11:00:44 PM UTC, comment #1: 

Removing the flag --enable-static fixes the problem. Thing is I need the binary to be static because I am running into other library issues.

Adam Labus <electricjozin>
Fri 22 Sep 2023 10:40:46 PM UTC, original submission:  

After fetching the release sources and running the following config:


../configure --disable-shared --enable-static --prefix=$PREFIX CPPFLAGS="-O0 -g -U __ANDROID_API__ -D __ANDROID_API__=33 --target=aarch64-linux-android33"


I get the following build error after running make:


Makefile:30915: update target 'libinterp/dldfcn/__delaunayn__.oct' due to: target does not exist                                              echo "  GEN     " libinterp/dldfcn/__delaunayn__.oct;/data/data/com.termux/files/usr/bin/install -c libinterp/dldfcn/.libs/ libinterp/dldfcn/__delaunayn__.oct                                                       Putting child 0x74a6b7d310 (libinterp/dldfcn/__delaunayn__.oct) PID 590 on the chain.                                                         Live child 0x74a6b7d310 (libinterp/dldfcn/__delaunayn__.oct) PID 590     GEN      libinterp/dldfcn/__delaunayn__.oct                          install: omitting directory 'libinterp/dldfcn/.libs/'                  Reaping losing child 0x74a6b7d310 PID 590                              make[2]: *** [Makefile:30915: libinterp/dldfcn/__delaunayn__.oct] Error 1


The following Makefile line is of issue:

%.oct : %.la
        $(AM_V_GEN)$(INSTALL_PROGRAM) libinterp/dldfcn/.libs/$(shell $(SED) -n -e "s/dlname='\([^']*\)'/\1/p" < $<) $@


The rule gets run with:

Target: libinterp/dldfcn/__delaunayn__.oct
Depends: libinterp/dldfcn/__delaunayn__.la


Thing is the dlname field in the dependency file is an empty string, which in turn causes the error. Checkout the .la file in the attachments. I dont have the slightest clue how libtool fits into the configure picture, so idk if this even is the problem. Thing is, I could build the sources what I think then happend is I installed libtool and everything broke (uninstall didnt help).

Adam Labus <electricjozin>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #55171:  config.log added by electricjozin (2MiB - application/octet-stream)
file #55172:  config.h added by electricjozin (114KiB - application/octet-stream)
file #55158:  __delaunayn__.la added by electricjozin (969B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by electricjozin (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 project members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-10-24 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.1.0 (current stable)
    2023-10-04 mmuetzel Planned ReleaseNone 9.1.0 (current stable)
    2023-09-27 mmuetzel StatusNeed Info Ready For Test
    2023-09-26 electricjozin Attached File- Added config.log, #55171
        Attached File- Added config.h, #55172
    2023-09-24 mmuetzel StatusNone Need Info
    2023-09-22 electricjozin Attached File- Added _delaunayn_.la, #55158

    Back to the top

    Powered by Savane 3.12