hex package 1.0.4 has .o files in c_src folder

[skorobkov]

https://diff.hex.pm/diff/jiffy/1.0.3..1.0.4 Because of that, can't compile: c_src/decoder.o: file not recognized: File format not recognized collect2: error: ld returned 1 exit status sh(c++ c_src/decoder.o c_src/encoder.o c_src/jiffy.o c_src/termstack.o c_src/utf8.o c_src/util.o c_src/doubles.o c_src/objects.o c_src/double-conversion/bignum-dtoa.o c_src/double-conversion/bignum.o c_src/double-conversion/cached-powers.o c_src/double-conversion/diy-fp.o c_src/double-conversion/double-conversion.o c_src/double-conversion/fast-dtoa.o c_src/double-conversion/fixed-dtoa.o c_src/double-conversion/strtod.o -flto -lstdc++ -shared -L"/opt/otp/22.2.8/lib/erl_interface-3.13.1/lib" -lerl_interface -lei -o priv/jiffy.so) failed with return code 1 and the following output: c_src/decoder.o: file not recognized: File format not recognized collect2: error: ld returned 1 exit status

Git version {jiffy, {git, "https://github.com/davisp/jiffy.git", {tag, "1.0.4"}}} doesn't have such problem

[aboroska]

@skorobkov What is your rebar3 version? A recent version compiles it. I use 3.13.0 for example.

Or if you use mix you can update rebar3 by:

curl -O https://rebar3.s3.amazonaws.com/rebar3
mix local.rebar rebar3 rebar3 --force

[nalundgaard]

I concur that upgrading rebar3 to the latest (3.13.1 today) obviates this issue. Still, one wonders what the point of putting compilation artifacts in a hex package would be.

[davisp]

Just an accident on my part that I've not gotten around to cleaning up. I'll make a note to fix my release script.

[nalundgaard]

Great. No rush on it, since it looks like the latest rebar3 ignores them appropriately.

[davisp]

Long since cleaned this up.