Arm64 Pc

[Angelique Syria]

Isthis behaviour intended? Now anybody can read private values from the framework from this json file. I would expect that at least this will be opt-in feature of Xcode. After little bit of searching I have found that this can be turned off by OTHER_SWIFT_FLAGS = "-Xfrontend -empty-abi-descriptor"; in the Build Settings. Another thing is that there is very little documentation about this feature. I think this can be a big surprise for some SDK developers that suddenly XCode reveals their private values in the arm64-apple-ios.abi.json file.

I have also noticed that this file is created only if BUILD_LIBRARY_FOR_DISTRIBUTION is set to YES in Build Settings. I have tried building my XCFramework with Xcode 14.1, removing arm64-apple-ios.abi.json and then use it in my app in Xcode 14.3 and it worked fine. So I am not sure if this file is required to support Library evolution or not.

Hey @jakub-vallo , This abi.json file isn't required for supporting library evolution at all. The most common usage for this file is to serve as an input for ABI stability checking purposes using the swift-api-digester tool (swift/swift_api_digester_main.cpp at main apple/swift GitHub), where two JSON files are specified for comparison. You've made a great point that whether we should turn this output file into an opt-in output instead of always emitting it when BUILD_LIBRARY_FOR_DISTRIBUTION is specified though. Could you file an GitHub issue for this?

When trying to build and run this app in the simulator I get the following error message: "Build failed because SwiftyDropbox.swiftmodule is not built for arm64". I scrolled through stack overflow but all hints I found there didn't fix the issue. Has anyone an idea what's wrong?

To be honest, I'm not familiar with the mentioned package. I cannot imagine any package, targeting particular platform, to expect exclusion of the same platform though. ? (including arm64, but not only)

PS: Probably you are trying to do something like cross-compilation with pre-build package. Clarify to yourself what you're going to do and everything's gona be fine (I believe). In any way all packages have to be the same architecture for one executable binary though (not some mixture as seems to be in your case). If you plan mixed architecture project, split the different archs in different binaries, for example.

You have excluded an arm64 part (the Dropbox part) from your arm64 (Apple Silicon) project (why at all ?). At the end you got surprised that your build system "informs" you about that. Am I missing something? ?

I'm using th package NMSSH from github in this app too for SFTP-filetransfer to a server as alternative to storing data on Dropbox. The older NMSSH module is only working, if arm6 is excluded. This is the reason why I excluded it. Do I understand it correct that the result is the conflict out of these two packages? NMSSH only without arm6, SwiftyDropboy only with arm6?

I got an existing installation up and running in arm64 after a rebuild and some basic sanity check to make sure the frontend loads. However, a ./launcher logs web_only shows that rails.stderr.log is constantly being filled with these:

I am curious to know if there will be an arm64 version of Teams in the near furture. I would need it, as we (my company) deployed 80 Raspberry Pi 4's for home office use, due to the somewhat special situation at the moment. We are running Ubuntu Server 19.10 at the moment and it would be great to have teams usable.

2. Edit: I musst have missed the fact that there is support of Teams on Google Chrome since v72, but we as a company would definetly prefer a desktop client for ARM. (By the way armhf would be great too.)

I was finding a solution for students who don't have laptops & buying a smartphone might be more costly thing...so they can use Raspberry PI and connect it with TV (assuming commonly available) using HDMI cable. USB keyboard and mouse will cost less then 8$ in India.

So overall the PI will solve online classes issue and will work as nice portable machine to do python and other programming language practice also which are introduced in course for grade 8th and above.

@stratusand everyone else, I am new to this whole Raspberry Pi and ARM64 jargon but I think this is along the lines of what you are looking for. It was released last friday (October 16th, 2020). If it is, could you confirm. I am looking to build some remote devices for work but need Teams to run on a Raspberry Pi to get approval.

@azcloudOnce if I have installed teams for linux, it wasn't because I have arm architecture on my Raspberry pi 4. In terminal, it was saying that we don't support arm64 version but supports armhf and amd64 versions. This is only my problem I was installing ubuntu 20.04 amd64 on raspberry but not working. I also tried ubuntu core 20 but only blank screen.

It's a lot simpler and safer to recreate a container of Joplin as a docker container. Compared to a normal installation of Joplin.

Since it is easier to make backups of files from a container. Then having to rollback an entire system in case something goes wrong.

I and my friend would really appreciate if this would be make.

Since we run our low cost and low power consumption servers as a pi 4 arm64 installation.

And the only thing we are missing is getting Joplin on our servers as well.

I also know there is a large pi community on arm64 and they would probably appreciate it as well.

My current project throws IBDesignable errors when using Interface builder on an apple Silicon based machine..i tried excluding arm64 architecture for debugging, as well as some other hints i found on the internet, but no success at all..

Frustratingly, even though I don't have any dependencies on the framework with my IBDesignable views in, I was getting some errors related to dependencies of my app - which I fixed by this answer: which disabled "ONLY_ACTIVE_ARCH" for my cocoapod dependences.

I had this problem on Xcode 14.0 with my M1 Mac. My code had some IBDesignables for UIView to expose cornerRadius, borderWidth, and borderColor as a UIView extension. Xcode was throwing up the warnings described in this thread, and warning of instability to render the storyboard too.

My app's deployTarget was 15.0, but after reading the comment above about how deployTarget needs to be at least 13.0 to solve the problem, I discovered that it was my cocoapods that could have a lower deployTarget!

So by adding the below to by Podfile to force all my Cocoapods to have at least iOS 13 deploy target, all those storyboard warnings about IBDesignables and general instability to render and archtecture mismatch went away! (I'm showing also ONLY_ACTIVE_ARCH force to NO but I already had this one in place - so though that wasn't the fix, per se, I think you'll want it too).

I was able to make this work end to end with STM32CubeProgrammer and IAR on Windows 11 ARM64 (running in Parallels on an Apple M1). To make that work, I have removed all references to the certificate signatures (CAT files) from INF files.

To install, you need to temporarily disable driver checks: -to-fix-the-third-party-inf-doesnt-contain-digital-signature-information/ (use the temporary solution 3 - Reset while holding Shift). After rebooting with driver signature checks, go to Device Manager, find the STLink device and manually specify the folder where you've unzipped the file attached below.

I made the modifications and because the inf changed Windows fails to install the driver (tampering). Because the driver is signed and the signature changed, I don't know of a simple way to disable the check. This means there is no viable workaround for now for all Windows ARM64 users.

The changes I've made cannot work (for security reasons as the driver package is signed). The changes are following driver documentation from Microsoft here: -us/windows-hardware/drivers/install/inf-controlflags-section

I have attached only the INF files from the STLink driver. These have been changed from NTamd64 to NTarm64. The correct fix is to add another arm64 section (i.e. wherever amd64 is used, add something similar for arm64).

Hi

I have been using the TL Linux app during several years for work on the NSC Triolith and later Tetralith systems. AFAIK NSC never implemented the Web Access part of TL.

Any chance you will release a TL client for ARM64, not HF or consider a release for Android?

Hi Peter, as far as I know there is nothing currently on the roadmap, but perhaps one of the dev team can clarify (@samuel)? Web Access was intended to provide ThinLinc access from platforms without a native client available, like Android/iOS. So the path of least resistance may be asking NSC to activate the web access component.

In fact, IMHO it would be a great move - and probably best - if cendio could consider to open-source the client and move development of it to, e.g. GitHub so that interested third-party developers (like me) could contribute / develop own client versions and also potentially merge these changes back via pull requests.

3a8082e126