Error on make about the new commit

[Kous92]

Hello @nanoscopic, your latest update have a problem. After pulling, the make run have made this error below. How to fix that ?

checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin19.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common -DPIC
checking if g++ PIC flag -fno-common -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin19.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libusbmuxd-2.0 >= 2.0.2... no
configure: error: Package requirements (libusbmuxd-2.0 >= 2.0.2) were not met:

No package 'libusbmuxd-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables libusbmuxd_CFLAGS
and libusbmuxd_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** [repos/libimobiledevice/Makefile] Error 1

[nanoscopic]

This is corrected by the updated to init.sh. You should re-run init.sh. It is generally also probably a good idea to run init.sh after any pull of the repo to ensure any new dependency changes are pulled in.

The cause for the new dependencies is that libimobiledevice HEAD version is no longer buildable / installable on latest Catalina via brew. The build/install method for libimobiledevice therefore has changed. libusbmuxd is installed through brew using --head. libplist is installed through brew using --head. libimobiledevice is now build and installed through the Makefile.

I will leave this ticket open though; it makes sense to add these checks to happen in the Makefile. The way makefile_preflight.pl is written can/should be changed to support the new dependencies. This will cause the package to move further away from being a brew package, but it is unavoidable at this time.

[Kous92]

@nanoscopic Unfortunately, with init.sh executed, the error persists. Should I have to remove manually the libusbmuxd library or other dependency and run init.sh again ?

[devlucy]

I had same issue but this worked for me #972

[Kous92]

So, the error is related to the dependency. Can you tell me when it’s fixed ?

[chriiis78]

I resolved it like this:

brew uninstall libimobiledevice ios-webkit-debug-proxy
brew uninstall libusbmuxd
./init.sh
make

[Kous92]

@nanoscopic How to use your new testVideo mode ? Also, it would be nice to put it on the readme.

[nanoscopic]

@Kous92 Yes; agreed I need to update the documentation. I also have some changes I need to commit that address some additional issues.

The general way to use the new testVideo mode:

1. Create a cache folder to cache h264 headers in mkdir stf_ios_support/cache
2. Run the devreset command bin/devreset 3776 1452 ( see main readme )
3. Run the testVideo mode bin/coordinator -testVideo
4. Wait until it says "First Video Frame Received" ( I'm forgetting the exact wording... )
5. ctrl-c stop the coordinator
6. A udid based file with exist then in the created cache folder, and will be used for the h264 headers when starting up the coordinator normally. Having these headers cached makes it much more reliable to start up coordinator and have it work.

I am still seeing situations where the media services ( the stuff on the IOS device streaming out the video ) get screwed up after running for a while ( 24+ hrs ). Devreset and the built in libusb reset don't address this messed up state. The only ways I've seen so far to ensure media services are fully reset is either rebooting the IOS device or using "Settings -> Developer -> Reset Media Services" on the IOS device. I am still investigating some other way to fully reset it that can happen automatically within the coordinator every so often ( every X hours )

The latest changes that I will commit this weekend address the following:

1. Iphone 11 does not work due to null character in the UDID due to a glitch in Google gousb code.
2. The "wda wrapper" has stability issues and hits max cpu usage for no clear reason when being used frequently by automated tests through Appium. I've gotten rid of it again and made WDA be started directly by coordinator again. It was causing more problems than it was helping.
3. The whole libusb / libplist dependency mess. This is generally due to libimobiledevice being altered currently right now but I made a workaround that at least makes this work through the scripts without having to do something manually.

Additionally the documentation needs to be updated to explain that libimobiledevice must be built and installed manually right now if everything is deployed through dist.tgz, as it is installed right now by the make process. Step 1: update documentation to explain this. Step 2: make an install process as part of dist.tgz that does so.

[Kous92]

Note: Docker/server part have to be updated also. The official OpenSTF have been updated to version 3.4.2. And I have took a look to your code, you have forgotten to add the iPhone SE 2nd generation on the device list.

[nanoscopic]

Standard server can be used... I'd generally recommend using the server information / docker-compose here: https://github.com/tmobile/stf_ios_support/tree/master/server

This now points at a prebuilt docker image that contains all the latest updates ( including latest server from DeviceFarmer upstream )

Soon the updates will be upstreamed via PR into DeviceFarmer/stf as well.

All device ids I am aware of are here: https://github.com/tmobile/osx_ios_device_trigger/blob/master/osx_ios_device_trigger/main.cpp#L16

If your device ID isn't one of those, please tell me what it is and I'll add it. Please also update the wiki here if you have one that is not documented yet: https://www.theiphonewiki.com/wiki/Normal_Mode

[nanoscopic]

Closing due to lack of updates and because I'm not sure what action this ticket is requesting at this point.

The code does need to go into upstream STF; but that is not the clear purpose of this ticket.

If there is still an issue probably best to open a new ticket describing what that issue is. I feel the issues described above have been resolved.