OSM Developer's Toolkit: LIB woes

The Watcher on 10/9/2014 at 06:59

Quote Posted by LarryG

. . . The site you ref has GCC 4.8.1 OK to use that? 4.6.x seems depreciated.

Ah, the double-edged sword of software. If it's not updated, it's usually abandoned and becomes unusable; if it is updated, you need to keep updating...

I'll see about revising the documentation to get the latest version in there later today, so it'll be a step-by-step thing again.

Mortal Monkey on 10/9/2014 at 18:52

Quote Posted by Telliamed

~~And if you want to try something new, there's a (http://sourceforge.net/projects/msys2/) fork of MSys that seems to be more actively maintained.~~

Tried building with MSys2 and MinGW. It did fix the "mkdir -p" problem, and you can fix the "loss of precision" errors by adding -m32 to CXXFLAGS, but now I'm getting errors that ::strtol and ::strtod have not been declared. I'll take that as a sign that it's time to switch to Winbuild.

Edit: Same error with the g++ from Winbuild:

Code:

utils.cpp: In function 'void StringToMultiParm(cMultiParm&, const char*)':
utils.cpp:128:8: error: '::strtol' has not been declared
mp = ::strtol(psz+1, NULL, 0);
^
utils.cpp:131:8: error: '::strtod' has not been declared
mp = ::strtod(psz+1, NULL);
^
utils.cpp:147:8: error: '::strtol' has not been declared
mp = ::strtol(psz, &end, 0);
^
Makefile:101: recipe for target 't1obj/utils.o' failed
mingw32-make: *** [t1obj/utils.o] Error 1

Edit2: Including stdlib.h in utils.h was super effective, but then a wild Linker Error appears:

Code:

g++ -mwindows -mdll -L../lg -Wl,--image-base=0x12200000 -o dh2.osl dh2_exp.o dh2.o dh2dll.o dh2_res.o -llg -luuid
c:/tools/winbuild/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lstdc++
c:/tools/winbuild/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lgcc_s
c:/tools/winbuild/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lgcc_s

Googledex says I need "g++-multilib" to defeat this foe.

The Watcher on 10/9/2014 at 22:57

(http://thief.starforge.co.uk/wiki/Scripting:Build_Environment) - updated step-by-step instructions to get a build environment using TDM-GCC and MSYS. Please tell me if any steps are ambiguous, or you encounter any problems (I reinstalled the whole environment from scratch to get the updated steps, and built lg, scriptlib, and twscript in there, and it works fine in my test mission)

LarryG on 11/9/2014 at 01:25

Quote:

Click on the checkbox next to "msys-mintty' and select "Mark for installation"

There are two of these. One for doc and one for bin. Any harm in taking both?

It appears not.

Quote:

Setting up git

To actually get the code, you need to install git. If you already have git (or github's native tool) installed, you can skip this section.

Download the latest installer from (http://git-scm.com/downloads)
Run the installer, clicking "Next" through it until you come to the "Adjusting your PATH environment" page. Select the "Run Git from the Windows Command Prompt" option, and click "Next"
Leave the "Choosing the SSH executable" option on "Use OpenSSH". Do not select "Use (Tortoise)Plink", even if you have it installed and working. Enabling that option can, and usually will, cause problems.
Keep clicking "Next" until it starts installing.
Twiddle your thumbs for a while.
Once the install has finished, run Git -> Git Bash from the Start Menu.
If all goes well, the Git Bash window should open, and you can use git --version to confirm that git is working.

1. Well, there is no option called "Choosing the SSH executable"
~~2. is the command-prompt command Git followed by entering Git Bash into the Git command window? If so it doesn't recognize Git Bash as a command.~~Never mind I see what you meant now. It does also open from the command prompt with git ...

Edit: Well everything compiled just fine, so I suppose I now have a base to work from. All I need is the time to dust off the C++ books and refresh myself and then maybe get another bottle of tequila and refresh myself some more. After I'm feeling no pain and have a firm grasp of the bottle, I'll begin ...

The Watcher on 11/9/2014 at 06:28

Quote Posted by LarryG

There are two of these. One for doc and one for bin. Any harm in taking both?

No harm, other than extra download time; the doc one is documentation.

Quote Posted by LarryG

1. Well, there is no option called "Choosing the SSH executable"

That's actually one of the steps in the wizard, doesn't really matter much as the correct option is the default anyway. I've tweaked the document a bit anyway.

Telliamed on 11/9/2014 at 20:45

Quote Posted by Mortal Monkey

Add #include <cstdlib> to utils.c.

I thought the makefiles were shell-agnostic but I overlooked mkdir. All you need to do is create those directories manually and it won't try to invoke the rule.

Quote:

Edit2: Including stdlib.h in utils.h was super effective, but then a wild Linker Error appears:

Code:

Googledex says I need "g++-multilib" to defeat this foe.

You may have to add -static-libgcc and -static-libstdc++ to LDFLAGS. I need to get winbuilds set up on my computer.

edit Yes, please add those flags. There's some other things 4.8 introduced that I need to take care of. It seems they added native support for the MSVC "thiscall" so maybe I can do away with some of those ASM hacks.

Mortal Monkey on 11/9/2014 at 22:22

Strange, I still get the error for stdc++. Tried both with what you suggested and -L/path/to/winbuild/lib -static (and the libstdc++.a is indeed in that folder). The gcc_s one is gone either way.

Telliamed on 12/9/2014 at 05:43

I'd say your build environment is wrong. You shouldn't need to set a path to standard libraries.

I've updated the repositories. Please sync your copies.

edit Seems that the win-builds package is broken. You can "fix" it by moving some libraries from $YYPREFIX/lib to $YYPREFIX/lib/gcc/i686-w64-mingw32/4.8.2: libgcc, libquadmath, libssp, libstdc++, libsupc++.

Or just go back to TDM which we know works. sigh

The Watcher on 12/9/2014 at 19:36

Thanks, updated and confirmed they build fine in the above linked build environment (and removed the step adding the sScrMsgBase virtual destructor in the instructions. Thanks for that, I guess I should really have forked and pull-requested it...)

Mortal Monkey on 16/9/2014 at 09:37

Quote Posted by Telliamed

Or just go back to TDM which we know works. sigh

Yep, twscript and even dh2 builds now. Publicscripts doesn't, though:

Code:

T1Scripts.cpp: In member function 'virtual void cScr_NumberButton::ActivateButton(object)':
T1Scripts.cpp:1407:12: error: ambiguous overload for 'operator=' (operand types are 'cAnsiStr' and 'cMultiParm')
strTxRep = mpTxRep;
^
T1Scripts.cpp:1407:12: note: candidates are:
In file included from ../lg/lg/scrservices.h:15:0,
from T1Scripts.h:29,
from T1Scripts.cpp:22:
../lg/lg/types.h:259:12: note: cAnsiStr& cAnsiStr::operator=(const char*)
cAnsiStr& operator= (const char* psz);
^
../lg/lg/types.h:260:12: note: cAnsiStr& cAnsiStr::operator=(const cScrStr&)
cAnsiStr& operator= (const cScrStr& rCpy)
^
T1Scripts.cpp:1413:11: error: ambiguous overload for 'operator=' (operand types are 'cAnsiStr' and 'cMultiParm')
strQVar = mpQVar;
^
T1Scripts.cpp:1413:11: note: candidates are:
In file included from ../lg/lg/scrservices.h:15:0,
from T1Scripts.h:29,
from T1Scripts.cpp:22:
../lg/lg/types.h:259:12: note: cAnsiStr& cAnsiStr::operator=(const char*)
cAnsiStr& operator= (const char* psz);
^
../lg/lg/types.h:260:12: note: cAnsiStr& cAnsiStr::operator=(const cScrStr&)
cAnsiStr& operator= (const cScrStr& rCpy)
^
make: *** [t1obj/T1Scripts.o] Error 1