update with prefix and ".a"

[delabj]

Following the example in r-rust/hellorust#9

I added a lib prefix and a .a suffix to the STATLIB line

[clauswilke]

Thanks! The AppVeyor build is still failing, though. Could you see if you can figure out what's going wrong? Does this work for you locally?

[delabj]

I'm able to get further than I could before, but I'm getting a new error

error: expected `;`
  --> src\style\properties\definitions.rs:82:30
   |
82 |         "margin" => FourSides<SpecifiedLengthOrPercentageOrAuto> {
   |                              ^
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

[clauswilke]

Ah, that's actually a problem with the Rust code. Some of the libraries I'm depending on may have changed and it'll require some modification to the code or explicitly using an older version. Unfortunately this isn't going to be an easy fix most likely. I'll take on this project again at some point but right now I'm focusing on better R-Rust interoperability in general.

[delabj]

Makes sense. I'm excited to see where R-Rust goes!

[clauswilke]

I just committed by Cargo.lock file. This should allow you to build the project. Merge in master and see what happens.

[delabj]

I got further, but I've been compiling unicase v2.6.0 for about 40 minutes so something may not be working.

[clauswilke]

Yeah, that doesn't sound right. The entire build takes maybe 2-3 min on my laptop. The CI builds also still fail. I'll have to investigate more.

[clauswilke]

On AppVeyor, the error message is:

C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc_eh
          collect2.exe: error: ld returned 1 exit status      

That looks like a problem in the toolchain, possibly with Rtools.

On Travis, the build breaks because textshaping can't be installed from CRAN. This has nothing to do with my code and is just a reflection of a broken Travis setup. I'll probably have to set up github actions to see if something is fundamentally broken.

[clauswilke]

So the compile error you saw earlier seems correct. I'm getting it on a clean build on ubuntu 20.4 also:
https://github.com/clauswilke/sinab/runs/1478056367#step:10:210

I suspect something has changed in the latest version of rustc. My local one is a few months old, and there were some changes introduced that recently that may break some macros. I'll have to see how easy it is to fix.

[clauswilke]

Ok, I fixed the issue in the rust code related to the latest changes in rustc. That lets me build sinab on ubuntu. However, it still doesn't build on Windows, for some unrelated linking issue. I've opened an issue: #13

I'll close this PR, as I've already added this change into the code:

sinab/src/Makevars.win

Line 3 in d8bbfbf

STATLIB = $(LIBDIR)/libsinab.a

It's not the reason why the Windows build won't succeed.

[clauswilke]

Just an FYI: The latest code base does compile on Windows, just not on AppVeyor:
#13 (comment)

Maybe try your local build one more time.

[delabj]

As an update, I was unable to get it to work on my main machine. But this could just be a bad Rust set up.

[clauswilke]

Could you describe the problem? Was it also the missing gcc_eh library as on the AppVeyor runs?

[clauswilke]

@delabj FYI, I've learned a lot about building rust apps on windows lately. If your default host is x86_64-pc-windows-gnu (which the Sinab documentation currently recommends) your build is likely going to fail. Make the default host x86_64-pc-windows-msvc instead:

rustup-init.exe -y --default-host x86_64-pc-windows-msvc --default-toolchain stable

This has fixed all sorts of build problems for the extendr project.