Query: capsimg.so doesn't compile? (also not present in recent binary releases)

[giantclambake]

Query: capsimg.so doesn't compile? (also not present in recent binary releases)

[giantclambake]

...bit more digging.... citing wiki/FAQ ...

If you have downloaded a pre-compiled release, the library is already included in the archive.

This isn't so ~ the binary tarballs for amiberry-v5.7.3 and amiberry-6.3.3 do NOT contain the capsimg.so library...

...so this must be broken on the build bots as well?

M'kay... so it's broke, but where? First notion I had, was that $PLATFORM isn't being considered, so maybe that's why it's emitting the complaint about --host?

Following on from above example...

cd ~/testingcaps/amiberry/external/capsimg/CAPSImg
./configure

....actually succeeds...

gcb@gallah:~/testingcaps/amiberry/external/capsimg/CAPSImg$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... unsupported
checking for g++ option to enable C++98 features... unsupported
checking for a BSD-compatible install... /usr/bin/install -c
checking for tar... tar
checking for sfd... no
checking for fd2inline... no
checking for autodoc... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dirent.h... yes
checking for struct dirent.d_type... yes
checking whether byte ordering is bigendian... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h

....follow on with make ... compiles successfully it seems....(last line)

g++ -shared -Wl,-soname,libcapsimage.so.5 -Wl,--version-script,libcapsimage.map -fPIC ../Codec/CTRawCodec.o ../Codec/CTRawCodecDecompressor.o ../Codec/DiskEncoding.o ../Core/BaseFile.o ../Core/BitBuffer.o ../Core/CRC.o ../Core/DiskFile.o ../Core/MemoryFile.o CapsAPI.o CapsFDCEmulator.o CapsFile.o CapsFormatMFM.o CapsImage.o CapsImageStd.o CapsLoader.o DiskImage.o DiskImageFactory.o stdafx.o StreamCueImage.o StreamImage.o -o libcapsimage.so.5.1

gcb@gallah:~/testingcaps/amiberry/external/capsimg/CAPSImg$ ls -l libcapsimage.so.5.1
-rwxr-xr-x 1 gcb gcb 532664 Jun 25 09:29 libcapsimage.so.5.1

....probably not stripped, and $prefix looks wrong to me (prefix=usr/local/ ) ...

...but this suggests the error is instantiated from the top level directory, not from here...

I wonder if cmake works?.....retest....

[giantclambake]

....nope....

~/testingcaps/amiberry/external/capsimg/CAPSImg$make distclean //cleanup
~/testingcaps/amiberry/external/capsimg/CAPSImg$cd .. //lets check here...
~/testingcaps/amiberry/external/capsimg$./configure //completes
~/testingcaps/amiberry/external/capsimg$make //compiles successfully

g++ -shared -Wl,-soname,libcapsimage.so.5 -Wl,--version-script,libcapsimage.map -fPIC ../Codec/CTRawCodec.o ../Codec/CTRawCodecDecompressor.o ../Codec/DiskEncoding.o ../Core/BaseFile.o ../Core/BitBuffer.o ../Core/CRC.o ../Core/DiskFile.o ../Core/MemoryFile.o CapsAPI.o CapsFDCEmulator.o CapsFile.o CapsFormatMFM.o CapsImage.o CapsImageStd.o CapsLoader.o DiskImage.o DiskImageFactory.o stdafx.o StreamCueImage.o StreamImage.o  -o libcapsimage.so.5.1
make[1]: Leaving directory '/home/gcb/testingcaps/amiberry/external/capsimg/CAPSImg'
cp CAPSImg/libcapsimage.so.5.1 capsimg.so

That actually appears 'sane' to me, and $prefix would appear correctly set - I'll come back to here after checking cmake;

~/testingcaps/amiberry/external/capsimg$make distclean //cleanup
~/testingcaps/amiberry/external/capsimg$cd ../.. //goto top-level
~/testingcaps/amiberry$mkdir build && cd build
~/testingcaps/amiberry/build$cmake ..

That's all I need here, check if cmake ropes in external/capimg...

~/testingcaps/amiberry/build$ ls external
floppybridge libguisan mt32emu

Nope... it doesn't, and the Makefile has no capsimg target ...so we are boned here as well ;)

M'kay.... I can go back to external/capsimg and go on to test IPF support...but first, when did this break?

*capsimg.so not present in binary tarballs after amiberry v5.6.5 //normal branch

*capsimg.so not present in binary tarballs after amiberry v6.1.2 //preview branch

That's likely enough triage for you to clean-up/check this boofle =)

--added IPF support check to my local testing protocol

HTH

Edit: Further... from wiki/FAQ;

You will need to copy the file above into the same directory your amiberry binary is located, so it can open it on startup.

E.g. if you're running RetroPie: sudo cp capsimg.so /opt/retropie/emulators/amiberry/

That appears incorrect, when looking at the top-level Makefile I see;

# The CAPSImg library that Amiberry uses, for accessing IPF disk images
capsimg:
        cd external/capsimg && ./bootstrap && ./configure && $(MAKE)
        cp external/capsimg/capsimg.so ./plugins

Ergo, cwd/plugins is the correct location, and no longer in cwd as the wiki describes.

[midwan]

I've updated the wiki with the manual steps to compile the library.
I'm not sure why, but the call from the Makefile doesn't seem to work anymore. I'll look into it when I get a chance, but for now, you can still build it manually if you want.

And yes, libraries now live inside the plugins directory (wiki updated accordingly).

[giantclambake]

Better, however "But if you have compiled Amiberry from source yourself" ...is still ambiguous.

That is, if the source is the Source Code tarball/zip from https://github.com/BlitterStudio/amiberry/releases, then the command git submodule update --init will certainly fail...

gcb@gallah:~/TMP/amiberry-preview-v6.3.3$ git submodule update --init
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

[giantclambake]

Not sure what the cause is yet, but I see the problem...

If you invoke make capsimg from the top-level directory ($CWD)...

configure:3290: $? = 1
configure:3310: checking whether the C compiler works
configure:3332: gcc -Wall -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -g  -pipe -Wno-shift-overflow -Wno-narrowing -fno-pie -O3  -O2 -fomit-frame-pointer
 -MD -MT capsimg -MF capsimg -I/usr/include/SDL2 -D_REENTRANT -Iexternal/libguisan/include -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archivers -Iexterna
l/floppybridge/src -Iexternal/mt32emu/src -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DARM_HAS_DIV  conftest.c  >&5
configure:3336: $? = 0
configure:3386: result: yes
configure:3389: checking for C compiler default output file name
configure:3391: result: a.out
configure:3397: checking for suffix of executables
configure:3404: gcc -o conftest -Wall -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -g  -pipe -Wno-shift-overflow -Wno-narrowing -fno-pie -O3  -O2 -fomit-f
rame-pointer -MD -MT capsimg -MF capsimg -I/usr/include/SDL2 -D_REENTRANT -Iexternal/libguisan/include -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archive
rs -Iexternal/floppybridge/src -Iexternal/mt32emu/src -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DARM_HAS_DIV  conftest.c  >&5
configure:3408: $? = 0
configure:3431: result:
configure:3453: checking whether we are cross compiling
configure:3461: gcc -o conftest -Wall -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -g  -pipe -Wno-shift-overflow -Wno-narrowing -fno-pie -O3  -O2 -fomit-f
rame-pointer -MD -MT capsimg -MF capsimg -I/usr/include/SDL2 -D_REENTRANT -Iexternal/libguisan/include -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archive
rs -Iexternal/floppybridge/src -Iexternal/mt32emu/src -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DARM_HAS_DIV  conftest.c  >&5
/usr/bin/ld: /tmp/ccCGN1tm.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
configure:3465: $? = 1
configure:3472: ./conftest
./configure: line 3474: ./conftest: No such file or directory
configure:3476: $? = 127

...however, if you cd external/capsimg and invoke ./bootstrap && ./configure (pretty much what make capsimg does), it follows a completely different code path for sanity checking.

The only thing that really stood out to me, is that from $CWD the ./configure call is inheriting...

ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=' -pipe -Wno-shift-overflow -Wno-narrowing -fno-pie -O3 '
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value='-MD -MT capsimg -MF capsimg -I/usr/include/SDL2 -D_REENTRANT -Iexternal/libguisan/include -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include
-Isrc/archivers -Iexternal/floppybridge/src -Iexternal/mt32emu/src -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DARM_HAS_DIV'
ac_cv_env_CXXFLAGS_set=set
ac_cv_env_CXXFLAGS_value=' -pipe -Wno-shift-overflow -Wno-narrowing -fno-pie -O3 -std=gnu++17'

...running ./configure in external/capsimg has these unset ...but that's just a script...

#!/bin/sh

set -e

cd CAPSImg
if [ "$1" = "--enable-static" ]; then
LDFLAGS="-static -static-libgcc -static-libstdc++" ./configure
else
./configure "$@"
fi

...me thinks somewhere around here is the problem...

[midwan]

Yeah, most likely.
I think I will just include the sources in there directly, and perhaps change them a bit so they build properly through the Makefile and CMakeLists.txt both. Having them as a submodule was useful if they got updated often, but there haven't been any updates for a few years now.

[giantclambake]

That makes the most sense to me ~ we routinely build the other plugins at make PLATFORM=? time, so we might as well build capsimg.so at that time too (especially as it's shipped with the binary releases). If in future it's ever updated, that bridge can be crossed when ever it may become apparent ;)

[midwan]

This is now fixed.

I've included the sources directly, removed the submodule, and updated things to the library is built automatically and placed in the plugins folder as expected.

The naming has changed, so it's now called libcapsimage.so instead of capsimg.so, to be more consistent with the other libraries. The wiki FAQ has also been updated accordingly.

And finally, the build pipeline was also updated to reflect these changes (it should be packaged with the next release).