newbie compiling problems

GPT4 seems to handle it:

The error you’re encountering is related to the UNLINK macro. The issue seems to be with the (first) and (last) assignments within the macro. The macro expects first and last to be lvalues, meaning they need to be assignable. However, in your dispose_ban function, you’re passing expressions to the macro that are not lvalues.

The error occurs because the expressions (type==BAN_SITE)?first_ban:(type==BAN_CLASS)?first_ban_class:first_ban_race and (type==BAN_SITE)?last_ban:(type==BAN_CLASS)?last_ban_class:last_ban_race used for first and last are conditional expressions. These are not lvalues because they don’t directly refer to a modifiable memory location. They evaluate to a value depending on the condition, but you cannot assign a value to them directly.

To resolve this issue, you might need to use temporary pointers that store the result of these conditional expressions. You can then pass these temporary pointers to the UNLINK macro. Here’s an example of how you might modify your dispose_ban function:

void dispose_ban(BAN_DATA *pban, int type)
{
    BAN_DATA **first_temp, **last_temp;

    if (!pban)
        return;

    if (type != BAN_SITE && type != BAN_CLASS && type != BAN_RACE)
    {
        bug("Dispose_ban: Unknown Ban Type %d.", type);
        return;
    }

    // Determine the correct first and last pointers based on the type
    if (type == BAN_SITE)
    {
        first_temp = &first_ban;
        last_temp = &last_ban;
    }
    else if (type == BAN_CLASS)
    {
        first_temp = &first_ban_class;
        last_temp = &last_ban_class;
    }
    else // BAN_RACE
    {
        first_temp = &first_ban_race;
        last_temp = &last_ban_race;
    }

    // Now use the temporary pointers in the UNLINK macro
    UNLINK(pban, *first_temp, *last_temp, next, prev);

    free_ban(pban);
    return;
}

In this modified version, first_temp and last_temp are pointers to pointers. They are set to point to the appropriate first_ban, first_ban_class, first_ban_race, last_ban, last_ban_class, or last_ban_race based on the type. When you pass *first_temp and *last_temp to the UNLINK macro, you are passing modifiable lvalues, which should resolve the error.

An alternative, and this is my idea and not ChatGPT’s, is to not try to do all three ban types in one line, but rather:

void dispose_ban(BAN_DATA *pban, int type)
{
    if (!pban)
        return;

    if (type == BAN_SITE)
    {
        UNLINK(pban, first_ban, last_ban, next, prev);
    }
    else if (type == BAN_CLASS)
    {
        UNLINK(pban, first_ban_class, last_ban_class, next, prev);
    }
    else if (type == BAN_RACE)
    {
        UNLINK(pban, first_ban_race, last_ban_race, next, prev);
    }
    else
    {
        bug("Dispose_ban: Unknown Ban Type %d.", type);
        return;
    }

    free_ban(pban);
    return;
}

Not sure. This is what ChatGPT had to say:

This error message and warning are coming from a Makefile used in compiling a C program with GCC (GNU Compiler Collection). Let’s break down what each part means:

1. Makefile:49: warning: ignoring prerequisites on suffix rule definition
   • This is a warning about the way a suffix rule is defined in your Makefile. Suffix rules are a way to define how to convert one type of file to another, based on their file extensions. For example, a rule to compile .c files into .o (object) files. The warning is likely because the prerequisites (dependencies) for a suffix rule are not specified correctly. This might not stop the make process but indicates potential issues in the Makefile.
2. gcc -c -O -g3 -Wall -Wuninitialized -DREQUESTS -DSMAUG -DNOCRYPT act_comm.c
   • This line is the actual command being executed. It’s calling gcc (the GNU C Compiler) to compile the act_comm.c source file. The flags used are:
     • -c: Compile and assemble, but do not link.
     • -O: Enable compiler optimizations.
     • -g3: Produce debugging information in the operating system’s native format.
     • -Wall: Enable all compiler’s warning messages.
     • -Wuninitialized: Warn if an uninitialized variable is used.
     • -DREQUESTS, -DSMAUG, -DNOCRYPT: Define these preprocessor macros.
3. make: *** [Makefile:49: act_comm.o] Error 1
   • This is the actual error message from make, indicating that the compilation failed. The Error 1 part is a general error code from gcc meaning that there were problems during the compilation. This error is associated with the target act_comm.o, which is defined on line 49 of the Makefile.

To resolve this issue, you will need to:

• Check the definition of the rule at line 49 in the Makefile. Ensure that the syntax is correct and all necessary prerequisites are specified.
• Look at the preceding lines of the output (not shown in your message) for any specific gcc error messages. These messages will provide more detail about why the compilation of act_comm.c failed.
• Address any syntax errors, missing dependencies, or other issues in act_comm.c as indicated by the gcc error messages.
• If the issue is with the Makefile’s syntax or structure, you may need to consult the GNU Make manual or other resources on writing Makefiles.

I would be running from the Cygwin shell personally. No feedback sounds odd. Maybe it’s running in the background? Try: ps -waux and see if you can spot smaug there. Maybe:

ps -waux | grep smaug

 PS C:\Conquest_SRC\Conquest\dist\src> ./smaug
 Wed Feb 14 12:53:44 2024 :: Booting Database

You should still be running from the area directory, which you aren’t there.

Oh well, then since it doesn’t like ‘w’:

 ps -aux | grep smaug

And how big is smaug?

ls -lh ../src/smaug