conflicting types for 'strtold'


#1

I have been migrating MUDs to a new server. I run the same version of gcc on both (and same Makefile), but am getting errors on the new server when compiling. I understand what this error means, but not why I’m getting it when both versions are the same:

build.c:33: error: conflicting types for ‘strtold’ /usr/include/stdlib.h:178: error: previous declaration of ‘strtold’ was here

The line:

long double strtold args( ( const char *string, const char **endstring) );

The stdlib.h line on the new server:

extern long double strtold (__const char *__restrict __nptr,

On stdlib.h in the same directory on the old server, same line:

extern long double strtold (__const char *__restrict __nptr,

But the old server does not receive this compile error. Old server gcc:

[user@old src]# /usr/bin/gcc34 -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: …/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-4.1)

New server gcc:

[user@new src]$ /usr/bin/gcc34 -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: …/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)

What am I missing here? What could be pointing to a different library if the code, gcc version and Makefile are the same?


#2

Ah, good old C. My favorite language that I ironically haven’t used for 5 years.

I think you already got your answer:

bottom line is that you should fix it and not scratch your head too much over the reasons why it didn’t complain on your previous server.


#3

The issue is that I’m more of the MUD host/SysAdmin rather than the MUD dev in a number of scenarios. I’m migrating to the new server and if some MUD owners aren’t around, the MUD will no longer boot. I’d rather not be going around having to fix various MUDs because something is breaking and there’s no reason why. You can see https://www.reddit.com/r/MUD/comments/5smwoc/introducing_the_anime_mud_network_amn/ for details.


#4

Poorly written MUD codebases will break when moving them around from system to system. Not your fault but sure is your problem. The fixes are usually trivial though.


#5

The systems aren’t the same.

Your old system is a 32 bit i386 architecture, your new system is 64 bit x86_64. The two architectures have different underlying definitions for what a long double is. The difference gets resolved transparently through a lot of complex, conditional definitions in the standard library headers that you probably don’t want to mess with.

In general, your code shouldn’t be re-declaring a function that is already defined by the inclusion of stdlib.h.

I’d say comment out line build.c:33 and see if that takes care of it.