old btstack package on ios 9.1

[Michael Kramer]

Greetings,

I know I am using a very outdated btstack package, version 0.9-1, but it is giving an error on the bt_open() command when I run it on and iPhone 5s with iOS 9.1.  For reference I made sure the latest BTstack package was uninstalled in Cydia then used dpkg to install this older version (and when done Cydia does report that version 0.9-1 is installed).

I have a library that I have been compiling against libBTstack.dylib from the 0.9-1 package for years and so far it has not failed me on an iPhone 5 with ios 6.1.2 or an iphone6 with ios 8.4, but now the same lib that works on arm_v7 and arm64 devices is not working on the iphone 5s w/ ios 9.1.

Can anyone think of a reason why the same same lib with the same .deb package installed would have a problem unique to either an iPhone 5s or iOS 9.1?

I know I should get with the times and build against the latest libBTstack.dylib and use the latest deb package from Cydia but right now I'm just curious where things might be going wrong with my current setup. (plus I am getting an error when doing a make in btstack-master/port/ios but I'll leave that to another thread).

any suggestions or advice would be most welcome,

Mike

[Matthias Ringwald]

Hi Michael

Nice to hear you're still using BTstack on iOS. 

That's a weird error and I don't have a good idea why this happens. If bt_open fails, it means the socket could not get opened. The main cause for this would be if BTdaemon did not start up. Does BTdaemon start if you run it from a terminal directly?

In the last years, the main updates to the BTstack Cydia package were motivated by changes in iOS. I just remember that sandboxing prevented CFMessagePorts from working between apps or so. Adding rocketbootstrap helped with that. If you're really curious, please check the notes on newer releases and/or go through the commits in either v0.9 or master - I've moved the code from master to v0.9 before doing a re-architecture.

Building btstack for iOS 3-9 became more and more tricky over time. You need two Xcode installations and also the correct theos variant.

It builds on our buildserver:https:// buildbot.bluekitchen-gmbh.com/btstack/builders/port-ios-master - that has 10.11 installed

I just tried on 10.12 and failed, too. 

dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation

  Referenced from: /Applications/Xcode-4.4.1.app/Contents/Developer/usr/bin/xcodebuild

  Reason: no suitable image found.  Did find:

/Applications/Xcode-4.4.1.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Applications/Xcode-4.4.1.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported

Keeping a full VM just to build the armv6 lib would suck :(

Cheers

 Matthias

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.
Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.

[Michael Kramer]

Hi Matthias,

Thank you for the speedy reply.

I can start BTdaemon from the 0.9 and 1.1 packages fine w/o errors, so I am guessing from that that the BTStack socket in /tmp/ can be accessed (?). 

What is odd is that at first I tried to run my library w/ the libBTstack from the 1.1 package and still get the same error - bt_open() is returning -1

And for what it is worth things work w/ the BTstack GPS app - I am able to run that just fine and see my BT device and connect to it, although it is not a GPS device so once the connection is made nothing really happens after that. But since this is working I do not believe that it is anything fundamental with the iphone5s or ios 9.1.

Without having to rebuild the BTdaemon is there a way to get some more information about connection attempts from my library other than the /tmp/hci_dump.pklg file?  When I look into the file it reports the BTdaemon started and that L2CAP_EVENT_SERVICE_REGISTERD with status 0x0 but nothing else regarding my lib trying to connect.

Finally, although it is a complete hack, I was able to get BTdaemon and libBTstack.dylib to build by copying dylib1.o from an older Xcode and modify the Makefile to remove armv6 - after that though it complained that it could not find the crt1.o library so the linking of tool inquiry failed.  (for reference I am still building against the SDK for Xcode 8.1 and using the theos from the DHowet git repo.

Is there a precompiled version of rfcomm_test that I could try to run against either the 1.1 or 0.9 packages? Without being able to build from the 1.1 source I cannot get the rfcomm binaries to use these to test w/ BTdaemon.

For now I will keep trying things out and see what happens but if you have a suggestion as to what else I could try I open to whatever. 

Thanks and my regards and wishes for a good holiday season to you and your family.

cheers,

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev+unsubscribe@googlegroups.com.

To post to this group, send email to btsta...@googlegroups.com.
Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev+unsubscribe@googlegroups.com.

[Matthias Ringwald]

Hi Michael 

Independent from the actual problem, I'd recommend to use the latest package from Cydia - although you probably have a good reason not to.

Here's a zip of the examples folder build from the master branch (on my build server). The files contain armv6 and arm64 slices.

https://dl.dropboxusercontent.com/u/5138628/btstack-examples.zip

If you disable the armv6 slice, it should build without hacks - at least in theory.

matthias

To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.

[Michael Kramer]

Hi Matthias,

Thanks for the examples folder and I will give them a try when I can.

As for building my lib against the latest package I am open to the possibility of this - it would just mean me doing some massaging of my existing BTstack interface code to work w/ the latest headers which can be done but I'm just not sure if I would end up w/ the same errors - but I will look into it.

thanks,

Mike

[Matthias Ringwald]

quick update: if you select armv7 or arm64 and use deployment target 6.0, it should compile with a stock theos and the latest Xcode. I'll have a solution for armv7/3.0 soon too without using older Xcodes.

You can try theos from github/rpetrich or the new official one https://github.com/theos/theos.git

best

 matthias

To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.

[Michael Kramer]

Hi Matthias,

Thank you for the update.  I will give that a try.

I am still doing some digging but so far I have been able to build a simple command line test executable with theos that just calls run_loop_init() and then bt_open() and that can be run as user mobile just fine with a successfull call to bt_open() and I can see that it triggers BTdaemon into starting.

I also made a simple one button app from xcode that does the same but there the bt_open() returns an error.

So at this point I am working under the assumption that there is something going on with building an app from xcode and running it on ios 9 that I am not expecting - as the same simple test apps work fine when tested on os 6 or 8, so far it is just xcode developed apps running on os9 (but still targeting 6.0) that are causing the headache.

Can you think of anything that would cause an xcode project vs. an app compiled with theos behave differently?

thanks,

Mike

[Michael Kramer]

Hi Matthias,

when updating theos to the official one I cam across the deviceconsole app from rpetrych and the additional logging information has shed some light onto the problem.

When I run a simple app on iOS 9 that makes the call to bt_open() I get the following line in the log that does not show up on ios 8 or 6:

   [0;37mDec 19 05:26:57 MobiLab-V [0;36m kernel[0] [2;32m < [0;32mNotice [2;32m> [0;37m: [m Sandbox: TestSswLite(1010) deny(1) network-outbound /private/var/tmp/BTstack

So even though the device is jailbroken it appears that there is still some sandboxing going on that is blocking things.  Does this make sense to you?  Any thoughts on a work around?

thanks,

Mike

[Matthias Ringwald]

Hi Michael

You're on the right path. I was about to respond to your previous mail that the problem most likely is that you cannot access /tmp/BTstack from a sandboxed app.

Work arounds: the most obvious one is not to use Xcode to build for JB. theos can build apps just fine, too. And these won't be sandboxed.

Then, BTdaemon also supports incoming connection via TCP instead of a Unix Domain Socket. I think that's is disabled for the Cydia builds but it could be enabled without too much effort if compiled by yourself.(Check in daemon.c and btstack.c)

Best

 Miatthias

To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.

[Michael Kramer]

Hi Matthias,

Ahh - now things are working.  I managed to play stupid and just copy my app from where xcode installed it to /Appplications/ and then run uicache and now everything is working as hoped, the app runs fine and can access btstack to do all that I need.

For me it is not a problem to use theos for builds however I want to buid/use Kivy which has a lot of background scripts run to bundle the app and this would be a bit of a paint to transfer over to a theos based build.  But between being able to access logs from rpetrych and having the ability to update the GUI part of the app by just copying over python files it will completely break my dependency on Xcode (at least for this project).

Many thanks!

Mike