| |
Frostbyte
Registered: Aug 2003
Posts: 181 |
Release id #214996 : Dali V0.3 (2022.02.21)
Has anyone successfully compiled this for macOS? Mojave, to be specific. I've installed the required dependencies via Homebrew ('brew install acme' for Acme, 'brew install binutils' for objcopy), but the build fails on the following error:
clang: error: cannot specify -o when generating multiple output files
What I searched online, this could possibly be because I have a newer version of clang which is not happy about the header file prerequisites on the target, but
1) I don't know what older version of clang I should have for these to be ignored or even how to downgrade clang which I believe comes as part of Xcode's Command line tools, and
2) how to fix the makefile to work with the newer version of clang. My C and make skillz are pretty non-existent, unfortunately. :(
'clang --version' returns
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
The full make output for reference:
$ make
Compiling sfx code for dali...
Warning - File sfx.asm, line 382 (Zone <untitled>): !warn: sfx zp size: 183 (0xb7)
Warning - File sfx.asm, line 383 (Zone <untitled>): !warn: sfx size: 209 (0xd1)
Compiling sfx code for dali...
Warning - File sfx.asm, line 380 (Zone <untitled>): !warn: zp saved/restored up to: 227 (0xe3)
Warning - File sfx.asm, line 382 (Zone <untitled>): !warn: sfx zp size: 238 (0xee)
Warning - File sfx.asm, line 383 (Zone <untitled>): !warn: sfx size: 270 (0x10e)
Creating salvador library...
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/salvador.c -o obj/src/salvador.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/expand.c -o obj/src/expand.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/matchfinder.c -o obj/src/matchfinder.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/shrink.c -o obj/src/shrink.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/libdivsufsort/lib/divsufsort.c -o obj/src/libdivsufsort/lib/divsufsort.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/libdivsufsort/lib/divsufsort_utils.c -o obj/src/libdivsufsort/lib/divsufsort_utils.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/libdivsufsort/lib/sssort.c -o obj/src/libdivsufsort/lib/sssort.o
gcc -O3 -g -fomit-frame-pointer -Isrc/libdivsufsort/include -Isrc -fPIC -c src/../src/libdivsufsort/lib/trsort.c -o obj/src/libdivsufsort/lib/trsort.o
gcc obj/src/salvador.o obj/src/expand.o obj/src/matchfinder.o obj/src/shrink.o obj/src/libdivsufsort/lib/divsufsort.o obj/src/libdivsufsort/lib/divsufsort_utils.o obj/src/libdivsufsort/lib/sssort.o obj/src/libdivsufsort/lib/trsort.o -o salvador
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: salvador.a(divsufsort_utils.o) has no symbols
Building dali...
clang: error: cannot specify -o when generating multiple output files
make: *** [dali] Error 1 |
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
I recommend you check out the latest version directly from teh bitfire repo and use the dali from there, this is fixed meanwhile as far as i know. I'm sorry for those intermediate releases that i never did, i always recommend to stick to the repo.
-> https://github.com/bboxy/bitfire
In fact i link the dali and salvador part in a different way now, by just renaming and overwriting the main function now instead of linking via a library, which fails on MacOS as it defaults to clang and not gcc. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting BitbreakerIn fact i link the dali and salvador part in a different way now, by just renaming and overwriting the main function now instead of linking via a library, which fails on MacOS as it defaults to clang and not gcc. Iirc, there is also (still) no working objcopy for M1 etc., so renaming symbols in object files doesn't work.
There should be a better way to do what you want to do, such as introducing a define for Salvador's main() function to make it have a different name right when compiling already.
Or rename it to something else, then have a very thin Salvador main() wrapper function in its own compilation unit, only calling the former, which would not be included in Dali. =) |
| |
Frostbyte
Registered: Aug 2003
Posts: 181 |
Well that was an easy solution, thanks! Took me a second to realise that salvador directory was empty, as in github it was just a reference to the salvador git repo. But after cloning that too, it was just "a push of a button" to build. :)
Thanks again @Bitbreaker, much appreciated!
PS. Should I share the v0.3.2 macOS Mojave executable somewhere? Would maybe prefer not to do a CSDB release out of it, but maybe it could be dumped into the git repo to some precompiled bins folder? |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Quote: Well that was an easy solution, thanks! Took me a second to realise that salvador directory was empty, as in github it was just a reference to the salvador git repo. But after cloning that too, it was just "a push of a button" to build. :)
Thanks again @Bitbreaker, much appreciated!
PS. Should I share the v0.3.2 macOS Mojave executable somewhere? Would maybe prefer not to do a CSDB release out of it, but maybe it could be dumped into the git repo to some precompiled bins folder?
That is what i basically do meanwhile? :-)
//include salvador and rename main
#define main salvador_main
#include "salvador/src/salvador.c"
#undef main
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Quoting Frostbyte
PS. Should I share the v0.3.2 macOS Mojave executable somewhere? Would maybe prefer not to do a CSDB release out of it, but maybe it could be dumped into the git repo to some precompiled bins folder?
I prefer not having binaries in the repo, as things can always be build from source for any target desired. But feel free to spread/release any binary as you wish :-) |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
I built a win x64 exe and upped it here for completeness and for those not wanting to install a msys2 environment and apply the needed changes to make it work
Dali V0.3.2 |
| |
Burglar
Registered: Dec 2004
Posts: 1085 |
trying to find a changelog, cuz uhm, I have dali 0.1 installed, now installed the new one, it packs a bit slower with the same result.. so.. what changed? |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
change path vars
build without objcopy and ar
return to left shift
finally ceased that big endianess on dest addr
add a flag to exit on i/o warning
fix carry bug
clean up
fix bug with prefix
macro for inc <lz_src + 1
fix --binfile to only add load-address and depack-address if relocating
add --prefix-file option and clean up
use FILE* for tempfile
make proper use of tmpfiles for dict
fix error handling for dict file
add --prefix-from
add info about small sfx
make it more obvious that hex nums work
make read_number throw appropriate errors on invalid numbers, give more info
combine small/fast sfx in one file and compile conditionally
move some code to other file
make little endian elias gamma configurable
integrate small and fast sfx
switch over to right shift in lz_bits
add --cli option
$01 can be set for sfx, save/restore most of zp while depacking
back to normal lz_bits, keep compatible
changed encoding to save bytes in the resident part
throw error if packed fiule is bigger than original
save bytes
reducing size of executable
fix file creation bug
reduce argv array elems
clean up
fix naming
rename recoder and move around things
This is what gitlog says what changed up until today.
It is okay to use whatever version for sfx (though that also changed a bit) if compatibility is needed, it is always advisable to use the version coming along with bitfire, as it contains a suitable depacker. i did a few format changes on the way. |
| |
Burglar
Registered: Dec 2004
Posts: 1085 |
thanks for the quick reply :)
ah yea, decruncher-changes, the thing I didn't check /o\ |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting Burglarah yea, decruncher-changes, the thing I didn't check /o\ You wondered about the slower crunching, though. :)
I guess that stuff would fall more into the domain of the underlying Salvador/ZX0 cruncher that Dali wraps, which probably did have a few changes, too. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Quote: Quoting Burglarah yea, decruncher-changes, the thing I didn't check /o\ You wondered about the slower crunching, though. :)
I guess that stuff would fall more into the domain of the underlying Salvador/ZX0 cruncher that Dali wraps, which probably did have a few changes, too.
Right, dali is just reading in the zx0-stream, reencoding it with swapped lo/hibyte on the lengths, changed bitshift-direction and adding all the stuff that is for good use on c64 side, like a sfx, inplace depacking, load-address handling, cutting the source into pieces, as well as using previous data as dictionary. Overall pretty lean processes compared to crunching :-) |
| |
Frostbyte
Registered: Aug 2003
Posts: 181 |
Better late than never... Added v0.3.2 compiled on macOS Mojave to the release: Dali V0.3.2 |
