Reversing to Orion - project 1oom

[Kilgore T.M. Replicant]

MSYS2 has pacman (from Arch Linux)

Ah, cool.

What I tried is:

Thanks for trying and writing. SDL_image is not used but SDL_mixer is. I assume both pull in SDL itself.

But then it did not found -lmingw32 and an hour of head-bashing the wall didn't make it work, so at this point it'd be simpler to just fire up a linux VM (for me)

Sorry about your head and wall. Not quite sure what -lmingw32 is, but I'll try to fix that and readline.

Linux is really user friendly when it comes to building software.

EDIT:

I find the combination

Code: [Select]

gcc
mingw32/mingw-w64-i686-SDL
./configure

suspicious. Shouldn't that be either

Code: [Select]

gcc
SDL
./configure

or

Code: [Select]

mingw32/mingw-w64-i686-gcc
mingw32/mingw-w64-i686-SDL
./configure --host=i686-w64-mingw

? In any case, can't help much further without config.log.

Took a look at configure.ac again. No idea on -lmingw32 or the readline issue, but made missing SDL(2)_mixer and OpenGL cause an error and require --disable to get around.

[SupSuper]

Works fine here. Here's what I did:

1. Install MSYS2 following the instructions on http://www.msys2.org/
2. After doing all the updates as instructed, launch MSYS2 MSYS and install your toolchain (replace i686 with x86_64 if you want 64-bit EXEs):

Code: [Select]

pacman -S mingw-w64-i686-toolchain mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-libsamplerate3. Install the build tools:

Code: [Select]

pacman -S git autoconf automake make4. Close the shell and launch MSYS2 MinGW 32-bit (or 64-bit respectively) to set up the environment variables.
5. Compile as usual:

Code: [Select]

git clone https://gitlab.com/KilgoreTroutMaskReplicant/1oom.git
cd 1oom
autoreconf -fi
./configure
make



Btw Kilgore you need to clean up those unused warnings.

Edit: mingw-w64-i686-toolchain might already be installed for you so not sure it's needed.

[Kilgore T.M. Replicant]

Works fine here. Here's what I did:

Thanks! I'll try to write the HOWTO based on these.

A few questions:
1. Does it run?
2. Are the SDL2 libs just s/SDL/SDL2/g?

Btw Kilgore you need to clean up those unused warnings.

OK, fine. I don't see them as they are used for --enable-modebug.

[Stoddard]

Ok, reinstalled MSYS2 from scratch according to SupSuper's instructions and it worked. Thanks, man.

SDL2 is indeed just a

Code: [Select]

pacman -S mingw-w64-i686-SDL2 mingw-w64-i686-SDL2_mixer

away.

And it all does run modulo problems with finding the .dlls. I suggest you incorporate a static build option and make it default for msys2 builds otherwise it'll be no end of confusion about copying dlls and stuff.

[SupSuper]

And it all does run modulo problems with finding the .dlls. I suggest you incorporate a static build option and make it default for msys2 builds otherwise it'll be no end of confusion about copying dlls and stuff.

Well static linking is kinda inefficient when you've got 10 EXEs... don't know how to integrate it into automake, but you could easily write a separate script to copy them for you: https://blog.rubenwardy.com/2018/05/07/mingw-copy-dlls/

[Stoddard]

Well, it's not like there are ten thousand libs linked, after all the whole statically linked shebang weighs under 20Mb.
Besides we're talking about debug/test builds here, in which case some convenience way outweighs minor disk space waste.

[Kilgore T.M. Replicant]

And it all does run modulo problems with finding the .dlls. I suggest you incorporate a static build option and make it default for msys2 builds otherwise it'll be no end of confusion about copying dlls and stuff.

Does it run if you simply "src/1oom_classic_sdl1" right after make? If it doesn't then I can only
1) ask for you guys to write the dll copy instructions
2) take a closer look at static builds

IIRC autotools has some --enable-static added by default but I doubt it's that easy. I'd settle for instructions on grabbing the dlls.

Draft v1 in attachments. (EDIT: obsolete, removed)

[Stoddard]

Static build (that is, linking SDL statically) was achieved by

Code: [Select]

--- a/configure.ac
+++ b/configure.ac
@@ -189,10 +189,10 @@ if test x"$enable_hwsdl1" != "xno"; then
         HW_SDL1_LIBS="$SDL1_LIBS"
     elif test x"$sdl_config" != "xno"; then
         HW_SDL1_CFLAGS="$CFLAGS `$sdl_config --cflags`"
-        HW_SDL1_LIBS="`$sdl_config --libs`"
+        HW_SDL1_LIBS="`$sdl_config --static-libs`"
     elif $pkg_config --exists sdl; then
         HW_SDL1_CFLAGS="$CFLAGS `$pkg_config --cflags sdl`"
-        HW_SDL1_LIBS="`$pkg_config --libs sdl`"
+        HW_SDL1_LIBS="`$pkg_config --libs --static sdl`"
     else
         HW_SDL1_LIBS="-lSDL"
     fi
@@ -223,7 +223,7 @@ if test x"$enable_hwsdl1" != "xno"; then
             if test x"$SDL1MIXER_LIBS" != "x"; then
                 HW_SDL1_LIBS="$HW_SDL1_LIBS $SDL1MIXER_LIBS"
             elif $pkg_config --exists SDL_mixer; then
-                HW_SDL1_LIBS="`$pkg_config --libs SDL_mixer`"
+                HW_SDL1_LIBS="`$pkg_config --static --libs SDL_mixer`"
             else
                 HW_SDL1_LIBS="$HW_SDL1_LIBS -lSDL_mixer"
             fi

AND running configure as follows:

Code: [Select]

LDFLAGS=-static ./configure  --disable-hwsdl1audio

After that it runs when just the executable is copied into the MOO1 data dir.

SDL_mixer package somehow doesn't install a pkg-config file, so there's no way to link it statically but for listing all its dependent libs manually or something. But the sound isn't that critical for AI development.

As for the DLL set, previously I just copied the all the *.dll files from $MSYS2_INSTALL_DIR/mingw32/bin to the MOO1 data dir because I'm lazy like that. (substitute mingw64 for 64bit builds).

[Kilgore T.M. Replicant]

I remembered wrong: there is no --enable-static by default. I tried implemeting it, but couldn't get a static SDL (or libsamplerate) configured on my Debian setup and gave up. I can add it anyway if you deem it helpful. Meanwhile, something like

Code: [Select]

../configure LDFLAGS="-static" \
        SDL1_CFLAGS="`sdl-config --cflags`" \
        SDL1_LIBS="`sdl-config --static-libs`" \
        SDL1MIXER_LIBS="-lblahblah"
should work without the patch. I'd rather not document that.

The reason I asked about "src/1oom_classic_sdl1" in specific was the remote possibility that the dynamic linker can somehow find the dlls when run in MSYS. I guess "nope" is the answer.

I've written the howto with running the exes within MSYS in mind. Given "make -j 3 && src/1oom_..." and command history, who would prefer copying the exe somewhere else and running it via other means?

But the sound isn't that critical for AI development.

Sure, but this is not only for AI work. I'm trying to bring freedom 1 and the joy of hacking to wider masses. I'd much prefer "how to build a fully functional build" than something specific. I'm willing to ignore libsamplerate and readline.

As for the DLL set, previously I just copied the all the *.dll files from $MSYS2_INSTALL_DIR/mingw32/bin to the MOO1 data dir because I'm lazy like that. (substitute mingw64 for 64bit builds).

I'm tempted to use that solution. Can you state that as a copy/pasteable cp command?

Adapting that script SupSuper linked to would be better. As I can't test it, well...

As for static vs. dynamic: whichever someone chooses and fixes that v1 draft to work with. If you need --enable-static, say so.

[Stoddard]

It all kinda depends on a particular workflow.

I, for example, copy built exes to a separate directory, which contains MOO1 data files, by other means (not msys shell).

Someone else might prefer to do it the other way around or something else.

In MSYS2 the root of its filesystem namespace is its install directoty, under that you have /bin, /home/$windows_username, /mingw32, /mingw64, etc.

So to copy dlls it would be cp /mingw32/*dll ~/1oom/src for them to end up adjacent to the built exes  assuming you just did git clone 1oom ; cd 1oom ; autoconf-dance  without cd-ing somewhere else before that.

[Kilgore T.M. Replicant]

Thanks, I think I can finish the howto now. Should be up in a few days.

[SupSuper]

The reason I asked about "src/1oom_classic_sdl1" in specific was the remote possibility that the dynamic linker can somehow find the dlls when run in MSYS. I guess "nope" is the answer.

I've written the howto with running the exes within MSYS in mind. Given "make -j 3 && src/1oom_..." and command history, who would prefer copying the exe somewhere else and running it via other means?

If you run it from inside MSYS, it will find the DLLs in the search paths automatically, but you can only run command-line apps from MSYS (so the command-line 1oom will work, but not the classic 1oom).

I might experiment with a proper Windows toolchain and see how it compares to autotools.

[Kilgore T.M. Replicant]

(was just about to post:)

Howto is up. Bug reports / patches here or there.

(when this popped up)

If you run it from inside MSYS, it will find the DLLs in the search paths automatically, but you can only run command-line apps from MSYS (so the command-line 1oom will work, but not the classic 1oom).

... fuck. Did not expect that. Taking down link from index.html and waiting for patches...

[SupSuper]

... fuck. Did not expect that. Taking down link from index.html and waiting for patches...

Nothing's broken. To clarify:

- If you run the .exe's directly from the MSYS shell, then you don't need to copy the DLLs, as it will use the shell search path (with the caveat that only the command-line version will work inside a shell).

- If you run the .exe's directly in Windows, then you need to copy the DLLs, since it will use the Windows search path.

[Kilgore T.M. Replicant]

Nothing's broken. To clarify:

- If you run the .exe's directly from the MSYS shell, then you don't need to copy the DLLs, as it will use the shell search path (with the caveat that only the command-line version will work inside a shell).

- If you run the .exe's directly in Windows, then you need to copy the DLLs, since it will use the Windows search path.

The howto (link above) directs the user to start 1oom_classic_sdl1 via the MSYS shell in order to find out which DLLs are missing. According to your clarifications this fails in two ways:

- MSYS shell can find the DLLs when the exe is run inside it and thus will not help in the generic case (which is not that important from the howto's perspective).

- It does not work for the _sdlN exes since only command-line applications can be run from the MSYS shell. (WTF? The mind boggles. Why do you put up with that garbage?)

The point of the howto is to give step-by-step instructions in compiling and running your own build. The current version fails. How is it not broken?

I guess I'll rewrite the DLL hell section and hope for the best.

EDIT:

Rewritten version is up.

Thanks guys spaceship and dog for the help! My Face When receiving a solid contribution: