eli-project-users — For communication among users

[Eli-project-users] gcc 15.1.1 and eli

[Freelance R. <fre...@ro...>]

Hi all,

with the event of gcc 15.1.1, the default C language standard of gcc has 
changed from gnu17 (that is not identical to c17) to gnu23 (not 
identical to c23).

Unfortunately, this breaks some code in eli, or to be more precise

1. A new problem has been added
2. We haven't seen some problems with c11 and c17 before

---

1. A new problem has been added

I haven't read the c23 standard yet, but it seems that "bool", "false", 
and "true" are keywords now (before we had _Bool, but boolean 
expressions and values were handled differently, i.e. before they were 
ints while now it seems they are of type bool).

A "typedef int bool" or alike is not allowed anymore.
(see .../Eli/pkg/liga/middle/order/bool.h
and maybe also in .../Eli/pkg/liga/backend/bool.h)

In lack of a real bool type (incl false and true), also #defines for 
FALSE and TRUE had been used in C code, and this is true for the eli 
sources as well.

My ¢2 is to use a common bool.h file.
For now that file could look like the following

cat <<-BOOLH > bool.h

#ifndef __cplusplus
#if __STDC_VERSION__ < 202311L
/* pre C23 versions */
typedef int bool;
#define false   0
#define true    (!false)
#endif
#endif

#define FALSE false
#define TRUE  true

BOOLH


---
2. We haven't seen the problems with c11 and c17 until now

When I encountered the problems with the bools, I first tried to set the 
standard to c17 or c11, but that also failed, although the eli sources 
were compilable until right before the new gcc version was installed.

The reason for that is that gcc always uses its own versions of the 
standards, i.e. instead of c11 they use gnu11, instead of c17, they use 
gnu17 by default.

If we compile with strict c11 or c17, then functions like strdup() and 
kill() (both found in editline.c, but maybe in other files, too) do not 
have proper prototypes anymore.
(strdup was not even in the C standard until C23).


Those who want to compile eli with gcc 15.1.1 right now, need to specify 
something like

CFLAGS="-std=gnu17 -O"

at the ./configure.


Thomas


PS clang (and by that the "gcc" on Apple's IOS) has not have made that 
transition yet.


cat <<-NULL > 0.c
typedef int bool;

int main()
{
     bool x = false;
     return 0;
}
NULL

cat <<-EINS > 1.c
#include <string.h>

int main()
{
     char* p = 0;

     p= (char*) strdup((char*)"x");

     return 0;
}
EINS

cat <<-EINSEINS > 11.c
int main()
{
     int false = 1;
     return 0;
}
EINSEINS


cat <<-ZWEIZWEI > 22.c
#include <stdio.h>

#if __STDC_VERSION__ < 202311L
typedef int bool;
#endif

int main()
{
     const int V = 42;
     bool truevalue1 = 4;
     bool truevalue2 = V < 100;

     printf("%d\n",(int)truevalue1);

     if (truevalue1 == truevalue2)
     {
         printf("it's true\n");
     }
     else
     {
         printf("it's false\n");
     }

     return 0;
}
ZWEIWEI


#
# 1.c is similar to line 721 in editline.c
#
#gcc --version
#gcc (GCC) 15.1.1 20250425

Try

gcc -std=gnu23 0.c

gcc -std=c11 1.c
gcc -std=gnu11 1.c
gcc -std=c17 1.c
gcc -std=gnu17 1.c
gcc -std=c23 1.c
gcc -std=gnu23 1.c

gcc -std=c11 11.c
gcc -std=c23 11.c

gcc -std=c11 22.c
gcc -std=c23 22.c

Re: [Eli-project-users] auxEOF and :gorto

[uwe <uw...@un...>]

I’m sorry to say that at the moment none of the Eli developers is
available to take care of the auxEOF topic. It may take a several days
until you’ll get an answer.

Regards 
Uwe

> Am 10.02.2025 um 08:16 schrieb Freelance Roemke <fre...@ro...>:
> 
> 
> Thanks Uwe,
> 
> is anyone working on a fix to the problem with the auxEOF in version 4.9.3 ?
> 
> In the attached tar file you will find a reduced accessors.gla, accessors.specs
> and a script file.
> 
> When I derive
> 
> accessors.specs +cc='g++' +cc_flags='-O2' +cxx_flags='-O2' :exe :help
> accessors.specs +cc='g++' +cc_flags='-O2' +cxx_flags='-O2' :source >src
> 
> then the auxEOF error occurs, and auxEOF.c is not part of the generated sources.
> 
> ---
> 
> It does not occur, if I derive
> 
> accessors.specs +cc='gcc' +cc_flags='-O2' +cxx_flags='-O2' :exe :help
> accessors.specs +cc='gcc' +cc_flags='-O2' +cxx_flags='-O2' :source >src
> 
> and auxEOF.c can be found in src.
> 
> Regards,
> Thomas
> 
> 
> 
> On 2/9/25 13:12, uwe wrote:
>>> Am 24.01.2025 um 16:10 schrieb Freelance Roemke<fre...@ro...>:
>>> 
>>> Hi all,
>>> 
>>> a short update to my last question:
>>> 
>>> The problem with the auxEOF also occurs when eli is used in a freshly
>>> setup Debian 12 ( ./symlinks;./configure;make; make install )
>>> 
>>> ---
>>> 
>>> On top, there seems to be a problem with :gorto (in 4.9.3 and apparently also
>>> in 4.9.1). I don't use that tool much, but when I derive :gorto       now, then ligaGorto
>>> crashes with a segmentation fault.
>> Thank you for your information. But I’m sorry to say that we won’t be able to
>> support Gorto anymore.
>> Regards
>> 	Uwe
> 
> <accessors.tar.gz>

Re: [Eli-project-users] auxEOF and :gorto

[Freelance R. <fre...@ro...>]

Thanks Uwe,

is anyone working on a fix to the problem with the auxEOF in version 
4.9.3 ?

In the attached tar file you will find a reduced accessors.gla, 
accessors.specs
and a script file.

When I derive

accessors.specs +cc='g++' +cc_flags='-O2' +cxx_flags='-O2' :exe :help
accessors.specs +cc='g++' +cc_flags='-O2' +cxx_flags='-O2' :source >src

then the auxEOF error occurs, and auxEOF.c is not part of the generated 
sources.

---

It does not occur, if I derive

accessors.specs +cc='gcc' +cc_flags='-O2' +cxx_flags='-O2' :exe :help
accessors.specs +cc='gcc' +cc_flags='-O2' +cxx_flags='-O2' :source >src

and auxEOF.c can be found in src.

Regards,
Thomas



On 2/9/25 13:12, uwe wrote:
>> Am 24.01.2025 um 16:10 schrieb Freelance Roemke<fre...@ro...>:
>>
>> Hi all,
>>
>> a short update to my last question:
>>
>> The problem with the auxEOF also occurs when eli is used in a freshly
>> setup Debian 12 ( ./symlinks;./configure;make; make install )
>>
>> ---
>>
>> On top, there seems to be a problem with :gorto (in 4.9.3 and apparently also
>> in 4.9.1). I don't use that tool much, but when I derive :gorto       now, then ligaGorto
>> crashes with a segmentation fault.
> Thank you for your information. But I’m sorry to say that we won’t be able to
> support Gorto anymore.
> Regards
> 	Uwe

Re: [Eli-project-users] auxEOF and :gorto

[uwe <uw...@un...>]

> Am 24.01.2025 um 16:10 schrieb Freelance Roemke <fre...@ro...>:
> 
> Hi all,
> 
> a short update to my last question:
> 
> The problem with the auxEOF also occurs when eli is used in a freshly
> setup Debian 12 ( ./symlinks;./configure;make; make install )
> 
> ---
> 
> On top, there seems to be a problem with :gorto (in 4.9.3 and apparently also
> in 4.9.1). I don't use that tool much, but when I derive :gorto       now, then ligaGorto 
> crashes with a segmentation fault.

Thank you for your information. But I’m sorry to say that we won’t be able to
support Gorto anymore.
Regards
	Uwe

> 
> On my arch system (6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 x86_64 GNU/Linux), 
> coredumpctl reports 
> 
>        ...
>             Message: Process 2228527 (ligaGorto.exe) of user 1000 dumped core.
>                 
>                 Stack trace of thread 2228527:
>                 #0  0x00005967f3ac7856 n/a (n/a + 0x0)
>                 #1  0x0000790264820ab8 XtAppProcessEvent (libXt.so.6 + 0x2dab8)
>                 #2  0x0000790264814d7c XtAppMainLoop (libXt.so.6 + 0x21d7c)
>                 #3  0x00005967f3ab227f n/a (n/a + 0x0)
>                 ELF object binary architecture: AMD x86-64
> 
> and on Debian 12 (6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux),
> gdb reports:
> 
> 
>     Program terminated with signal SIGSEGV, Segmentation fault.
> 
>     warning: Section `.reg-xstate/2553' in core file too small.
>     #0  0x000055edd0413982 in GenTreeDeps (ae=0x55ede5000000) at bottomup.c:545
>     545       foreachinSEQDef(defseqOfAttrEval(ae), defs, d)
> 
> As of gdb, the values of defs and d are not available:
> 
>     (gdb) print defs
>     $1 = <optimized out>
>     (gdb) print d
>     $2 = <optimized out>
>     (gdb) bt
>     #0  0x000055edd0413982 in GenTreeDeps (ae=0x55ede5000000) at bottomup.c:545
>     #1  0x000055edd0403b44 in DoWork (client_data=<optimized out>) at Order.c:230
>     #2  0x00007f5824868fb0 in ?? () from /lib/x86_64-linux-gnu/libXt.so.6
>     #3  0x00007f582486ab05 in XtAppProcessEvent () from /lib/x86_64-linux-gnu/libXt.so.6
>     #4  0x00007f582485f253 in XtAppMainLoop () from /lib/x86_64-linux-gnu/libXt.so.6
>     #5  0x000055edd03ff878 in main (argc=<optimized out>, argv=<optimized out>) at Main.c:205
> 
> 
> Libraries:
>     arch: libXt (1.3.1-1) and libxaw (1.0.16-1)
>     debian:libXt (1.2.1-1) and libxaw (1.0.14-1)
> 
> The arch libXt was updated last November (with sources coming from freedesktop.org),
> while the Debian site just states that an upstream version is available.
> 
> Regards,
> Thomas
> 
> 
> 
> 
> 
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] auxEOF and :gorto

[Freelance R. <fre...@ro...>]

Hi all,

a short update to my last question:

The problem with the auxEOF also occurs when eli is used in a freshly
setup Debian 12 ( ./symlinks;./configure;make; make install )

---

On top, there seems to be a problem with :gorto (in 4.9.3 and apparently 
also
in 4.9.1). I don't use that tool much, but when I derive :gorto now, 
then ligaGorto
crashes with a segmentation fault.

On my arch system (6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 
2025 02:26:57 +0000 x86_64 GNU/Linux),
_coredumpctl_ reports

        ...
             Message: Process 2228527 (ligaGorto.exe) of user 1000 
dumped core.

                 Stack trace of thread 2228527:
                 #0  0x00005967f3ac7856 n/a (n/a + 0x0)
                 #1  0x0000790264820ab8 XtAppProcessEvent (libXt.so.6 + 
0x2dab8)
                 #2  0x0000790264814d7c XtAppMainLoop (libXt.so.6 + 0x21d7c)
                 #3  0x00005967f3ab227f n/a (n/a + 0x0)
                 ELF object binary architecture: AMD x86-64

and on Debian 12 (6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 
(2025-01-12) x86_64 GNU/Linux),
_gdb_ reports:


     Program terminated with signal SIGSEGV, Segmentation fault.

     warning: Section `.reg-xstate/2553' in core file too small.
     #0  0x000055edd0413982 in GenTreeDeps (ae=0x55ede5000000) at 
bottomup.c:545
     545 foreachinSEQDef(defseqOfAttrEval(ae), defs, d)

As of gdb, the values of defs and d are not available:

     (gdb) print defs
     $1 = <optimized out>
     (gdb) print d
     $2 = <optimized out>
     (gdb) bt
     #0  0x000055edd0413982 in GenTreeDeps (ae=0x55ede5000000) at 
bottomup.c:545
     #1  0x000055edd0403b44 in DoWork (client_data=<optimized out>) at 
Order.c:230
     #2  0x00007f5824868fb0 in ?? () from /lib/x86_64-linux-gnu/libXt.so.6
     #3  0x00007f582486ab05 in XtAppProcessEvent () from 
/lib/x86_64-linux-gnu/libXt.so.6
     #4  0x00007f582485f253 in XtAppMainLoop () from 
/lib/x86_64-linux-gnu/libXt.so.6
     #5  0x000055edd03ff878 in main (argc=<optimized out>, 
argv=<optimized out>) at Main.c:205


Libraries:
     arch: libXt (1.3.1-1) and libxaw (1.0.16-1)
     debian:libXt (1.2.1-1) and libxaw (1.0.14-1)

The arch libXt was updated last November (with sources coming from 
freedesktop.org),
while the Debian site just states that an upstream version is available.

Regards,
Thomas

[Eli-project-users] Version 4.9.3 and glahead/auxEOF

[Freelance R. <fre...@ro...>]

Happy new year to all,

yesterday I noticed that there is a new eli release (4.9.3), and I 
compiled it on my arch system with my own PKGBUILD and the new default 
options for AUR packages¹. A lot of warning messages came up (I can 
provide them, if necessary), but in the end, the executables were built.

So far, so good ... However, for many of my projects (that worked fine 
with 4.9.1), I now get a linker error:

      glahead.c.c.o: in function `glalex(int*)':
      glahead.c:(.text+0xe8a): undefined reference to `auxEOF'
      collect2: error: ld returned 1 exit status

As of the generated sources, auxEOF is present in

     ScanProc.h:extern char *auxEOF ELI_ARG((char *, int));
     xcode.h:   p = TokenStart = TokenEnd = auxEOF(TokenStart, 0);

only.

How do I have to change my specs now?

Thomas



---

¹ The arch compiler options are

-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions 
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security 
-fstack-clash-protection -fcf-protection -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g 
-ffile-prefix-map= 
/home/freelance/self_compiled/eli-git/src=/usr/src/debug/eli-git -flto=auto

The lto options had to be disabled, otherwise eli will fail to compile 
at ofiles already.

However, the main problem occursalso when only "-O2" is used.

Re: [Eli-project-users] Fwd: 4.9.1

[Allen, N. T. <al...@hu...>]

I just pulled the latest changes and rebuilt and installed Eli. I had 
previously installed 4.9.0. After building, I started eli and got:

    nta891@EAS-NALLEN1L ~/Port/Eli
    $ eli
    Eli Version 4.9.0 (? for help, ^D to exit)
    ->

Then I ran:

    $ eli -R
    Cache at /home/nta891/.ODIN/EAS-NALLEN1L has been reset.
    Clearing packages for /home/nta891/.ODIN/EAS-NALLEN1L.
    Installing package /usr/local/lib/Eli/Adt/1.0.0.
    ...
    /home/nta891/.ODIN/EAS-NALLEN1L packages compiled.
    Eli Version 4.9.1 (? for help, ^D to exit)
    ->



On 7/15/2023 9:00 AM, William M Waite wrote:
> I tried on both of my machines:
>
> MacAir (Ventura):
>
> doyle% ping git.code.sf.net
> PING git.code.sf.net (204.68.111.16): 56 data bytes
> doyle% git --version
> git version 2.39.2 (Apple Git-143)
> doyle%
>
> Dell (Gentoo linux):
>
> monk% ping git.code.sf.net
> PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.
> monk% git --version
> git version 2.41.0
> monk%
>
> However, something interesting happened when I cloned on the Dell — I 
> got a version that said it was 4.9.0!
>
> I’m sure that SourceForge has a number of mirrors round about the net, 
> and accesses that you make may be cached by intermediate servers.  It 
> may be that we’re simply seeing propagation delays and synchronization 
> problems.  When I first updated the online documentation for 4.9, I 
> kept seeing 4.8 documentation.  But when I asked Norton Allen to try 
> it, he got 4.9.  I also got 4.9 when I tried it several days later.
>
> There is probably a good reason that SourceForge has the option of 
> delaying an announcement for three days...
>
>> Begin forwarded message:
>>
>> *From: *Thomas Roemke <tr...@gm...>
>> *Subject: **Fwd: [Eli-project-users] Fwd: 4.9.1*
>> *Date: *July 15, 2023 at 00:21:46 MDT
>> *To: *William M Waite <wil...@Co...>
>>
>>
>> William, the mailing list refused this answer.
>> That's why I sent it here again.
>>
>> Regards,  Thomas
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	Re: [Eli-project-users] Fwd: 4.9.1
>> Date: 	Sat, 15 Jul 2023 08:19:25 +0200
>> From: 	Freelance Roemke <fre...@ro...> 
>> <mailto:fre...@ro...>
>> To: 	eli...@li... 
>> <mailto:eli...@li...>
>>
>>
>>
>> Hi William,
>>
>> well, actually there is a small difference, at least on the command lines
>>
>> You used
>>
>> git clone https://git.code.sf.net/p/eli-project/ 
>> <https://git.code.sf.net/p/eli-project/>*eli eli-project-eli*
>>
>> while I use
>>
>> git clone http://git.code.sf.net/p/eli-project/ 
>> <http://git.code.sf.net/p/eli-project/>*eli#branch=master*"
>> (in my PKGBUILD, which results in 4.8.1 as well)
>>
>> -or-
>>
>> git clone http://git.code.sf.net/p/eli-project/ 
>> <http://git.code.sf.net/p/eli-project/>*eli*
>> (in my example)
>>
>> However, that doesn't seem to have a big impact.
>>
>> Even, if I use your version, the reported version is still 4.8.1 (see 
>> attached typescript file)
>>
>> What is the result of
>>
>> $ ping git.code.sf.net
>> PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.
>>
>> $ git --version
>> git version 2.41.0
>>
>> on your system?
>>
>> Regards,
>> Thomas
>>
>>
>> On 7/14/23 22:43, William M Waite wrote:
>>> Thomas,
>>>
>>> I just did what you said that you did: cloned a new tree and 
>>> compiled Eli.  The result is attached — I got a message saying that 
>>> I had 4.9.1.
>>>
>>> Just for grins, here are the last 10 commits on the cloned repository:
>>>
>>> doyle% git log --oneline -10
>>> b7a74fde (HEAD -> master, origin/master, origin/HEAD) Generate a new 
>>> configure script
>>> cb8fc7a2 Upgrade the Include module
>>> 46a515e9 Correct cross referencing errors
>>> b87b6e34 Generate a new configure script
>>> 9abaebd8 Correct Cola derived Srcs
>>> 5d949713 Correct the HTML page titles
>>> d9912171 Integrate Release Notes for Eli 4.9
>>> a520c358 Upgrade to Odin_1_17_13
>>> ef358622 Allow the user to avoid the internal Odin processor
>>> 8c4dcc4b Allow the user to configure with specified CFLAGS
>>> doyle%
>>>
>>> They match the last 10 commits in my local repository.
>>>
>>> Bill Waite
>>>
>>>
>>>> Begin forwarded message:
>>>>
>>>> *From: *Freelance Roemke <fre...@ro...> 
>>>> <mailto:fre...@ro...>
>>>> *Subject: **Re: [Eli-project-users] 4.9.1*
>>>> *Date: *July 12, 2023 at 09:18:19 MDT
>>>> *To: *eli...@li... 
>>>> <mailto:eli...@li...>
>>>>
>>>>
>>>> Hi William,
>>>>
>>>> I'm sorry, I've been too busy to answer your other mail yet,
>>>> but just a short note about this one.
>>>>
>>>> A minute ago, I cloned a new tree, and compiled Eli, and
>>>> expected it to be the new version, but when I call the eli
>>>> executable in the source tree
>>>>
>>>> {967} > ./bin/eli
>>>> Eli Version 4.8.1 (? for help, ^D to exit)
>>>> ->
>>>>
>>>> it still reports version 4.8.1
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> $ git clone http://git.code.sf.net/p/eli-project/eli 
>>>> <http://git.code.sf.net/p/eli-project/eli>
>>>> $ cd eli
>>>> $ ./symlinks
>>>> $ ./configure
>>>> $ make
>>>> $ ./bin/eli
>>>>
>>>>
>>>>
>>>> On 7/11/23 03:35, William M Waite wrote:
>>>>> Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.
>>>>>
>>>>> _______________________________________________
>>>>> Eli-project-users mailing list
>>>>> Eli...@li...  <mailto:Eli...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/eli-project-users  <https://lists.sourceforge.net/lists/listinfo/eli-project-users>
>>>>
>>>> _______________________________________________
>>>> Eli-project-users mailing list
>>>> Eli...@li... 
>>>> <mailto:Eli...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/eli-project-users 
>>>> <https://lists.sourceforge.net/lists/listinfo/eli-project-users>
>>>
>>>
>>>
>>> _______________________________________________
>>> Eli-project-users mailing list
>>> Eli...@li...  <mailto:Eli...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/eli-project-users  <https://lists.sourceforge.net/lists/listinfo/eli-project-users>
>>
>
>
>
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] Fwd: 4.9.1

[William M W. <wil...@Co...>]

If you have an existing eli in your path, you need to be careful that you get the correct version to execute.  When you build a new eli, if you don’t “install” it, it’s a good idea to begin by running the command “./eli -R” in the directory in which you built that new eli.

We do not give that advice at the end of the build process because we assume that we are dealing with a new user, and therefore no old versions of Eli are hanging around.

Begin forwarded message:

From: Freelance Roemke <fre...@ro...>
Subject: Re: [Eli-project-users] Fwd: 4.9.1
Date: July 16, 2023 at 12:01:26 MDT
To: William M Waite <wil...@Co...>


Hi all,

I just had a look at the config.h in the Eli subdir, and indeed that one contains

#define PACKAGE_STRING "Eli 4.9.1"
#define PACKAGE_VERSION "4.9.1"

However, the resulting ./bin/eli still reported version 4.8.1.

Then I uninstalled the old package, and tried ./bin/eli again

It reported problems with the $HOME/.ODIN directory

/home/tomtom/y/eli/Odin/bin/odin: line 152: /home/tomtom/.ODIN/warp10/PKGS/odin/odin.exe: No such file or directory

so for some reason, the script wanted to start the odin.exe in the cache.

After removing that whole .ODIN directory, ./bin/eli now reports 4.9.1

Regards,
Thomas


On 7/15/23 15:00, William M Waite wrote:
I tried on both of my machines:

MacAir (Ventura):

doyle% ping git.code.sf.net
PING git.code.sf.net (204.68.111.16): 56 data bytes
doyle% git --version
git version 2.39.2 (Apple Git-143)
doyle%

Dell (Gentoo linux):

monk% ping git.code.sf.net
PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.
monk% git --version
git version 2.41.0
monk%

However, something interesting happened when I cloned on the Dell — I got a version that said it was 4.9.0!

I’m sure that SourceForge has a number of mirrors round about the net, and accesses that you make may be cached by intermediate servers.  It may be that we’re simply seeing propagation delays and synchronization problems.  When I first updated the online documentation for 4.9, I kept seeing 4.8 documentation.  But when I asked Norton Allen to try it, he got 4.9.  I also got 4.9 when I tried it several days later.

There is probably a good reason that SourceForge has the option of delaying an announcement for three days...

Begin forwarded message:

From: Thomas Roemke <tr...@gm...><mailto:tr...@gm...>
Subject: Fwd: [Eli-project-users] Fwd: 4.9.1
Date: July 15, 2023 at 00:21:46 MDT
To: William M Waite <wil...@Co...><mailto:wil...@Co...>


William, the mailing list refused this answer.
That's why I sent it here again.

Regards,  Thomas



-------- Forwarded Message --------
Subject:        Re: [Eli-project-users] Fwd: 4.9.1
Date:   Sat, 15 Jul 2023 08:19:25 +0200
From:   Freelance Roemke <fre...@ro...><mailto:fre...@ro...>
To:     eli...@li...<mailto:eli...@li...>


Hi William,

well, actually there is a small difference, at least on the command lines

You used

git clone https://git.code.sf.net/p/eli-project/eli eli-project-eli

while I use

git clone http://git.code.sf.net/p/eli-project/eli#branch=master"
(in my PKGBUILD, which results in 4.8.1 as well)

-or-

git clone http://git.code.sf.net/p/eli-project/eli
(in my example)

However, that doesn't seem to have a big impact.

Even, if I use your version, the reported version is still 4.8.1 (see attached typescript file)

What is the result of

$ ping git.code.sf.net
PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.

$ git --version
git version 2.41.0

on your system?

Regards,
Thomas


On 7/14/23 22:43, William M Waite wrote:
Thomas,

I just did what you said that you did: cloned a new tree and compiled Eli.  The result is attached — I got a message saying that I had 4.9.1.

Just for grins, here are the last 10 commits on the cloned repository:

doyle% git log --oneline -10
b7a74fde (HEAD -> master, origin/master, origin/HEAD) Generate a new configure script
cb8fc7a2 Upgrade the Include module
46a515e9 Correct cross referencing errors
b87b6e34 Generate a new configure script
9abaebd8 Correct Cola derived Srcs
5d949713 Correct the HTML page titles
d9912171 Integrate Release Notes for Eli 4.9
a520c358 Upgrade to Odin_1_17_13
ef358622 Allow the user to avoid the internal Odin processor
8c4dcc4b Allow the user to configure with specified CFLAGS
doyle%

They match the last 10 commits in my local repository.

Bill Waite


Begin forwarded message:

From: Freelance Roemke <fre...@ro...><mailto:fre...@ro...>
Subject: Re: [Eli-project-users] 4.9.1
Date: July 12, 2023 at 09:18:19 MDT
To: eli...@li...<mailto:eli...@li...>


Hi William,

I'm sorry, I've been too busy to answer your other mail yet,
but just a short note about this one.

A minute ago, I cloned a new tree, and compiled Eli, and
expected it to be the new version, but when I call the eli
executable in the source tree

{967} > ./bin/eli
Eli Version 4.8.1 (? for help, ^D to exit)
->

it still reports version 4.8.1

Regards,
Thomas





$ git clone http://git.code.sf.net/p/eli-project/eli
$ cd eli
$ ./symlinks
$ ./configure
$ make
$ ./bin/eli



On 7/11/23 03:35, William M Waite wrote:

Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.

_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users


_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users





_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users







_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] Fwd: 4.9.1

[William M W. <wil...@Co...>]

I tried on both of my machines:

MacAir (Ventura):

doyle% ping git.code.sf.net
PING git.code.sf.net (204.68.111.16): 56 data bytes
doyle% git --version
git version 2.39.2 (Apple Git-143)
doyle%

Dell (Gentoo linux):

monk% ping git.code.sf.net
PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.
monk% git --version
git version 2.41.0
monk%

However, something interesting happened when I cloned on the Dell — I got a version that said it was 4.9.0!

I’m sure that SourceForge has a number of mirrors round about the net, and accesses that you make may be cached by intermediate servers.  It may be that we’re simply seeing propagation delays and synchronization problems.  When I first updated the online documentation for 4.9, I kept seeing 4.8 documentation.  But when I asked Norton Allen to try it, he got 4.9.  I also got 4.9 when I tried it several days later.

There is probably a good reason that SourceForge has the option of delaying an announcement for three days...

Begin forwarded message:

From: Thomas Roemke <tr...@gm...>
Subject: Fwd: [Eli-project-users] Fwd: 4.9.1
Date: July 15, 2023 at 00:21:46 MDT
To: William M Waite <wil...@Co...>


William, the mailing list refused this answer.
That's why I sent it here again.

Regards,  Thomas



-------- Forwarded Message --------
Subject:        Re: [Eli-project-users] Fwd: 4.9.1
Date:   Sat, 15 Jul 2023 08:19:25 +0200
From:   Freelance Roemke <fre...@ro...><mailto:fre...@ro...>
To:     eli...@li...<mailto:eli...@li...>


Hi William,

well, actually there is a small difference, at least on the command lines

You used

git clone https://git.code.sf.net/p/eli-project/eli eli-project-eli

while I use

git clone http://git.code.sf.net/p/eli-project/eli#branch=master"
(in my PKGBUILD, which results in 4.8.1 as well)

-or-

git clone http://git.code.sf.net/p/eli-project/eli
(in my example)

However, that doesn't seem to have a big impact.

Even, if I use your version, the reported version is still 4.8.1 (see attached typescript file)

What is the result of

$ ping git.code.sf.net
PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.

$ git --version
git version 2.41.0

on your system?

Regards,
Thomas


On 7/14/23 22:43, William M Waite wrote:
Thomas,

I just did what you said that you did: cloned a new tree and compiled Eli.  The result is attached — I got a message saying that I had 4.9.1.

Just for grins, here are the last 10 commits on the cloned repository:

doyle% git log --oneline -10
b7a74fde (HEAD -> master, origin/master, origin/HEAD) Generate a new configure script
cb8fc7a2 Upgrade the Include module
46a515e9 Correct cross referencing errors
b87b6e34 Generate a new configure script
9abaebd8 Correct Cola derived Srcs
5d949713 Correct the HTML page titles
d9912171 Integrate Release Notes for Eli 4.9
a520c358 Upgrade to Odin_1_17_13
ef358622 Allow the user to avoid the internal Odin processor
8c4dcc4b Allow the user to configure with specified CFLAGS
doyle%

They match the last 10 commits in my local repository.

Bill Waite


Begin forwarded message:

From: Freelance Roemke <fre...@ro...><mailto:fre...@ro...>
Subject: Re: [Eli-project-users] 4.9.1
Date: July 12, 2023 at 09:18:19 MDT
To: eli...@li...<mailto:eli...@li...>


Hi William,

I'm sorry, I've been too busy to answer your other mail yet,
but just a short note about this one.

A minute ago, I cloned a new tree, and compiled Eli, and
expected it to be the new version, but when I call the eli
executable in the source tree

{967} > ./bin/eli
Eli Version 4.8.1 (? for help, ^D to exit)
->

it still reports version 4.8.1

Regards,
Thomas





$ git clone http://git.code.sf.net/p/eli-project/eli
$ cd eli
$ ./symlinks
$ ./configure
$ make
$ ./bin/eli



On 7/11/23 03:35, William M Waite wrote:

Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.

_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users


_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users





_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users

Re: [Eli-project-users] Fwd: 4.9.1

[Freelance R. <fre...@ro...>]

Hi William,

well, actually there is a small difference, at least on the command lines

You used

git clone https://git.code.sf.net/p/eli-project/*eli eli-project-eli*

while I use

git clone http://git.code.sf.net/p/eli-project/*eli#branch=master*"
(in my PKGBUILD, which results in 4.8.1 as well)

-or-

git clone http://git.code.sf.net/p/eli-project/*eli*
(in my example)

However, that doesn't seem to have a big impact.

Even, if I use your version, the reported version is still 4.8.1 (see 
attached typescript file)

What is the result of

$ ping git.code.sf.net
PING git.code.sf.net (204.68.111.16) 56(84) bytes of data.

$ git --version
git version 2.41.0

on your system?

Regards,
Thomas


On 7/14/23 22:43, William M Waite wrote:
> Thomas,
>
> I just did what you said that you did: cloned a new tree and compiled 
> Eli.  The result is attached — I got a message saying that I had 4.9.1.
>
> Just for grins, here are the last 10 commits on the cloned repository:
>
> doyle% git log --oneline -10
> b7a74fde (HEAD -> master, origin/master, origin/HEAD) Generate a new 
> configure script
> cb8fc7a2 Upgrade the Include module
> 46a515e9 Correct cross referencing errors
> b87b6e34 Generate a new configure script
> 9abaebd8 Correct Cola derived Srcs
> 5d949713 Correct the HTML page titles
> d9912171 Integrate Release Notes for Eli 4.9
> a520c358 Upgrade to Odin_1_17_13
> ef358622 Allow the user to avoid the internal Odin processor
> 8c4dcc4b Allow the user to configure with specified CFLAGS
> doyle%
>
> They match the last 10 commits in my local repository.
>
> Bill Waite
>
>
>> Begin forwarded message:
>>
>> *From: *Freelance Roemke <fre...@ro...>
>> *Subject: **Re: [Eli-project-users] 4.9.1*
>> *Date: *July 12, 2023 at 09:18:19 MDT
>> *To: *eli...@li...
>>
>>
>> Hi William,
>>
>> I'm sorry, I've been too busy to answer your other mail yet,
>> but just a short note about this one.
>>
>> A minute ago, I cloned a new tree, and compiled Eli, and
>> expected it to be the new version, but when I call the eli
>> executable in the source tree
>>
>> {967} > ./bin/eli
>> Eli Version 4.8.1 (? for help, ^D to exit)
>> ->
>>
>> it still reports version 4.8.1
>>
>> Regards,
>> Thomas
>>
>>
>>
>>
>>
>> $ git clone http://git.code.sf.net/p/eli-project/eli 
>> <http://git.code.sf.net/p/eli-project/eli>
>> $ cd eli
>> $ ./symlinks
>> $ ./configure
>> $ make
>> $ ./bin/eli
>>
>>
>>
>> On 7/11/23 03:35, William M Waite wrote:
>>> Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.
>>>
>>> _______________________________________________
>>> Eli-project-users mailing list
>>> Eli...@li...  <mailto:Eli...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/eli-project-users  <https://lists.sourceforge.net/lists/listinfo/eli-project-users>
>>
>> _______________________________________________
>> Eli-project-users mailing list
>> Eli...@li...
>> https://lists.sourceforge.net/lists/listinfo/eli-project-users
>
>
>
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] Fwd: 4.9.1

[William M W. <wil...@Co...>]

Thomas,

I just did what you said that you did: cloned a new tree and compiled Eli.  The result is attached — I got a message saying that I had 4.9.1.

Just for grins, here are the last 10 commits on the cloned repository:

doyle% git log --oneline -10
b7a74fde (HEAD -> master, origin/master, origin/HEAD) Generate a new configure script
cb8fc7a2 Upgrade the Include module
46a515e9 Correct cross referencing errors
b87b6e34 Generate a new configure script
9abaebd8 Correct Cola derived Srcs
5d949713 Correct the HTML page titles
d9912171 Integrate Release Notes for Eli 4.9
a520c358 Upgrade to Odin_1_17_13
ef358622 Allow the user to avoid the internal Odin processor
8c4dcc4b Allow the user to configure with specified CFLAGS
doyle%

They match the last 10 commits in my local repository.

Bill Waite


Begin forwarded message:

From: Freelance Roemke <fre...@ro...>
Subject: Re: [Eli-project-users] 4.9.1
Date: July 12, 2023 at 09:18:19 MDT
To: eli...@li...


Hi William,

I'm sorry, I've been too busy to answer your other mail yet,
but just a short note about this one.

A minute ago, I cloned a new tree, and compiled Eli, and
expected it to be the new version, but when I call the eli
executable in the source tree

{967} > ./bin/eli
Eli Version 4.8.1 (? for help, ^D to exit)
->

it still reports version 4.8.1

Regards,
Thomas





$ git clone http://git.code.sf.net/p/eli-project/eli
$ cd eli
$ ./symlinks
$ ./configure
$ make
$ ./bin/eli



On 7/11/23 03:35, William M Waite wrote:

Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.

_______________________________________________
Eli-project-users mailing list
Eli...@li...<mailto:Eli...@li...>
https://lists.sourceforge.net/lists/listinfo/eli-project-users


_______________________________________________
Eli-project-users mailing list
Eli...@li...
https://lists.sourceforge.net/lists/listinfo/eli-project-users

Re: [Eli-project-users] 4.9.1

[Freelance R. <fre...@ro...>]

Hi William,

I'm sorry, I've been too busy to answer your other mail yet,
but just a short note about this one.

A minute ago, I cloned a new tree, and compiled Eli, and
expected it to be the new version, but when I call the eli
executable in the source tree

{967} > ./bin/eli
Eli Version 4.8.1 (? for help, ^D to exit)
->

it still reports version 4.8.1

Regards,
Thomas





$ git clone http://git.code.sf.net/p/eli-project/eli
$ cd eli
$ ./symlinks
$ ./configure
$ make
$ ./bin/eli



On 7/11/23 03:35, William M Waite wrote:
> Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.
>
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] 4.9.1

[William M W. <wil...@Co...>]

Eli 4.9.1 has been released, both in git and as a tarball.  The major change is in the documentation, where there were a lot of index and cross-referencing errors.  I updated the on-line documentation as well as making the releases.

[Eli-project-users] Online documentation -- and a warning

[William M W. <wil...@Co...>]

The online documentation for Eli 4.9 is now available.  Use the “Manuals” link on “eli-project.sourceforge.net <http://eli-project.sourceforge.net/>” to access it.  Of course that documentation is also available in the distribution’s “doc” directory for use locally on your computer.

We have had some reports of segmentation faults during system build, due to problems with C compiler “optimizations”.  The configuration process sets the optimization level for the compiler based on information that it extracts from the environment on your computer.  If you encounter a segmentation fault during the system build, you should try configuring without specifying an explicit optimization level:

	make distclean
	./configure CFLAGS=‘-g’

With this configuration parameter, the C compiler will use its default optimization level as well as providing information for the debugger.

The "CFLAGS=“ configuration parameter is in addition to any other configuration parameters you may desire (see the README file at the top level).

[Eli-project-users] Version 4.9.0

[William M W. <wil...@Co...>]

I have released a new version of Eli that avoids all of the strict-prototype errors and includes some other improvements.  I updated the git repository, but I was unable to upload the release’s online documentation due to an rsync problem.  The documentation incorporated in the distribution tar file corresponds to the current release.  I have submitted a trouble ticket to SourceForge, and hope that the rsync problem will be resolved soon.

[Eli-project-users] Eli 4.8.2

[William M W. <wil...@Co...>]

I’ve uploaded a new distribution, Eli 4.8.2, to SourceForge.  This distribution is essentially a mirror of the latest state of the Git repository.  It contains the bug fixes that have been made since the release of Eli 4.8.1.

I verified Eli 4.8.2 on a Mac Air with an M1 chip under Mac OS Ventura 13.3, and on a Dell Dimension 2400 running Gentoo Linux.  Here is the information about the compilers on the two machines:

——————————————————————
doyle% gcc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

monk% gcc --version
gcc (Gentoo 12.2.1_p20230121-r1 p10) 12.2.1 20230121
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
———————————————————————

I implemented the system from the tar file in each case, using the process described in README file in the top directory.  There was one well-known error report during execution of the command “./configure q”:

./configure: line 5550: #include: command not found
 
We haven’t been able to pinpoint the cause of the bogus line in file Eli/configure, but we haven’t spent much time on it because it does not affect the result.

I have not been able to reproduce any of Thomas’ errors.  It wasn’t clear to me whether the FunnelWeb error was during the system build or during an Eli session.  If the latter, I would appreciate getting the input data.

Remember that Eli maintains a cache, and also has a concept of a “Versioned package”.  These are not relevant during the system build, since full path names are always used by the scripts.  However, once the system has been built, you need to be well aware of where the command is coming from and what is the default cache.  See https://eli-project.sourceforge.net/elionline/sysadmin_toc.html.  Also, the command “which eli” can tell you whether you have a different command in your path.

Re: [Eli-project-users] Buildbraking Bug in Eli

[Thomas K. <tho...@in...>]

Dear Norton Allen, Dear Freelance Roemke,

finally everything is working also on my end, and the practical course 
can start.

Thank you again for your help and support.

Just a quick note regarding the missing files (l.lis,m.map,n.nop). They 
were not created by a call to fw.exe in fwTangle.sh due to a Unicode 
character (Ü) in the build path passed to FunnelWeb.  This error, 
however, was not emitted to any of the logs.

I suggest to either emit such errors or better permit Unicode characters 
in path names.

Regards and stay safe
--Thomas Kühn

Am 28.03.23 um 16:28 schrieb Norton Allen:
> I'm afraid I don't know how to update the release and am not sure I have 
> the necessary access to do so or the authority to decide what goes into 
> the latest release. Perhaps Prof. Waite will be able to it.
> 
> On 3/28/2023 10:11 AM, Thomas Kühn wrote:
>> Thank you, for this help. I was using the Downloadable Version of Eli 
>> from [1] as my students would.
>>
>> I'll test the recent version in master.
>>
>> Would you kindly let us know whether you could update the release to a 
>> 2021 version?
>>
>> Regards and stay safe
>> --Thomas Kühn
>>
>> [1]:https://sourceforge.net/projects/eli-project/
>>
>> Am 28.03.23 um 15:23 schrieb Norton Allen:
>>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>>> 1. Make both declarations `static` leading to `static struct 
>>>>>> obstack obstck;` in both files.
>>>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>>>> operate on the same state of `obstck`.
>>>>>
>>>>> static makes the declared object local to the current file or 
>>>>> function. What makes you think it becomes global?
>>>>>
>>>> My local source (~1.5 years old) has obstck declared static in both 
>>>> files. Are you getting your source from git?
>>>>
>>> Yes, Prof. Waite made that patch on 2021-09-09:
>>>
>>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/
>>>
>>>
>>

-- 
Martin-Luther-Universität Halle-Wittenberg
Nat. Fak. III - Institute of Computer Science
Chair for Software-Engineering and Programming Languages

Dr.-Ing. Thomas Kühn
Tenured Senior Researcher

Von-Seckendorff-Platz 1
Room: 323
D-06120 Halle, Germany

Phone: +49 345 55-24767
Fax: +49 345 55-27333
E-mail: tho...@in...

Re: [Eli-project-users] Buildbraking Bug in Eli

[William M W. <wil...@Co...>]

I’ve been lax about creating downloadable versions, relying on the git repository.  I’ll put up a new version in the Eli directory today.  It’s past time...

> On Mar 28, 2023, at 08:28, Norton Allen <al...@hu...> wrote:
> 
> I'm afraid I don't know how to update the release and am not sure I have the necessary access to do so or the authority to decide what goes into the latest release. Perhaps Prof. Waite will be able to it.
> 
> On 3/28/2023 10:11 AM, Thomas Kühn wrote:
>> Thank you, for this help. I was using the Downloadable Version of Eli from [1] as my students would.
>> 
>> I'll test the recent version in master.
>> 
>> Would you kindly let us know whether you could update the release to a 2021 version?
>> 
>> Regards and stay safe
>> --Thomas Kühn
>> 
>> [1]:https://sourceforge.net/projects/eli-project/
>> 
>> Am 28.03.23 um 15:23 schrieb Norton Allen:
>>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>>> 1. Make both declarations `static` leading to `static struct obstack obstck;` in both files.
>>>>>>      This however makes `obstck` global, i.e., both cexp and cccp operate on the same state of `obstck`.
>>>>> 
>>>>> static makes the declared object local to the current file or function. What makes you think it becomes global?
>>>>> 
>>>> My local source (~1.5 years old) has obstck declared static in both files. Are you getting your source from git?
>>>> 
>>> Yes, Prof. Waite made that patch on 2021-09-09:
>>> 
>>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/ 
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

Re: [Eli-project-users] Buildbraking Bug in Eli

[Freelance R. <fre...@ro...>]

Well, the package builds well with gcc 12.2.1 (just a second ago).
This might be a problem with your special gcc version.

@Mr Kühn: The best idea is to clean install the whole thing.

Are you sure you took the sources from

source=("${_pkgname}::git+http://git.code.sf.net/p/eli-project/eli#branch=master"


Thomas

PS If you had Arch, I could give you the PKGBUILD for that.



On 3/28/23 16:28, Norton Allen wrote:
> I'm afraid I don't know how to update the release and am not sure I 
> have the necessary access to do so or the authority to decide what 
> goes into the latest release. Perhaps Prof. Waite will be able to it.
>
> On 3/28/2023 10:11 AM, Thomas Kühn wrote:
>> Thank you, for this help. I was using the Downloadable Version of Eli 
>> from [1] as my students would.
>>
>> I'll test the recent version in master.
>>
>> Would you kindly let us know whether you could update the release to 
>> a 2021 version?
>>
>> Regards and stay safe
>> --Thomas Kühn
>>
>> [1]:https://sourceforge.net/projects/eli-project/
>>
>> Am 28.03.23 um 15:23 schrieb Norton Allen:
>>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>>> 1. Make both declarations `static` leading to `static struct 
>>>>>> obstack obstck;` in both files.
>>>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>>>> operate on the same state of `obstck`.
>>>>>
>>>>> static makes the declared object local to the current file or 
>>>>> function. What makes you think it becomes global?
>>>>>
>>>> My local source (~1.5 years old) has obstck declared static in both 
>>>> files. Are you getting your source from git?
>>>>
>>> Yes, Prof. Waite made that patch on 2021-09-09:
>>>
>>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/ 
>>>
>>>
>>>
>>
>
>
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

[Eli-project-users] Fwd: Buildbraking Bug in Eli

[Freelance R. <fre...@ro...>]

-------- Forwarded Message --------
Subject: 	Re: [Eli-project-users] Buildbraking Bug in Eli
Date: 	Tue, 28 Mar 2023 16:43:36 +0200
From: 	Freelance Roemke <fre...@ro...>
To: 	Norton Allen <al...@hu...>, Thomas Kühn 
<tho...@in...>, 
eli...@li...
CC: 	Prof. Dr. Wolf Zimmermann <zi...@in...>




Well, the package builds well with gcc 12.2.1 (just a second ago).
This might be a problem with your special gcc version.

@Mr Kühn: The best idea is to clean install the whole thing.

Are you sure you took the sources from

source=("${_pkgname}::git+http://git.code.sf.net/p/eli-project/eli#branch=master"


Thomas

PS If you had Arch, I could give you the PKGBUILD for that.



On 3/28/23 16:28, Norton Allen wrote:
> I'm afraid I don't know how to update the release and am not sure I 
> have the necessary access to do so or the authority to decide what 
> goes into the latest release. Perhaps Prof. Waite will be able to it.
>
> On 3/28/2023 10:11 AM, Thomas Kühn wrote:
>> Thank you, for this help. I was using the Downloadable Version of Eli 
>> from [1] as my students would.
>>
>> I'll test the recent version in master.
>>
>> Would you kindly let us know whether you could update the release to 
>> a 2021 version?
>>
>> Regards and stay safe
>> --Thomas Kühn
>>
>> [1]:https://sourceforge.net/projects/eli-project/
>>
>> Am 28.03.23 um 15:23 schrieb Norton Allen:
>>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>>> 1. Make both declarations `static` leading to `static struct 
>>>>>> obstack obstck;` in both files.
>>>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>>>> operate on the same state of `obstck`.
>>>>>
>>>>> static makes the declared object local to the current file or 
>>>>> function. What makes you think it becomes global?
>>>>>
>>>> My local source (~1.5 years old) has obstck declared static in both 
>>>> files. Are you getting your source from git?
>>>>
>>> Yes, Prof. Waite made that patch on 2021-09-09:
>>>
>>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/ 
>>>
>>>
>>>
>>
>
>
> _______________________________________________
> Eli-project-users mailing list
> Eli...@li...
> https://lists.sourceforge.net/lists/listinfo/eli-project-users

Re: [Eli-project-users] Buildbraking Bug in Eli

[Thomas K. <tho...@in...>]

I understand, unfortunately, I now see new errors when building eli 
related to missing l.lis, m.map and n.nop files all referenced in the 
Eli/pkg/fw/fwTangle.sh

For some reason they are not created in CACHE/JOB1 during the execution.

I will later try to simply create empty files during make, but assume 
this will just lead to further issues down the line?

Are the files properly created on your end, or could you reproduce this 
error in the current version of Eli (master)?

Thank you in advance.

Regards and stay safe
--Thomas Kühn

Am 28.03.23 um 16:28 schrieb Norton Allen:
> I'm afraid I don't know how to update the release and am not sure I have 
> the necessary access to do so or the authority to decide what goes into 
> the latest release. Perhaps Prof. Waite will be able to it.
> 
> On 3/28/2023 10:11 AM, Thomas Kühn wrote:
>> Thank you, for this help. I was using the Downloadable Version of Eli 
>> from [1] as my students would.
>>
>> I'll test the recent version in master.
>>
>> Would you kindly let us know whether you could update the release to a 
>> 2021 version?
>>
>> Regards and stay safe
>> --Thomas Kühn
>>
>> [1]:https://sourceforge.net/projects/eli-project/
>>
>> Am 28.03.23 um 15:23 schrieb Norton Allen:
>>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>>> 1. Make both declarations `static` leading to `static struct 
>>>>>> obstack obstck;` in both files.
>>>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>>>> operate on the same state of `obstck`.
>>>>>
>>>>> static makes the declared object local to the current file or 
>>>>> function. What makes you think it becomes global?
>>>>>
>>>> My local source (~1.5 years old) has obstck declared static in both 
>>>> files. Are you getting your source from git?
>>>>
>>> Yes, Prof. Waite made that patch on 2021-09-09:
>>>
>>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/
>>>
>>>
>>

-- 
Martin-Luther-Universität Halle-Wittenberg
Nat. Fak. III - Institute of Computer Science
Chair for Software-Engineering and Programming Languages

Dr.-Ing. Thomas Kühn
Tenured Senior Researcher

Von-Seckendorff-Platz 1
Room: 323
D-06120 Halle, Germany

Phone: +49 345 55-24767
Fax: +49 345 55-27333
E-mail: tho...@in...

Re: [Eli-project-users] Buildbraking Bug in Eli

[Norton A. <al...@hu...>]

I'm afraid I don't know how to update the release and am not sure I have 
the necessary access to do so or the authority to decide what goes into 
the latest release. Perhaps Prof. Waite will be able to it.

On 3/28/2023 10:11 AM, Thomas Kühn wrote:
> Thank you, for this help. I was using the Downloadable Version of Eli 
> from [1] as my students would.
>
> I'll test the recent version in master.
>
> Would you kindly let us know whether you could update the release to a 
> 2021 version?
>
> Regards and stay safe
> --Thomas Kühn
>
> [1]:https://sourceforge.net/projects/eli-project/
>
> Am 28.03.23 um 15:23 schrieb Norton Allen:
>> On 3/28/2023 9:17 AM, Norton Allen wrote:
>>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>>> 1. Make both declarations `static` leading to `static struct 
>>>>> obstack obstck;` in both files.
>>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>>> operate on the same state of `obstck`.
>>>>
>>>> static makes the declared object local to the current file or 
>>>> function. What makes you think it becomes global?
>>>>
>>> My local source (~1.5 years old) has obstck declared static in both 
>>> files. Are you getting your source from git?
>>>
>> Yes, Prof. Waite made that patch on 2021-09-09:
>>
>> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/ 
>>
>>
>>
>

Re: [Eli-project-users] Buildbraking Bug in Eli

[Thomas K. <tho...@in...>]

Thank you, for this help. I was using the Downloadable Version of Eli 
from [1] as my students would.

I'll test the recent version in master.

Would you kindly let us know whether you could update the release to a 
2021 version?

Regards and stay safe
--Thomas Kühn

[1]:https://sourceforge.net/projects/eli-project/

Am 28.03.23 um 15:23 schrieb Norton Allen:
> On 3/28/2023 9:17 AM, Norton Allen wrote:
>> On 3/28/2023 9:04 AM, Norton Allen wrote:
>>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>>> 1. Make both declarations `static` leading to `static struct obstack 
>>>> obstck;` in both files.
>>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>>> operate on the same state of `obstck`.
>>>
>>> static makes the declared object local to the current file or 
>>> function. What makes you think it becomes global?
>>>
>> My local source (~1.5 years old) has obstck declared static in both 
>> files. Are you getting your source from git?
>>
> Yes, Prof. Waite made that patch on 2021-09-09:
> 
> https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/
> 
> 

-- 
Martin-Luther-Universität Halle-Wittenberg
Nat. Fak. III - Institute of Computer Science
Chair for Software-Engineering and Programming Languages

Dr.-Ing. Thomas Kühn
Tenured Senior Researcher

Von-Seckendorff-Platz 1
Room: 323
D-06120 Halle, Germany

Phone: +49 345 55-24767
Fax: +49 345 55-27333
E-mail: tho...@in...

Re: [Eli-project-users] Buildbraking Bug in Eli

[Norton A. <al...@hu...>]

On 3/28/2023 9:17 AM, Norton Allen wrote:
> On 3/28/2023 9:04 AM, Norton Allen wrote:
>> On 3/28/2023 3:06 AM, Thomas Kühn wrote:
>>> 1. Make both declarations `static` leading to `static struct obstack 
>>> obstck;` in both files.
>>>      This however makes `obstck` global, i.e., both cexp and cccp 
>>> operate on the same state of `obstck`.
>>
>> static makes the declared object local to the current file or 
>> function. What makes you think it becomes global?
>>
> My local source (~1.5 years old) has obstck declared static in both 
> files. Are you getting your source from git?
>
Yes, Prof. Waite made that patch on 2021-09-09:

https://sourceforge.net/p/eli-project/eli/ci/bc2d1109b52ab8c02f037bf4cae1d94d78e399ce/

Re: [Eli-project-users] Buildbraking Bug in Eli

[Norton A. <al...@hu...>]

On 3/28/2023 3:06 AM, Thomas Kühn wrote:
> 1. Make both declarations `static` leading to `static struct obstack 
> obstck;` in both files.
>      This however makes `obstck` global, i.e., both cexp and cccp 
> operate on the same state of `obstck`.

static makes the declared object local to the current file or function. 
What makes you think it becomes global?