Leopard => Snow Leopard architecture woes with nokogiri / rails - ruby-on-rails

I'm confused. It's a regular state of affairs for me but specifically in this case I felt I could reach out to fellow stackoverflowers (that is, stackoverflow-ers, not stackover-flowers).
uname -a
Darwin macbookpro 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386
set
bash-3.2$ set
...
HOSTTYPE=x86_64
...
MACHTYPE=x86_64-apple-darwin10.0
...
I'm having a nightmare rebuilding some native ruby gems and I'm wondering whether this is part of the problem -- part of this machine says its 64 bit but another part 32 ... as far as I can tell?
Under 'About this Mac' it says 'Intel Core 2 Duo' which Apple says is 64 bit. So why, after doing
sudo gem pristine --all
am I still getting this kind of error?
dlopen(/Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle, 9): no suitable image found. Did find:
/Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle: mach-o, but wrong architecture - /Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle
Specifically I had removed nokogiri and reinstalled it. No errors in output.
bash-3.2$ sudo gem install nokogiri
Building native extensions. This could take a while...
Successfully installed nokogiri-1.4.2
1 gem installed
thanks for any thoughts!
UPDATE
I've found a useful post by Chris Noos on a similar problem. This is where I am:
cd /usr/local/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/
then made a file called wem_extconf.rb:
require 'mkmf'
find_library('xml2', 'xmlParseDoc')
dir_config('any-string-here', '/opt/local/include', '/opt/local/lib')
find_library('xml2', 'xmlParseDoc')
Running sudo web_extconf.rb produces
checking for xmlParseDoc() in -lxml2... no
checking for xmlParseDoc() in -lxml2... no
???? But hang on, it is there:
$ port installed | grep libxml2.*active
libxml2 #2.7.7_0+universal (active)
$ ls -l /opt/local/lib | grep libxml2
-rwxr-xr-x 2 root admin 2623276 31 May 20:09 libxml2.2.dylib
-rw-r--r-- 2 root admin 3643928 31 May 20:09 libxml2.a
lrwxr-xr-x 1 root admin 15 31 May 20:09 libxml2.dylib -> libxml2.2.dylib
-rwxr-xr-x 2 root admin 975 31 May 20:09 libxml2.la
And it does appear I have several copies of the thing -- but not sure which one port installed is using (I'm assuming given it's macports, it's /opt?)
$ ls -l /usr/lib | grep libxml2
lrwxr-xr-x 1 root wheel 15 23 May 16:07 libxml2.2.7.3.dylib -> libxml2.2.dylib
-rwxr-xr-x 1 root wheel 3758272 22 Sep 2009 libxml2.2.dylib
lrwxr-xr-x 1 root wheel 15 23 May 16:07 libxml2.dylib -> libxml2.2.dylib
$ ls -l /usr/local/lib | grep libxml2
-rwxr-xr-x 1 root admin 1456292 30 Oct 2009 libxml2.2.dylib
-rw-r--r-- 1 root admin 4812456 30 Oct 2009 libxml2.a
-rwxr-xr-x 1 root admin 1456292 30 Oct 2009 libxml2.dylib
-rwxr-xr-x 1 root admin 951 30 Oct 2009 libxml2.la

On Snow Leopard, gcc has a misleading behavior; even if you are running a i386 kernel, gcc will produce 64 bits binaries by default.
Have you looked at the GEM documentation to see how to specify the targeted architecture ?

Have you installed the XCode Development tools?

Related

brew: Not linking to the latest python (symlinks in /usr/local/opt)

Even after running brew link --overwrite python#3.10, the symlink /usr/local/opt/python#3 does not point to version 3.10. Worse, it removed the /usr/local/opt/python symlink (that was also pointed to 3.9)
l /usr/local/opt/ | grep python
lrwxr-xr-x 29 vivekragunathan admin 2 Jun 12:07  python#3 -> ../Cellar/python#3.9/3.9.13_1/
lrwxr-xr-x 29 vivekragunathan admin 18 May 14:39  python#3.8 -> ../Cellar/python#3.8/3.8.13_1/
lrwxr-xr-x 29 vivekragunathan admin 2 Jun 12:07  python#3.9 -> ../Cellar/python#3.9/3.9.13_1/
lrwxr-xr-x 28 vivekragunathan admin 8 Jul 12:17  python#3.10 -> ../Cellar/python#3.10/3.10.5/
What do I have to do so that I have symlinks python and python#3 under /usr/local/opt point to the latest version (3.10 now)?
The reason why you saw python#3 was pointing to python#3.9 is because python#3 is an alias to python#3.9. There is a WIP PR for migrating the alias to point to python#3.10`.

Xcode 13 quick help window not launch on custom objects

Ever since I downloaded Xcode 13 I have been unable to see the quick help window (option click) for objects/functions/variables I have created.
I can see the quick help window for other swift frameworks (option clicking tableView works, for example). Just not for my own.
I have tried
running this in command line:
$ defaults delete com.apple.dt.Xcode WebKitJavaScriptEnabled
deleting this:
~/Library/Caches/com.apple.dt.Xcode
running this:
$ defaults delete com.apple.dt.Xcode IDEIndexDisable
This is what I see when I run:
$ cd ~/Library/Developer/Xcode/DocumentationCache/
$ ls -al
total 0
drwxr-xr-x 4 myname staff 128 Sep 21 13:13 .
drwxr-xr-x 13 myname staff 416 Sep 24 20:38 ..
drwxr-xr-x 3 myname staff 96 Apr 28 10:49 v187
drwxr-xr-x 3 myname staff 96 Sep 21 13:13 v202
Anyone know of any fixes?
A restart of the machine solved the issue for me. Xcode then installed components and built the quick help for Apple's documentation and the documentation in my own code.

brew cask install meld: 'cannot import GTK+': what's wrong with my library?

I tried to install meld on my iMac running OS/X 10.13.1 High Sierra.
brew cask install meld
and homebrew completed without error, but when I tried to run it I saw
$ meld check1ping.sh check2pings.sh
frozen: ImportError
Cannot import: GTK+
dlopen(/Applications/Meld.app/Contents/Resources/lib/python2.7/gi/_gi.so, 2): Symbol not found: _inflateValidate
Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
Expected in: /Applications/Meld.app/Contents/Frameworks/libz.1.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
I note the questions How do I fix melds 'Cannot import: GTK+' error caused by missing 'gi.repository'? and Meld error "Cannot import: GTK+; No module named repository" but this problem seems to be different.
I found this page which suggests that /Applications/Meld.app/Contents/Frameworks/libz.1.dylib is out of date. This is what I saw in /Applications/Meld.app/Contents/Frameworks:
-rwxr-xr-x 1 myusername staff 127692 4 May 2016 libz.1.2.8.dylib
lrwxr-xr-x 1 myusername staff 16 16 Nov 15:24 libz.1.dylib -> libz.1.2.8.dylib
Looking for a replacement, I found:
lrwxr-xr-x 1 root wheel 12 11 Nov 09:57 /usr/lib/libz.1.1.3.dylib -> libz.1.dylib
lrwxr-xr-x 1 root wheel 12 11 Nov 09:57 /usr/lib/libz.1.2.11.dylib -> libz.1.dylib
lrwxr-xr-x 1 root wheel 12 11 Nov 09:57 /usr/lib/libz.1.2.5.dylib -> libz.1.dylib
lrwxr-xr-x 1 root wheel 12 11 Nov 09:57 /usr/lib/libz.1.2.8.dylib -> libz.1.dylib
-rwxr-xr-x 1 root wheel 186432 25 Oct 17:37 /usr/lib/libz.1.dylib
lrwxr-xr-x 1 root wheel 12 11 Nov 09:57 /usr/lib/libz.dylib -> libz.1.dylib
and when I replaced the libz.1.dylib in my meld app with this one, everything magically worked.
My question is: how do I fix homebrew so that it picks up the correct version of the library, so future users don't have this problem?
I see that brew cask cannot build from source and always installs from a binary, so I'm a bit surprised that it seems to have the wrong library version. I found the meld ruby file but am none the wiser. I know nothing about specifying brew or cask builds, I'm afraid.
Thanks!
Not sure if this qualifies as an answer, but here goes. First, thanks for identifying the cause of the problem, as it is one that affected me too after upgrading to MacOS High Sierra. I am not a homebrew expert, so this "answer" just formalises what you found...
unlink /Applications/Meld.app/Contents/Frameworks/libz.1.dylib
ln -s /usr/lib/libz.1.dylib /Applications/Meld.app/Contents/Frameworks/libz.1.dylib
The first line removes the symbolic link to the Meld's local libz.1.dylib (127692 bytes, dated 4 May 2016) which seemed to be at version 1.2.8. The next line recreates that symbolic link, but pointing to the global (GTK+) libz.1.dylib (186432 bytes, dated 25 October 2017), possibly version 1.2.11.
Hopefully the homebrew Meld cask maintainer will introduce a proper fix, but in the meantime, running those two commands in a terminal fixes this particular Meld problem so that Meld can run under MacOS High Sierra.
This is now fixed upstream. All you need to do is to update the Meld cask.
Updating is a bit counterintuitive. To update the list of available casks you use brew update, not brew cask update, but to upgrade casks to the new version you use brew cask upgrade, not just brew upgrade.
So the correct sequence to update all installed casks is:
brew update
brew cask upgrade

iOS is it a static or a dynamic framework?

This might sound like a silly question but If you have a thirdParty.framework file, can you tell if it's static or dynamic? I mean, do they look different if you look inside?
It can be either.
Only iOS8+ will allow dynamic frameworks in the app bundle, however.
The way to find out is to look in the .framework and use the file command on the main file:
$ cd iOS/Crashlytics.framework
$ ls -l
total 9984
-rwxr-xr-x 1 andy staff 4710656 11 Sep 17:11 Crashlytics
drwxr-xr-x 8 andy staff 272 11 Sep 17:11 Headers
-rw-r--r-- 1 andy staff 1553 11 Sep 17:11 Info.plist
drwxr-xr-x 3 andy staff 102 11 Sep 17:11 Modules
-rwxr-xr-x 1 andy staff 146164 11 Sep 17:11 run
-rwxr-xr-x 1 andy staff 241688 11 Sep 17:11 submit
$ file Crashlytics
Crashlytics: Mach-O universal binary with 5 architectures
Crashlytics (for architecture armv7): current ar archive random library
Crashlytics (for architecture armv7s): current ar archive random library
Crashlytics (for architecture i386): current ar archive random library
Crashlytics (for architecture x86_64): current ar archive random library
Crashlytics (for architecture arm64): current ar archive random library
Where ar archive means "static library".
Alternatively, a "dynamic" framework will look like this and explicitly state that it's dynamically linked.
$ cd /Library/Frameworks/iTunesLibrary.framework/
$ ls -l
total 40
lrwxr-xr-x 1 root wheel 24 10 Sep 17:38 Headers -> Versions/Current/Headers
lrwxr-xr-x 1 root wheel 24 10 Sep 17:38 Modules -> Versions/Current/Modules
lrwxr-xr-x 1 root wheel 26 10 Sep 17:38 Resources -> Versions/Current/Resources
drwxr-xr-x 4 root wheel 136 10 Sep 17:41 Versions
lrwxr-xr-x 1 root wheel 22 10 Sep 17:38 XPCServices -> Versions/A/XPCServices
lrwxr-xr-x 1 root wheel 30 10 Sep 17:38 iTunesLibrary -> Versions/Current/iTunesLibrary
$ file Versions/Current/iTunesLibrary
Versions/Current/iTunesLibrary: Mach-O universal binary with 2 architectures
Versions/Current/iTunesLibrary (for architecture i386): Mach-O dynamically linked shared library i386
Versions/Current/iTunesLibrary (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
I use this command to list all STATIC Frameworks from a path with a list of frameworks:
find -E . -type f -iregex ".*\.framework\/[^./]*" -exec file {} \; | grep ': current ar archive' | sed 's/.*\/\(.*.framework\).*/\1/'

Once jailbroken, will iOS apps run with root privilege?

Once an iOS device is jailbroken, we can build jailbreak apps (with theos) and it gets installed in the /Applications directory where the preloaded apps run with root privileges. If an app is built with Xcode, once it is installed, it gets into the /private/var/mobile/Applications/ folder, which is supposed to have Apple sandbox enforced (before jailbreak).
So, the questions I have are:
For a jailbroken device, will the apps in /private/var/mobile/Applications/ execute with root privileges or with mobile user privileges?
In case of Android, once rooted, the apps will have to gain root privileges by executing the su command. Is it the case when it comes to iOS as well?
I would like to understand the difference between these two development options (Theos / Xcode) and how it affects what operations my app can perform.
Not disagreeing with anything H2CO3 said, but to add some further clarification ...
Apps installed in /private/var/mobile/Applications/(†) with Xcode will run with user mobile privileges, even on jailbroken phones.
Even on a jailbroken phone, apps installed to /private/var/mobile/Applications/(†) will be sandboxed almost (‡) like apps on a jailed phone. So, no reading other (normal) apps' data, even if those files are owned by user mobile.
For a good description of the process that apps like Cydia use to run as root, see this answer. Or, just ssh into your phone, and take a look inside /Applications/Cydia.app/ yourself.
If you simply copy/install an app (without doing what H2CO3 suggested) to /Applications/, it won't be sandboxed, but it will still run with mobile (UID=501) privileges:
iPhone5:~ root# cd /Applications
iPhone5:/Applications root# ls -altr ./HelloJB.app/
total 220
-rw-r--r-- 1 root wheel 711 Apr 3 20:36 entitlements.xml
-rw-r--r-- 1 root wheel 297 Apr 3 20:36 entitlements-daemon.xml
-rw-r--r-- 1 root wheel 7972 Apr 3 20:36 embedded.mobileprovision
-rw-r--r-- 1 root wheel 58755 Apr 3 20:36 date.zip
-rw-r--r-- 1 root wheel 485 Apr 3 20:36 ResourceRules.plist
-rw-r--r-- 1 root wheel 8 Apr 3 20:36 PkgInfo
-rw-r--r-- 1 root wheel 1226 Apr 3 20:36 Info.plist
-rw-r--r-- 1 root wheel 10960 Apr 3 20:36 Icon\#2x.png
-rw-r--r-- 1 root wheel 8328 Apr 3 20:36 Icon.png
-rw-r--r-- 1 root wheel 451 Apr 3 20:36 HelloJB.plist
-rwxr-xr-x 1 root wheel 61088 Apr 3 20:36 HelloJB*
-rwxr-xr-x 1 root wheel 42688 Apr 3 20:36 HelloDaemon*
drwxr-xr-x 2 root wheel 136 Apr 3 20:36 en.lproj/
drwxr-xr-x 2 root wheel 102 Apr 3 20:36 _CodeSignature/
drwxr-xr-x 4 root wheel 544 Apr 3 20:36 ./
drwxrwxr-x 54 root admin 1904 Apr 5 02:14 ../
iPhone5:/Applications root# ps -Aef | grep HelloJB
501 9412 1 0 0:00.00 ?? 0:00.33 /Applications/HelloJB.app/HelloJB
iPhone5:/Applications root# grep mobile /etc/passwd
mobile:*:501:501:Mobile User:/var/mobile:/bin/sh
(‡) Here's a good discussion, with input from Saurik, about how different jailbreaks may affect the sandbox. Long story short: it depends.
(†) Update: in recent versions of iOS, the location of 3rd-party apps has been moved to /var/mobile/Containers, and later to /var/containers/, but the same basic sandbox issues remain.
Long story short: no.
Jailbreaking is a necessary but not sufficient condition for gaining root. Apps will still be sandboxed by default.
What you can do for making your app run with root privileges is creating a startup shell script that has root:wheel ownership and 755 permissions, then create your actual executable with the same ownership, 7555 as permissions (i. e. set its "setuid" bit), then call setuid(0); from within main(), before calling UIApplicationMain().

Resources