Hahahah, Gapan, your advice is very good, but I really wanted to compile
Gens-gs-r7 in Salix 14
64 bits Multilib... and after much struggle, and some hep,
I DID IT! 
First Warning: this topic will be
wide, and I'll divide it in
three parts, to explain what I had done, following the sequence of events.
Second warning: I realized that compiling/building programs, specially those use linkers/assembler is much complex than Alien's Bob says in his wiki... You will see...
Third warning: My thoughts, technically speaking, could be wrong, but are based in observation and facts... feel free to correct me in the technical aspect.
First part: Trying to compiling following the Alien's Bob advice and using the original Gens-gs Slackbuild.
First of all, I want to say that Alien's Bob advice isn't wrong, but works under certain circumstances (like I build
Zsnes-1.51b, as said above), but in
this case, things are more complex... Only editing some variables in the Slackbuild won't do the trick...
So, I did the classic way: set the
$ARCH to
x86_64, made the compiler create
32 bits code, setting (in the Slackbuild):
Code: Select all
export CC="gcc -m32"
export CXX="g++ -m32"
Compilation begins, but hangs, showing: "...can't compile in a 64 bit enviromment" (the cause, I learned latter, is the
$ARCH...). Like I said, it was caused by
several locks, and I removed them (saying the truth, there are several reasons for this, and you don't need to remove it...until you REALLY know the consequences...). Compilation advances a little, and hangs again, showing the error message of the first post:
/usr/bin/nasm -O99 -f elf64 -D __GCC2 -g -F dwarf -I../../src/ -w-orphan-labels mdZ80_x86.asm -D __PIC -o .libs/mdZ80_x86.o
mdZ80_x86.asm:2511: error: instruction not supported in 64-bit mode
So I post here, and got the advice to make a VM and build in it - but knowing (and saw) in Arch Linux and Debian is possible to compile
Gens-gs-r7 in
multilib... So, I want to try again...
Then, I began to study, and learn that
elf64 are
64 bits objects - why the compiler are making it, in the middle of the process, since I set the
-m32 flag, telling the compiler to produce
32 bit code... Where they come from? Studying a bit more, I discover that the compiler (
gcc/g++) pass the flags to the
linker/assembler(in a cascade of events), so I think: this error could be the
linker... let set the linker's flags to produce
32 bit code (see here:
http://forum.nasm.us/index.php?topic=754.0)
I did this, and didn't work - for several reasons... There are several types of objects (
elf32,
elf64,
elfx64 - if you want to know what type of object
NASM produces, type in a terminal:
$ nasm -hf), and when you begin to try this path, you
HAVE to match
previous object with the
following, and this begins to be a
'trial-and-error-game', if you don't REALLY know what you're doing - that was my case...
But, in this moment, I calm down and study a little more: why I still getting
64 bits objects? I read a bit more, and learned:
the compiler are making it, since it got them from the
$ARCH (the enviroment/machine) variables - remember, I set
$ARCH to
x86_64, and set the
-m32 flag...so, the compiler produces
32-bit code
BUT (in some point) when it re-check the
$ARCH or another enviromment variable (like the
$TARGET =
x86_64-slackware-linux, or the
$HOST) , it begins to (re)make a
64 bits code...in the middle of process...so, this explain the fact that, using a
64 bit ARCH (
x86_64) and
-m32, switch, my compilation advances a little and hangs... But, hey, I'm a stubborn people, and the wiki says to mantain the
$ARCH as x86_64, and when I compiled Zsnes (now I realize how luck I was), I didn't change the
$ARCH - let's set the
$HOST/TARGET to
i686-unknown-linux-gnu in the script (like
this guy: http://whynotwiki.com/How_I_installed_z ... -bit_Linux):
Code: Select all
export HOST=i686-unknown-linux-gnu
export TARGET=i686-unknown-linux-gnu
...and this can't solve my problem. Compilation won't advance anymore. Maintaining the
$ARCH as
x86_64 and dealing with the errors, setting enviroment or linker variables, 'forcing the way' isn't the right thing to do... I become tired and left this compilation...
Second part: Found the PhantomXscripts (Multilib ready!)
I'm tired, but I still want to test my Multilib... So I began to find another 32 bit program, and searched for
lxdream - a 32 bit Dreamcast Emu. I tried to build it in my Salix 13.37 64 bits Multilib, but failed - for several reasons. Now I want to try in Salix 14 64 bits Multilib... went to DDG search , and wrote
lxdream slackbuild - and, for my surprise, it return's a result:
PhantomX/slackbuilds · GitHub. I entered his page, (
https://github.com/PhantomX/slackbuilds) and surprise: he is a mantainer of several scripts for slackware (like one to recompile automatically the kernel! Whoa!). So, I grab the script and files for
lxdream, edit it (but this scripts, in a first look, are different from those of Slackbuild.org - but I'm tired...), run and got lxdream working in my machine... So easy...
Looking in his page, I see a script for
Gens-gs... so I give a try... got the script, edit it, and try to build... compilation begins and hangs, showing a different error: what is happening? I looked deeper in the script, and found a section
already ready to
multilib (with the g
cc/g++ -m32 flags). What is this? The script are
multilib ready! So, I wrote a e-mail to him - since the script is
much more complex than those of
Slackbuilds.org (it makes a change of
$ARCH and
$SLKTARGET variables, in the multilib section). He answers my e-mail, saying:
to compile in multilib, just pass ARCH=i686 when you run the script, and you will done...
Do:
# ARCH=i686 ./gens-gs.Slackbuild
or better:
# ARCH=i686 SB_NATIVE=yes./gens-gs.Slackbuild 2>&1 | tee build.log
(SB_NATIVE is for use GCC>=4.2, 2>&1 | tee build.log is for create a .log file - which was very usefull for me...
So, I did it... compilation advances, locks, but
produce ELF objects (
32 bits)!. Less one BIG error! Don't have to worry anymore with
$ARCH and
ELF64!
Ok, with this I'm really convinced that is the way... so I began to work with this script... The next error, is the script say a warning that can't find "
automake-1.10"? I write in a terminal "$ automake --version" - answer "
1.11.5". I checked the Salix 14 packages, and in the Slackware 14 (not current) packages files, and for both (
i486 or
x86_64), automake version is
1.11.5. Strange thing... I went to
Slackbuilds.org and the (
gens-gs.tar.gz) file is the same... now I found a
old version!I decided to
don't downgrade my automake (why? I'm using the official version...) and
patch the file to use the automake version of
my machine! So, I searched for automake=1.10 references in gens-gs-r7 folder... found it (in
configure and
configure.ac - later in
acloca.m4), changed to
1.11 (I tried 1.11.5 and got a error, so I do
$ file /usr/bin/automake and get "symbolic link to `automake-
1.11'"). And then, it worked...
Compilation advances, but I got another error:
make[4]: Enter folder `/tmp/gens-gs-r7/src/extlib/minizip'
mv -f .deps/libminizip_la-ioapi.Tpo .deps/libminizip_la-ioapi.Plo
mv -f .deps/libminizip_la-unzip.Tpo .deps/libminizip_la-unzip.Plo
mv: mv: impossible obtain state of “.deps/libminizip_la-ioapi.Tpo”mpossible obtain state of “.deps/libminizip_la-unzip.Tpo”:File or folder not found
: File or folder not found
make[4]: ** [libminizip_la-unzip.lo] Error 1
Wrote a e-mail to
PhantomX - the answer came quickly: "put
autoreconf -ivf in the script...". Do this, and the error disappears.
But another error appeared (this was hard to find, but easy to solve):
Code: Select all
libtool: link: g++ -m32 -Wall -Wextra -O0 -ggdb -fvisibility-inlines-hidden -DGENS_DATADIR=\"/usr/share/gens-gs\" -DGENS_MDP_DIR=\"/usr/lib/mdp\" -DGENS_DOC_DIR=\"/usr/doc/gens-gs-r7\" -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -O2 -march=i686 -mtune=i686 -Wl,--as-needed -Wl,--hash-style=both -Wl,-z -Wl,noexecstack -o gens emulator/gens-gens.o emulator/gens-g_main.o emulator/gens-g_md.o emulator/gens-g_mcd.o emulator/gens-g_32x.o emulator/gens-md_palette.o emulator/gens-g_update.o emulator/gens-parse.o emulator/gens-options.o gens_core/cpu/68k/gens-cpu_68k.o gens_core/cpu/sh2/gens-cpu_sh2.o gens_core/cpu/sh2/gens-sh2.o gens_core/cpu/z80/gens-cpu_z80.o gens_core/sound/gens-pcm.o gens_core/sound/gens-psg.o gens_core/sound/gens-ym2612.o gens_core/sound/gens-pwm.o gens_core/mem/gens-mem_z80.o gens_core/gfx/gens-fastblur.o gens_core/misc/gens-cpuflags.o gens_core/gfx/gens-fastblur_16_x86.o gens_core/gfx/gens-fastblur_32_x86.o audio/gens-audio_mmx.o gens_core/io/gens-io.o gens_core/io/gens-io_teamplayer.o gens_core/vdp/gens-vdp_io.o gens_core/vdp/gens-vdp_rend.o gens_core/vdp/gens-vdp_32x.o gens_core/vdp/gens-vdp_32x_32bit.o macros/gens-log_msg.o port/gens-ini.o segacd/gens-cd_file.o segacd/gens-cd_sys.o segacd/gens-lc89510.o ui/gens-gens_ui.o ui/common/gens/gens-gens_menu.o ui/common/gens/gens-gens_menu_callbacks.o ui/common/gens/gens-gens_window_sync.o ui/common/gens-about_window_data.o ui/common/gens-dir_window_common.o ui/common/gens-pmgr_window_common.o ui/common/gens-bmf_window_common.o util/file/gens-config_file.o util/file/gens-rom.o util/file/gens-save.o util/file/gens-file.o util/file/decompressor/gens-decompressor.o util/file/decompressor/gens-dummy.o util/file/decompressor/gens-md_rar.o util/file/decompressor/gens-md_rar_t.o util/gfx/gens-imageutil.o util/sound/gens-gym.o util/sound/gens-wave.o video/gens-C64_charset.o video/gens-osd_charset.o video/gens-vdraw.o video/gens-vdraw_cpp.o video/gens-vdraw_text.o video/gens-v_effects.o video/gens-vdraw_RGB.o input/gens-input.o input/gens-input_update.o audio/gens-audio.o plugins/gens-pluginmgr.o plugins/gens-rendermgr.o plugins/gens-mdp_host_gens.o plugins/gens-mdp_host_gens_cpp.o plugins/gens-mdp_host_gens_menu.o plugins/gens-mdp_host_gens_event.o plugins/gens-mdp_host_gens_mem.o plugins/gens-mdp_host_gens_emuctrl.o plugins/gens-mdp_host_gens_z.o plugins/gens-mdp_host_gens_config.o plugins/gens-mdp_host_gens_dir.o plugins/reg/gens-reg_get.o plugins/reg/gens-reg_set.o plugins/reg/gens-reg_get_all.o plugins/reg/gens-reg_set_all.o plugins/gens-eventmgr.o plugins/gens-mdp_incompat.o debugger/gens-debugger.o debugger/gens-m68kd.o debugger/gens-sh2d.o debugger/gens-z80dis.o segacd/gens-cdda_mp3.o util/file/decompressor/gens-md_gzip.o util/file/decompressor/gens-md_zip.o util/file/decompressor/gens-md_7z.o emulator/gens-g_main_unix.o port/gens-ini_old.o port/gens-timer.o charset/gens-iconv_string.o video/gens-vdraw_sdl_common.o video/gens-vdraw_sdl.o input/gens-input_sdl.o input/gens-input_sdl_events.o input/gens-input_sdl_key_names.o audio/gens-audio_sdl.o segacd/gens-cd_aspi_linux.o ui/gtk/gens-gens_ui_gtk.o ui/gtk/gens-gtk-misc.o ui/gtk/gens-gtk-uri.o ui/gtk/gens/gens-gens_window.o ui/gtk/gens/gens-gens_window_callbacks.o ui/gtk/gens/gens-gens_window_sync.o ui/gtk/gens/gens-gens_menu.o ui/gtk/controller_config/gens-cc_window.o ui/gtk/bios_misc_files/gens-bmf_window.o ui/gtk/directory_config/gens-dir_window.o ui/gtk/general_options/gens-genopt_window.o ui/gtk/color_adjust/gens-ca_window.o ui/gtk/country_code/gens-ccode_window.o ui/gtk/zip_select/gens-zipsel_dialog.o ui/gtk/plugin_manager/gens-pmgr_window.o ui/gtk/about/gens-about_window.o video/gens-vdraw_sdl_gl.o ui/gtk/opengl_resolution/gens-glres_window.o video/gens-vdraw_gl_glx.o ui/gtk/select_cdrom/gens-selcd_window.o gens_core/gfx/gfx_cd.o gens_core/mem/mem_m68k.o gens_core/mem/mem_m68k_cd.o gens_core/mem/mem_m68k_32x.o gens_core/mem/mem_s68k.o gens_core/mem/mem_sh2.o gens_core/misc/misc.o gens_core/cpu/sh2/sh2a.o gens_core/cpu/sh2/sh2_io.o gens_core/vdp/vdp_32x_x86.o gens_core/vdp/vdp_io_x86.o gens_core/vdp/vdp_rend_x86.o debugger/mcd_cell_dump.o -Wl,-rpath -Wl,/usr/lib64 plugins/render/normal/.libs/libmdp_render_1x.a plugins/render/double/.libs/libmdp_render_2x.a /usr/lib64/../lib/libstdc++.so ../../src/starscream/.libs/libstarscream.a ../../src/mdZ80/.libs/libmdZ80.a ../../src/libgsft/.libs/libgsft.a fw/.libs/libgens_fw.a ../../src/extlib/mp3_dec/.libs/libmp3_dec.a ../../src/extlib/minizip/.libs/libminizip.a ../../src/libgsft/.libs/libgsft_png.a /usr/lib/libpng14.so ../../src/extlib/lzma/.libs/liblzma.a -L/usr/lib64 /usr/lib64/libSDL.so /usr/lib64/libXrandr.so -lvga -L/usr/lib /usr/lib64/libgtk-x11-2.0.so /usr/lib64/libgdk-x11-2.0.so /usr/lib64/libatk-1.0.so /usr/lib64/libpangocairo-1.0.so /usr/lib64/libpangoft2-1.0.so /usr/lib64/../lib64/libstdc++.so /usr/lib64/libgdk_pixbuf-2.0.so /usr/lib64/libgio-2.0.so -lresolv /usr/lib64/libcairo.so /usr/lib64/libpixman-1.so /usr/lib64/libpng14.so /usr/lib64/libXrender.so /usr/lib64/libxcb.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so /usr/lib64/libpango-1.0.so /usr/lib64/libgmodule-2.0.so /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so -lz -lbz2 /usr/lib64/libexpat.so /usr/lib64/libgobject-2.0.so /usr/lib64/libgthread-2.0.so /usr/lib64/libffi.so /usr/lib64/libglib-2.0.so -lpthread -lrt /usr/lib64//libGL.so -L/usr/lib64/ /usr/lib64/libXext.so /usr/lib64/libX11.so -lm /usr/lib/libXext.so /usr/lib/libX11.so /usr/lib/libxcb.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -ldl -pthread -Wl,-rpath -Wl,/usr/lib64/../lib -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64/../lib64 -Wl,-rpath -Wl,/usr/lib64/ -Wl,-rpath -Wl,/usr/lib64/../lib -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64/../lib64 -Wl,-rpath -Wl,/usr/lib64/
/usr/[b]lib64[/b]/[b]libSDL.so[/b]: could not read symbols: File in wrong format
Apparently, it appears to see a path(?) problem (I thought in a first moment)... Notice /usr/
lib64... So I began to look the logs ( the
build.log, and the
compile.log in
/tmp folder) to trace the problem... Everytime I found a normal path (/lib, but then --libdir=/usr/lib
64...). So, I began to manually set the
$PATH and
$LIB$ variables in the script... Didn't work... And I began to look deeper - in the
makefile file, in the
configure file, and, no matter what I do, I can't change this paths... Tried the
. /etc/profile.d/32dev.sh - don't work. Try to export the paths of
/etc/profile.d/32dev.sh into the script - nothing. And sometimes, I notice a
PKG_CONFIG_PATH='/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/
lib64/pkgconfig:/usr/
lib64/pkgconfig'... strange...
So, I got angry, and begin to think about the
$HOST and
$TARGET - tried it, with no effect.
And then, I take a time. Calm down, wrote another e-mail to
PhantomX . He answered: "it could be a
one lib error, that generate a
cascade of errors. You have to find it."So, I began (again) to trace the paths in the configure and makefile... and I discover a strange thing: in the
config.log there's a
SDL PATH to /usr/
bin/sdl-config... but hey, I have both SDL (
64bits) and SDL-compat32 (
32 bits) libs in my system... where are they config files? So, a
locate sdl-config
did the trick:
Code: Select all
/usr/bin/sdl-config
/usr/bin/32/sdl-config
Then, I realized: could be the a
wrong config file version , that loads incorrect paths?...So, I set in the script:
Code: Select all
export SDL_CONFIG="/usr/bin/32/sdl-config"
and...
this solved my problems! Compilation ends, and I can grab my package! Yeah, baby, yeah!
Third part:Final errors. Polishing the script
Finally I can install
gens-gs-r7 in my machine. Do a
installpkg, and the run gens-gs in a terminal:
:
and got two errors:
Code: Select all
gens-gs:16008): Gtk-WARNING **: Error loading theme icon 'gtk-ok' for stock: image format dont recognized
...
(gens-gs:16008): Pango-CRITICAL **: No modules found:
No builtin or dynamically loaded modules were found.
PangoFc will not work correctly.
This probably means there was an error in the creation of:
'/etc/pango/pango.modules'
You should create this file by running:
pango-querymodules > '/etc/pango/pango.modules'
I became sad... Pango and Gtk errors (when this errors stops to appear?)...The gens-gs fonts are uggly, can't read anything... so, tried the suggestion above: create pango modules...didn't work...used a GTk-patch in the script (disabled by default)...nope...and though about to create a 32 version of pango(!) But, I search in the net, and found this
https://www.linuxquestions.org/question ... -a-819115/... Well, I tried:
Code: Select all
# /usr/bin/update-gtk-immodules --verbose
# /usr/bin/update-gdk-pixbuf-loaders --verbose
# /usr/bin/update-pango-querymodules --verbose
and... my errors are
gone! Can run
gens-gs perfectly, fonts and Gtk themes are ok! OpenGl video, graphics filters - all works! Yeah!
Now, to make things better, I'm polishing the script, removing unnecessary paths left (since I heavily edited it, and the script still have some modifications), leaving just the necessary. To a better process, created a patch for automake-1.11 (don't want to edit the
tar.gz file every time). Wrote to
PhantomX about the modifications and the patch. Let's see his opinion.
Add: I'm tired of writting this post. Hope it can clarify some things about compilating programs in Multilib... I wrote in this style, writing all my thoghs and errors, to show what worked and what don't.
Excuse my english. Any doubts, ask me, and I gadly try to answer.
