Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ SMAUG ➜ Compiling the server ➜ newbie compiling problems

newbie compiling problems

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Gdub   (35 posts)  Bio
Date Sat 10 Feb 2024 08:07 PM (UTC)

Amended on Wed 14 Feb 2024 06:41 AM (UTC) by Gdub

Message
Hoping someone has the patience to help me with some compiling problems. I have a heavily modified SMAUG code base that I found while cleaning out and old storage locker. I'm keen to start fiddling again. I'm using Win10 and cygwin.

I made it this far - skills are very dusty so apologies in advance if I'm being daft.
[code]
$ make smaug
Makefile:49: warning: ignoring prerequisites on suffix rule definition
<snip lots of warnings>
gcc -c  -O -g3 -Wall -Wuninitialized   -DREQUESTS -DSMAUG  -DNOCRYPT act_move.c
In file included from act_move.c:23:
act_move.c: In function ‘grab_word’:
act_move.c:175:21: warning: array subscript has type ‘char’ [-Wchar-subscripts]
  175 |     while ( isspace(*argument) )
      |                     ^~~~~~~~~
act_move.c:193:21: warning: array subscript has type ‘char’ [-Wchar-subscripts]
  193 |     while ( isspace(*argument) )
      |                     ^~~~~~~~~
act_move.c: In function ‘decorate_room’:
act_move.c:297:41: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
  297 |               switch( number_range(1, 2 * (iRand == nRand -1) ? 1 : 2) )
      |                                       ~~^~~~~~~~~~~~~~~~~~~~~
act_move.c: In function ‘rev_exit’:
act_move.c:400:15: warning: trigraph ??> ignored, use -trigraphs to enable [-Wtrigraphs]
  400 |     return "<???>";
      |
act_move.c: In function ‘generate_exit’:
act_move.c:628:25: error: lvalue required as left operand of assignment
  628 |     (EXIT_DATA *) pexit = xit;
      |                         ^
act_move.c: In function ‘do_climb’:
act_move.c:2468:10: warning: variable ‘found’ set but not used [-Wunused-but-set-variable]
 2468 |     bool found;
      |          ^~~~~
act_move.c: In function ‘do_enter’:
act_move.c:2499:10: warning: variable ‘found’ set but not used [-Wunused-but-set-variable]
 2499 |     bool found;
      |          ^~~~~
act_move.c: In function ‘do_leave’:
act_move.c:2538:10: warning: variable ‘found’ set but not used [-Wunused-but-set-variable]
 2538 |     bool found;
      |          ^~~~~
make: *** [Makefile:49: act_move.o] Error 1
[/code]
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #1 on Sat 10 Feb 2024 11:12 PM (UTC)

Amended on Sat 10 Feb 2024 11:13 PM (UTC) by Nick Gammon

Message
You've only got one error, which I asked ChatGPT about (to save myself having to think). :)




The error message you're encountering in your C code, specifically the "lvalue required as left operand of assignment," suggests a problem with the assignment operation at line 628. In C, an lvalue is an expression that refers to a memory location and allows us to take the address of that location. It's basically something that can appear on the left-hand side of an assignment.

The line (EXIT_DATA *) pexit = xit; seems to be attempting a cast and then an assignment. The issue here is that the casting operation (EXIT_DATA *) pexit creates a temporary value, not an lvalue. You cannot assign a value to a cast like this because the result of a cast is not a memory location that you can assign to.

If pexit is a pointer of a different type and you want to assign xit to it, you should first cast xit to the type of pexit. For example:


pexit = (EXIT_DATA *) xit;


This assumes xit is of a type that can be meaningfully cast to EXIT_DATA*. This code assigns the value of xit (after casting it to EXIT_DATA*) to pexit. Make sure that this cast is safe and that the types are compatible in a way that makes sense for your program.




This sounds like reasonable advice to me.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #2 on Sun 11 Feb 2024 08:33 AM (UTC)
Message
Thank you Nick!

I could have sworn I saved a compliable version of it. It is possible the cygwin of ~20 years ago would have handled that differently? Or more likely that I saved the wrong version? :/

Anyways, thank you for the prompt reply. I'll keep working through it and report back.
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #3 on Sun 11 Feb 2024 07:00 PM (UTC)
Message
I worked through a few more (very odd errors) and have been using chatgpt as a helpful guide - thanks for the tip.

I'm now stuck on a macro that handles linked lists

errors:

In file included from ban.c:24:
ban.c: In function ‘dispose_ban’:
mud.h:3141:33: error: lvalue required as left operand of assignment
3141 | (first) = (link)->next;\
| ^
ban.c:1266:3: note: in expansion of macro ‘UNLINK’
1266 | UNLINK(pban,(type==BAN_SITE)?first_ban:(type==BAN_CLASS)?first_ban_class:first_ban_race,(type==BAN_SITE)?last_ban:(type==BAN_CLASS)?last_ban_class:last_ban_race, next, prev );
| ^~~~~~
mud.h:3145:33: error: lvalue required as left operand of assignment
3145 | (last) = (link)->prev; \
| ^


macros:

#define UNLINK(link, first, last, next, prev) \
do \
{ \
if ( !(link)->prev )\
(first) = (link)->next;\
else \
(link)->prev->next = (link)->next; \
if ( !(link)->next ) \
(last) = (link)->prev; \
else \
(link)->next->prev = (link)->prev; \
} while(0)


use of macro:

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

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

UNLINK(pban,(type==BAN_SITE)?first_ban:(type==BAN_CLASS)?first_ban_class:first_ban_race,(type==BAN_SITE)?last_ban:(type==BAN_CLASS)?last_ban_class:last_ban_race, next, prev );
free_ban( pban );
return;
}

chatgpt has no suggestions for me.
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #4 on Sun 11 Feb 2024 08:43 PM (UTC)
Message

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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #5 on Sun 11 Feb 2024 08:45 PM (UTC)

Amended on Sun 11 Feb 2024 08:46 PM (UTC) by Nick Gammon

Message
Gdub said:

I could have sworn I saved a compliable version of it. It is possible the cygwin of ~20 years ago would have handled that differently? Or more likely that I saved the wrong version? :/


Quite likely. The error and warning checking by the C and C++ compilers continues to evolve (improve) so that dodgy constructs are now errors or warnings. The underlying code presumably still works, however you could always consider the warnings as indications of things that might possibly cause trouble later.

I've had code that used to compile perfectly well fail when compiled on newer compilers.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #6 on Sun 11 Feb 2024 09:19 PM (UTC)
Message

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;
}

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #7 on Mon 12 Feb 2024 04:48 PM (UTC)
Message
Thank you Nick. Your solution appears to have worked and I'm on to the next set of errors :)

I will attempt to resolve them on my own so I don't become dependent on your wisdom :) but I'll report back if I get stuck.

Cheers.
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #8 on Mon 12 Feb 2024 05:38 PM (UTC)
Message
I've successfully compiled!

There were a few multiple declaration errors so I tried using the extern keyword. That didn't work so I declared them as static and voila!

Now onto seeing if I can run it and connect.
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #9 on Mon 12 Feb 2024 09:53 PM (UTC)
Message
Gdub said:

There were a few multiple declaration errors so I tried using the extern keyword. That didn't work so I declared them as static and voila!


It would depend on the context. If the variable is supposed to be shared across compilation units then making them static will stop that sharing.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #10 on Wed 14 Feb 2024 05:53 AM (UTC)
Message
new and perplexing issue.

I compiled the .exe with no errors.
I ran the .exe from the command shell and got and error that cygwin.dll missing.
I copied cygwin.dll over to the src directory from the recent cygwin install.
I tried to run the .exe again and got an error re: requests pipe failure
I reviewed my code changes, changed nothing - make clean and make smaug
I got a an error on compile from the makefile!


Makefile:49: warning: ignoring prerequisites on suffix rule definition
gcc -c  -O -g3 -Wall -Wuninitialized   -DREQUESTS -DSMAUG  -DNOCRYPT act_comm.c
make: *** [Makefile:49: act_comm.o] Error 1



I made no changes to the make file... what have I done?
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #11 on Wed 14 Feb 2024 10:28 AM (UTC)
Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Gdub   (35 posts)  Bio
Date Reply #12 on Wed 14 Feb 2024 07:31 PM (UTC)
Message
When I delete the cywin.dll from the src folder it will compile again. Seems like a conflict with the .DLL?
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #13 on Wed 14 Feb 2024 08:16 PM (UTC)
Message
What operating system are you using? It sounds like a Windows version.

Are you compiling using the command shell or the Cygwin shell? If it compiles under Cygwin it shouldn't be asking for cygwin.dll when you go to execute it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #14 on Wed 14 Feb 2024 08:18 PM (UTC)
Message
The Cygwin shell normally puts the appropriate DLLs in your path.

Alternatively, maybe you cross-compiled for one operating system (not the one you are using), which means it might compile OK but not run.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


10,356 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.