Am 18.08.2020 um 04:09 schrieb "Kai Torben Ohlhus:
> When GNULIB_SRCDIR is set, this addition should probably work as well.
> Looking at it, maybe it can be fixed by extending your code section [2] by
> "git fetch":
>
> if test -d "$GNULIB_SRCDIR"/.git && test -n "$GNULIB_REVISION" \
> && !
I tried to use the windows-spawn module in a project that defines UNICODE.
Compilation of gnulib failed with the following error:
libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/osboxes/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libgnu -I..
-I/home/osboxes/Octave/mx
Am 06. Mai 2021 um 14:28 Uhr schrieb "Markus Mützel":
> I tried to use the windows-spawn module in a project that defines UNICODE.
>
> Compilation of gnulib failed with the following error:
>
> libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
> -I/home/o
Am 14. Mai 2021 um 12:39 Uhr schrieb "Bruno Haible":
> Yes, I agree. That's the proper way to fix it. I applied and pushed your
> change.
> Thanks!
Thanks! Very much appreciated.
Markus
r and integer
72 | for (wchar_t *ws = wenv; *ws != NULL; ws++)
^~
IIUC, these warnings might be legitimate.
The attached patch avoids those warnings.
I'm hoping this is the correct format to propose changes to gnulib.
Best,
Markus Mützel
From 87b83c757f7d249f983410e85d13ba450d5
Hi Bruno,
> > The attached patch avoids those warnings.
>
> Thanks, but it does not do the right thing: *s[1] accesses the first character
> of the string after s. What was meant was to access the second character of
> the string at s; this needs to be written as (*s)[1].
Oof. You are absolutely
Dear gnulib developers,
GNU Octave uses Mercurial as the VCS of its main repository.
Developers are using the bootstrap script of gnulib to automatically clone its
Git repository in a subdirectory of Octave's source tree. The revision that
we'd like to use is set in the bootstrap.conf script. Cu
Hi Bruno,
> > As a workaround we are applying the attached patch to the
> > bootstrap-funclib.sh script to automatically fetch from the remote gnulib
> > repository if the GNULIB_REVISION isn't found in the local gnulib Git
> > repository.
>
> Thanks for the patch. But note that GNULIB_REVISION
Hi Bruno,
Bruno Haible wrote:
> Markus Mützel wrote:
> > However, it looks like $GNULIB_SRCDIR is empty for us. So, the change
> > doesn't seem to make a difference. Executing bootstrap after a revision
> > bump still fails if the bootstrap script was already run befor
Dear gnulib maintainers,
We recently updated gnulib to a newer revision in GNU Octave (currently
92d80242ad1344b5364ca9bd1d995d68c3a73ef7).
Since then we are seeing compilation errors like the following when targeting
Cygwin:
In file included from /usr/include/sys/reent.h:16,
Hi Bruno,
Bruno Haible wrote
> Which Cygwin version, please?
That error occurred, e.g., in a CI run
https://github.com/gnu-octave/octave/actions/runs/8873331621/job/24358996111
The log of that run contains the following line:
Starting cygwin install, version 2.932
Is that the Cygwin version?
A
Hi Bruno,
> The patch below fixes it for me. It reverts a workaround for gcc 14.0.1
> from a few days ago, for which I'm adding a different workaround later.
Thank you very much. That fixed the build errors also for us. (Tested with
6213c5bd72d15ca5e1ea9c34122899e02fed448c.)
Markus
Octave is using gnulib's "fseek" and "ftell" functions. A user reported that
they have issues when using these functions with large files on Windows:
https://savannah.gnu.org/bugs/index.php?66399
If I understand the code paths for Windows correctly, the issue might be caused
by the fact that the
Am Montag, 11. November 2024 um 19:50 schrieb "Bruno Haible":
> Hi,
>
> Markus Mützel wrote:
> > Octave is using gnulib's "fseek" and "ftell" functions. A user
reported that they have issues when using these functions with large files on
Wi
My email provider started to mess with outgoing only-text messages. So,
apologies if some characters are replaced incorrectly.
Am 13. November 2024 um 00:54 schrieb "Bruno Haible":
> In order to make sure that Octave does not have bugs with files > 2 GiB
> (without restrictions like "as far as I
The following might be relevant:
configure:79124: checking spelling of daylight variable
configure:79153: gcc -o conftest.exe -g -ggdb -O0 -pthread -fopenmp
-fexceptions conftest.c -lpthread -lm >&5
conftest.c: In function 'main':
conftest.c:341:8: error: returning 'int * (*)(void)' from a fun
Hello,
I tried to build Octave for Windows after updating gnulib from
6213c5bd72d15ca5e1ea9c34122899e02fed448c to
f3d96537413f1fc0913cd290b1eea35386295b1b.
I'm using mingw-w64 at commit cf5c50cce0b4f8610eafd95443d1d3767de386a5.
Some configure tests are failing now that have been passing previou
Am 14. November 2024 um 18:43 schrieb "Paul Eggert":
> That 'daylight' business was a fiasco for other reasons, which I had
> been meaning to clean up but haven't gotten around to. I installed the
> attached Gnulib patch for now; please give it a try.
>
> As the Gnulib manual says, nobody should us
Am 14. November 2024 um 13:31 schrieb "Bruno Haible":
> No, this is not needed. In a testdir of the modules fseeko, ftello, fsync,
> on mingw:
> - we have REPLACE_FSEEKO=1, hence fseeko.c gets compiled, and it uses
> the mingw fseeko function,
> - the two new unit tests pass.
> - Apparent
Am 14. November 2024 um 05:18 schrieb "Bruno Haible":
> And with this additional patch, ftello() works on large files on mingw.
>
>
> 2024-11-14 Bruno Haible
>
>ftello: Fix override on mingw.
>Reported by Markus Mützel in
>.
>* lib/fte
Am 14. November 2024 um 15:31 schrieb "Bruno Haible"
>
> Markus Mützel wrote:
> > If the unit test passes with it, it might be passing erroneously.
>
> No: Before making the fixes and adding the unit test, I verified that
without
> the fixes, the unit test failed
21 matches
Mail list logo
