Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, 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
(40 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,100 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
(40 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
(40 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,100 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,100 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,100 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
(40 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
(40 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,100 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
(40 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,100 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:
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.
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.
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
(40 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,100 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,100 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,938 views.
This is page 1, subject is 2 pages long: 1 2
It is now over 60 days since the last post. This thread is closed.
Refresh page
top