Author Topic: gcc 5.3.0  (Read 1344 times)

0 Members and 1 Guest are viewing this topic.

Offline thematic

gcc 5.3.0
« on: December 30, 2015, 05:00:38 PM »
Does Simutrans compile correctly under gcc 5.3.0? I tried to do that on 120.1.1 but the undefined references at linking hint at an incompatibility. But it is the first real program I gave to that version - upgraded from 4.2.4 - so not sure. Both AmigaOS native.

edit: I was probably linking the wrong C++ lib. Duhh.
« Last Edit: July 10, 2017, 10:40:11 PM by thematic »
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline TurfIt

Re: gcc 5.3.0
« Reply #1 on: December 30, 2015, 08:29:34 PM »
Probably no one has tried. Unresolved references to Simutrans files? or dependent libraries? IIRC there's been a change to calling convention necessitating all libraries to be recompiled...

Offline DrSuperGood

Re: gcc 5.3.0
« Reply #2 on: December 31, 2015, 04:01:13 AM »
As far as I know GCC does not automatically change language features unless you explicitly tell it to using flags. Otherwise there would be a rather annoying destructor parameter syntax error (as happens in MSVC 2015 unless you use a hacky flag to disable the language feature).

A good place to start would be to rebuild all dependant libraries using the newer version of GCC. Hopefully these should be as simple as typing make and then moving the produced files.

Offline thematic

Re: gcc 5.3.0
« Reply #3 on: December 31, 2015, 01:29:32 PM »
A good place to start would be to rebuild all dependant libraries using the newer version of GCC. Hopefully these should be as simple as typing make and then moving the produced files.
Thanks. I used old libraries so I will try the smart thing.
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline thematic

Re: gcc 5.3.0
« Reply #4 on: July 10, 2017, 10:37:31 PM »
I have recently tinkered with this again, 120.2.2 codebase. It seems to be close, for upon linking there is only two distinct errors now:

undefined reference to `trim(std::string const&)'

and

undefined reference to `display_array_wh(short, short, short, short, unsigned short const*)'

I have tried changing the order of the object files (simtool.o simobj.o simgraph16.o) in the command line but it doesn't make any difference.

My code adapting was only about the log2 and log10 functions so that doesn't seem to be the issue (at this point!).
« Last Edit: July 12, 2017, 12:04:39 AM by thematic »
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4233
  • Total likes: 169
  • Helpful: 149
  • Languages: EN, DE, AT
Re: gcc 5.3.0
« Reply #5 on: July 11, 2017, 06:44:43 AM »
There is a makefile coming with the source, you should use it.
Parsley, sage, rosemary, and maggikraut.

Offline thematic

Re: gcc 5.3.0
« Reply #6 on: July 11, 2017, 07:32:41 AM »
There is a makefile coming with the source, you should use it.
Yes, this is how it used to be, really commendably simple. I had the makefile compile everything. I do not understand what the problem is.
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4233
  • Total likes: 169
  • Helpful: 149
  • Languages: EN, DE, AT
Re: gcc 5.3.0
« Reply #7 on: July 11, 2017, 11:47:06 AM »
Can you post your config file? Did you try ``make clean; make '' ?

The display_array_wh are declared in display/simgraph.h and implemented in simgraph*.cc. Can you check that both declaration and implementation are present and have the same function signature?
Parsley, sage, rosemary, and maggikraut.

Offline thematic

Re: gcc 5.3.0
« Reply #8 on: July 11, 2017, 06:32:47 PM »
The functions look alright to me. I recompiled everything and went with dynamic linking and it made no difference. I will probably try gcc 4.2.4 next.

config.default:
# this is config.default.in

# allowed backends:
#BACKEND = allegro
#BACKEND = gdi
#BACKEND = opengl
#BACKEND = sdl
#BACKEND = sdl2
#BACKEND = mixer_sdl
#BACKEND = posix
BACKEND = sdl2

# color depth either 16 or 0 (the latter needed for server)
COLOUR_DEPTH = 16

# architecture specifi flags
#OSTYPE = amiga
#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = haiku
#OSTYPE = linux
#OSTYPE = mingw
#OSTYPE = mac

OSTYPE = amiga

MSG_LEVEL = 3
DEBUG = 1    # Level 1-3, higher number means more debug-friendly, see Makefile
OPTIMISE = 0 # Add umpteen optimisation flags
#PROFILE = 1  # Enable profiling
#PROFILE = 2  # Enable profiling with optimisation flags, can be used with `OPTIMISE = 1'


WITH_REVISION = @svn@ # adds the revision from svn; required for networkgames
# if you do not use SVN, add -DREVISION="1234" to the FLAGS below

#WIN32_CONSOLE = 1 # adds a console for windows debugging

MULTI_THREAD = 0 # Enable multithreading, highly recommended
#BUNDLE_PTHREADGC2 = @bundlepthread@

# Define these as empty strings, if you don't have the respective config program
#ALLEGRO_CONFIG = allegro-config
#PNG_CONFIG     = pkg-config libpng
#SDL_CONFIG     = sdl-config
SDL2_CONFIG    = sdl2-config

VERBOSE = 1

# The following useful conditional compilation flags exist
#
# Needed to compile:
# USE_C: no assembler for copying (required for not using GCC on x86)
# SIM_BIG_ENDIAN: MUST be set for PPC/Motorola byte order! (old mac, amiga)
#
# Changing appearance:
# USE_SOFTPOINTER: emulate mouse pointer (set automatically in Makefile)
# USE_FREETYPE: use TrueType vector fonts
#
# Useful for debugging:
# DEBUG_ROUTES: show routing calculation information in minimap
# SHOW_FORE_GRUND: show which objects are drawn as foreground
# DEBUG_FLUSH_BUFFER: show the dirty areas on the screen
# USE_VALGRIND_MEMCHECK: make valgrind-memcheck aware of the memory allocation stuff in dataobj/freelist
# SYSLOG: send debug output to syslog
#
# Following flags alter game engine (and are off for standard builds)
# OTTD_LIKE: Enables half height tiles and crossconnects all industries
# AUTOMATIC_BRIDGES and AUTOMATIC_TUNNELS: will be built also for player
# AUTOJOIN_PUBLIC: stations next to a public stop will be joined to it
# MAX_CHOOSE_BLOCK_TILES=xxx: maximum distance between choose signal and a
#    target (undefined means no limit)
# USE_DIFFERENT_WIND: different airplane approach directions over the map
# DESTINATION_CITYCARS: Citycars can have a destination (not recommended)
#
# In order to use the flags, add a line like this: (-Dxxx)
FLAGS = -DSIM_BIG_ENDIAN
FLAGS += -DUSE_C
FLAGS += -DUSE_FREETYPE
FLAGS += -DREVISION="8163"

MAKEOBJ_PROGDIR = $(shell pwd)
NETTOOL_PROGDIR = $(shell pwd)
PROGDIR  = $(shell pwd)
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline TurfIt

Re: gcc 5.3.0
« Reply #9 on: July 11, 2017, 08:48:54 PM »
I would guess simgraph16.cc isn't actually compiling and your build system isn't aborting for some reason...
Code: [Select]
display/simgraph16.cc: In function 'void display_img_nc(KOORD_VAL, KOORD_VAL, KOORD_VAL, const PIXVAL*)':
display/simgraph16.cc:2528:17: error: assignment of read-only location '*(sp ++)'
       *sp++ = *p++;
                 ^~
SIM_BIG_ENDIAN is likely not tested for a long long time, and clearly broken.
USE_C is deprecated.
USE_FREETYPE is unknown. WIP perhaps...

Offline thematic

Re: gcc 5.3.0
« Reply #10 on: July 11, 2017, 11:40:12 PM »
Oh, the other error, originally omitted, was

undefined reference to `trim(std::string const&)'

Seems to have been built:
> ls -o build/default/display
total 1101
-rw-r--r--  1 nobody    992 Jul  1 22:48 font.d
-rw-r--r--  1 nobody  48712 Jul  1 22:48 font.o
-rw-r--r--  1 nobody   1833 Jul  1 22:49 simgraph16.d
-rw-r--r--  1 nobody 659628 Jul  1 22:49 simgraph16.o
-rw-r--r--  1 nobody   5110 Jul  1 22:49 simview.d
-rw-r--r--  1 nobody 207360 Jul  1 22:49 simview.o
-rw-r--r--  1 nobody   3266 Jul  1 22:49 viewport.d
-rw-r--r--  1 nobody 198828 Jul  1 22:49 viewport.o


simgraph16.cc seems to have an optimized loop for little endian, so it should still work BE? But I didn't delve deeper. I see there's a LOW_LEVEL flag, I think it's defined in simconst.h, though.
« Last Edit: July 12, 2017, 12:05:38 AM by thematic »
"If I could discover just one of these things - what eternity is, for example - I wouldn't care if they did think I was crazy."

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8764
  • Total likes: 307
  • Helpful: 229
  • Languages: De,EN,JP
Re: gcc 5.3.0
« Reply #11 on: July 13, 2017, 08:54:24 AM »
The old simigraph was working, and the optimisations should not have affected the code. And there was a pure C option anyway.

GCC 5.3.0 should work, with GCC 4.x I am not so sure.