bah.freeimage - undefined reference to `_localtime32'

Started by mattchuranu, October 29, 2018, 15:42:34

Previous topic - Next topic

mattchuranu

I recently got a hold of the source code to an engine that I've used in the past, which was built in BlitzMax. I'm not particularly familiar with BlitzMax, myself, but I'd like to continue to use and extend the engine if possible. The source code is from around 2013 and the core engine builds fine in BlitzMax 1.50, but it isn't building in BlitzMax NG just yet, as there are what appear to be a ton of type safety errors that need to be resolved first. With that in mind, I'm currently attempting to get everything to build in BlitzMax 1.50 before I attempt to move it all to BlitzMax NG.

One of the tools that comes with the engine uses the bah.freeimage and I've been having issues getting it to build the tool without any sort of error. When I was building bah.freeimage with gcc 8.10, there was a literal mountain of undefined reference errors when building the tool, but I've narrowed it down to just a few that, according to the internet, could possibly be anything from a tool mismatch error to something not being linked the way that it should be (which I assume also comes down to how BlitzMax's assembler interacts with it).

So far, I've tried the following combinations of bah.freeimage and gcc (thanks mostly to a few personal builds of mingw-w64 that made binaries of older versions of gcc easier to find, which may also be a factor):

- A version of bah.freeimage from November 2011, compiled with gcc 4.7.4, 4.8.1, and 8.10.
- A version of bah.freeimage from February 2013, compiled with gcc 8.10.
- A version of bah.freeimage from June 2013, compiled with gcc 4.7.4 and 4.8.1.
- A version of bah.freeimage from 2015, compiled with gcc 4.7.4, 4.8.1, and 8.10.
- The latest version of bah.freeimage, compiled with gcc 4.7.4 and 8.10.

Here are the build errors that show in BlitzMax's Output tab when any version of bah.freeimage is built with gcc 4.x:


D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(pngwrite.c.release.win32.x86.o):pngwrite.c:(.text+0x1040): undefined reference to `_gmtime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(libraw_datastream.cpp.release.win32.x86.o):libraw_datastream.cpp:(.text+0x25b): undefined reference to `__mingw_vfscanf'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(libraw_datastream.cpp.release.win32.x86.o):libraw_datastream.cpp:(.text+0x28b): undefined reference to `__mingw_vsscanf'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x17362): undefined reference to `_mktime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x1736e): undefined reference to `_mktime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x24f4c): undefined reference to `_mktime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x24f5c): undefined reference to `_mktime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x26338): undefined reference to `_mktime32'
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x26348): more undefined references to `_mktime32' follow
D:/Applications/BlitzMax/BlitzMax-1.50/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dcraw_common.cpp.release.win32.x86.o):dcraw_common.cpp:(.text+0x2e146): undefined reference to `_localtime32'
D:/Applications/BlitzMax/BlitzMax-1.50/projects/banshee-engine/.bmx/gif.bmx.release.win32.x86.o:(code+0x800): undefined reference to `_28'


Is there some specific version of gcc that I need to be using to get this to work or am I missing a separate issue?

Henri

Hi,

4.x version gcc is a bit out of date, so newer version is recommended. Release NG-download comes with MinGW-w64 builtin (found in MinGWx86 folder), so that is a good starting point (if you want to move there eventually).

Something that is not clear to me, is that you say it compiles fine with 8.0 for example, but still there are errors ? MinGW-w64 has 32-bit and 64bit variants which can be selected upon installing, so the undefined function errors that mention 32, might be due to this.

-Henri
- Got 01100011 problems, but the bit ain't 00000001

mattchuranu

The module builds fine, but it's causing errors when compiling the engine and linking the BlitzMax code to the module.

I used the 32-bit versions of each version of gcc mentioned and the version of gcc 8.10 used is the one that is included with the latest Windows release of bmx-ng.

A page on the OHRRPGCE wiki states that a similar error occurs when building FreeBASIC with an "incompatible" version of gcc, which is what led me to use an older version of gcc in the first place. The exact version I chose had to do with specific features that were deprecated in later versions of gcc, which other clues seemed to hint may have been the cause of the errors.

I have since found that the error thrown by the version built using gcc 8.10 has also previously been solved by downgrading gcc, but I have yet to try, for example, gcc 7.1, which is mentioned in that discussion. However, that issue also seems to be linked to libuv, so it seems unlikely that that is the issue here.

Another post on the FreeBASIC forums seems to indicate that the issue with gcc 8.10 an issue with not keeping gcc libraries up to date, but that seems unlikely, as well, as I've tried older versions of bah.freeimage with gcc 8.10, which one would assume would be fine with older versions of the library, and I

Here's the last 1/10th or so of the output for the version built with gcc 8.10 (it's so absurdly long that it exceeds hastebin's character limit): https://hastebin.com/efufunoguf.rb

Henri

For what it's worth I tried bah.freeimage on NG found at https://github.com/maxmods/bah.mod/tree/master/freeimage.mod, and it compiled fine.
Also the examples that came with it ran fine. gcc version was 8.1.0

-Henri
- Got 01100011 problems, but the bit ain't 00000001

mattchuranu

#4
It must be an issue with BlitzMax 1.50, then. Something must not be linking properly. I'm just not sure how to fix it at the moment.

EDIT: Tried building the first test that's included in the latest version of bah.freeimage in the latest release of BlitzMax NG. No issues.

Also tried building bah.freeimage in an x64 version of Windows XP that I have in a virtual machine. No luck. Attempts to compile the tool in question throw similar errors when BlitzMax attempts to link the executable to the module.

col

QuoteIt must be an issue with BlitzMax 1.50, then. Something must not be linking properly.

Hopefully I'm not throwing a curve ball here but if I recall correctly... 1.50 has some libs copied from a gcc installation into the /BlitzMax1.50/lib/ folder. I'd also look there for potential conflicts when using a different version of gcc - you shouldn't really mix up the gcc runtimes/support libs from different versions.

NG has it right to include the complete gcc installation within its own installation.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Henri

Yes, NG has newer version of bmk.exe that can search gcc from local folder first without the need for setting MinGW environment variables (and without the need to copy the libs files). Other things that might effect the outcome are default mods (namely brl.mod and pub.mod). These have been updated in NG version.

Both can be used in legacy Blitzmax as well, but require some experimenting.

For legacy bmx you could also try the TDM MinGW (try the 64 bit version, it has 32bit toolchain too) found here http://tdm-gcc.tdragon.net/download

-Henri
- Got 01100011 problems, but the bit ain't 00000001

TomToad

Remember, if you change the version of gcc, be sure to rebuild all the modules again. Sometimes modules built with different versions of gcc are incompatible.
------------------------------------------------
8 rabbits equals 1 rabbyte.

mattchuranu

Thanks for the suggestions. I ended up just commenting out the code that uses the library, though, as the program can still function without it, albeit without a feature or two.

Quote from: Henri on October 30, 2018, 12:26:16
For legacy bmx you could also try the TDM MinGW (try the 64 bit version, it has 32bit toolchain too) found here http://tdm-gcc.tdragon.net/download

I actually tried using this after seeing it mentioned in the readme in the BlitzMax OS GitHub repo (the .zip version, not the installer, for portability) and, upon attempting to use the core and c++ packages, I was told that "the CPU selected doesn't have support for 32-bit instructions" or something similar, so that went nowhere. Attempting to use the 32-bit version then threw some other error that I don't remember offhand.