iOS simulator arm64 build

[zoltan-gaspar-mobilengine]

I can use the lib on m1 mac's iOS simulator due to linker error: ld: in /.../libpdfium.a(fpdf_view.o), building for iOS Simulator, but linking in object file built for iOS, for architecture arm64

[paulocoutinhox]

Hi,

You can or you can't?

You need compile for arm64 simulator?

Thanks.

[bthomale]

I ran into the same issue. I believe he's saying he needs to be able to build for the arm simulator, which is needed for developing on an M1 mac. I have the same need. You can't just use the arm device build on the simulator, because they aren't the same.

I've actually added support for this to your scripts, if you wouldn't mind me submitting a pull request. (I'm planning on doing this today.)

So, because you can build for arm64 for device, and arm64 for simulator, you can't just lipo the simulator and device builds together anymore into one universal binary. Instead, what Apple recommends is that you lipo all of the simulator architectures (x86-64 and arm64) together into one library, the device architectures (arm and arm64) into a second library, and then you can combine these two into what's called an xcframework.

I've modified the scripts to produce the following 4 binaries (for my purposes, where I'm ultimately building an xcframework):

libpdfium_arm-device.a libpdfium_arm64-device.a libpdfium_arm64-simulator.a libpdfium_x64-simulator.a

And then it lipos the two device builds together, and the two simulator builds together, to produce the following two universal libs:

libpdfium-device.a libpdfium-simulator.a

These can be combined into an xcframework by doing the following command, which I could add to my pull request if it is helpful (this is just an example):

xcodebuild -create-xcframework -library ./lib/libpdfium-simulator.a -headers ./include -library ./lib/libpdfium-device.a -headers ./include -output "pdfium.xcframework"

Right now I'm just doing the xcframework step in my own build script, which calls your script and then works with the output.

[bthomale]

Actually, it looks like I can't submit pull requests to this project because I can't push a branch.

Anyhow, I've got the changes required to do this on my local machine. If they are helpful to you, I'd be glad to send you the updated files - I just had to modify ios.py and config.py to get this working.

[paulocoutinhox]

Hi, nice. This is a great thing. The better way is really create a xcframework, because it will solve these kind of problems. You can upload the python files here if you want. Thanks.

[bthomale]

Sounds good. See the attached .zip. I modified 2 files - ios.py and config.py.

They both go in modules.

If you look at the diffs from what's in master, it should be pretty straightforward how it works. I tried to match your coding style the best I could, but feel free to tweak it however you want.

ArmSimulator-XCFramework.zip

[bthomale]

Actually- I just realized I kind of messed up the xcframework build step.

Those libraries should really have the same name. The way they are now, the -device and -simulator ends up inside the xcframework. The framework still technically works but the naming just isn't quite following the usual convention.

When I ported things from my build script to yours I changed things slightly. I was sort of expecting Xcode to rename those lib files but it didn't. I'm going to give you an updated set of scripts here, tomorrow; it's the end of the day for me.

[bthomale]

Ok now it matches what it was doing when the xcframework step was in my script. One very small change - it keeps the name "libpdfium.a" the same in both paths and uses the paths within the xcframework to distinguish the files.

ArmSimulator-XCFramework-2.zip

[paulocoutinhox]

Hi,

Im removing armv7. Anyone still use it?

Thanks.

[bthomale]

I don't use it. In fact, I tweaked my local config to remove it as well.

[paulocoutinhox]

Hi,

All problems was fixed in new release.

You can check here: https://github.com/paulocoutinhox/pdfium-lib/releases/tag/5407

The demo is here: https://pdfviewer.github.io/

Feel free to donate to help project development.

Thanks.

[bthomale]

It works! Thanks!

[paulocoutinhox]

Hi @bthomale

It work for you in device?

[bthomale]

Actually, let me test that.

It works on the arm64 simulator, at least.

[bthomale]

Hmmmmm. It failed on my iPhone Xs. Here's the part of the stack trace where it goes into pdfium. This is in FPDF_InitLibrary();

#0 0x00000001117e8748 in partition_alloc::internal::logging::RawLog(int, char const*) () #1 0x00000001117e85cc in partition_alloc::internal::logging::LogMessage::~LogMessage() () #2 0x00000001117e8764 in partition_alloc::internal::logging::LogMessage::~LogMessage() () #3 0x00000001117e80a4 in partition_alloc::internal::logging::CheckError::~CheckError() () #4 0x00000001117e7d08 in partition_alloc::internal::(anonymous namespace)::HandlePoolAllocFailure() () #5 0x00000001117e7bf8 in partition_alloc::internal::PartitionAddressSpace::Init() () #6 0x00000001117eaf60 in partition_alloc::PartitionRoot::Init(partition_alloc::PartitionOptions) () #7 0x00000001117e7d48 in partition_alloc::internal::PartitionAllocator::init(partition_alloc::PartitionOptions) () #8 0x0000000111733bb0 in FX_InitializeMemoryAllocators() () #9 0x00000001117b35e8 in FPDF_InitLibraryWithConfig ()

Here's the last thing it logged to the debug console:

[FATAL:partition_address_space.cc(99)] Check failed: false.

[paulocoutinhox]

Yes, i already fixed it. Im fixing modularize wasm to release all together.

[bthomale]

I saw the update. (I checked 7 seconds after it went live! 👍 ) It's working much better now. Thanks.