Posts Tagged ‘Xcode’

libiconv from OS X and Mac Port, and change of Xcode behavior

I have an old project for converting wrongly encoded Korean to properly encode to properly encoded one in mp3 files.

However due to file system corruption while in upgrading to OS X 10.11.6,  I had to rebuild the project again. I found out that I had another project for the same purpose to use different ID3 library. I didn’t remember which project was correct one.

I finally identified the correct one, but had some issues. It was built previously without a problem, but it failed this time. It could be due to changes in Xcode. Yes. there is such change. I will talk about that after taking about difference of libiconv from OS X and Mac Port.

When tried to build, it complaint _iconv, _iconv_open, _iconv_close were missing.
I recalled that there was difference between libiconv from OS X and Mac Port, and there was a comment I wrote for that, but didn’t remember its detailed reasoning for that.

stackoverflow.com/questions/27392085/cant-link-to-iconv-on-os-x

So, I googled and found the stack overflow question above, and it made me recall what problem it had completely.

So,  this time I would like to record it here.

This is the result with libiconv from Mac Port.

JongAms-Mac-mini:lib jongampark$ nm -m  libiconv.2.dylib | grep iconv

0000000000002db1 (__TEXT,__text) external _libiconv
0000000000002dd3 (__TEXT,__text) external _libiconv_close
000000000000158c (__TEXT,__text) external _libiconv_open

This is the result with libiconv from OS X.

JongAms-Mac-mini:lib jongampark$ nm -m /usr/lib/libiconv.dylib | grep iconv

000000000000301c (__TEXT,__text) external _iconv
000000000000336d (__TEXT,__text) external _iconv_canonicalize
000000000000303e (__TEXT,__text) external _iconv_close
0000000000001c41 (__TEXT,__text) external _iconv_open

So, the difference is that the ones from Mac Port have _lib is prefixed while the ones from OS X don’t.

Also, the included iconv.h file should match with the library file.


Finally I would like to talk about the changes of Xcode behavior.

With a version of 7.x.x, Apple changed that default libraries and header files could be searched without specifying them. Especially, if a library, for example, /usr/lib/libiconv.dylib is linked using the build phase, Xcode didn’t require the /usr/lib is added to the library search path. It was new behavior at that time.

However, they changed it again from some version of Xcode later than the version mentioned above. So, the library path should be set to include /usr/lib.
Without that, even though the /usr/lib/libiconv.dylib is linked by build phase setting (Link Binary with libraries ), Xcode couldn’t find that it’s in /usr/lib.

Apple doesn’t document this kind of changes, and it gives headache.
I wonder why Apple keeps changing from one behavior to the other behavior from time to time. If they keep changing to a newer behavior, it could be understandable, although I don’t like it. However, they are kind of going forward and backward.

This is small difference, but can affect big way.
Apple should document this kind thing and handle this seriously.

Xcode 6.1이 가져온 큰 변화 (Integration of iOS & Mac OS X for programmers )

놀랍게도 내가 보기엔 Swift가 아니다.

Xcode 6.1이 가져온 큰 변화는 드디어 Mac에서도 iOS의 View Controller를 쓸 수 있다는 것.
이렇게 함으로써 주가 되는 뷰들을 각각의 xib에 넣고 관리하게끔 유도한다. (물론 그 xib들을 storyboard로 관계 맺어주는 것이지. 사실 storyboard의 등장은 xib를 없앤게 아니다. 스토리보드 파일을 열어보면 그 답이 나온다.)
당연히 덩치가 큰 프로그램은 메모리 사용량 관리에서 더 좋아질테고. 이렇게 함으로써 사실상 Mac과 iOS의 가장 큰 차이점이 없어지게 되었다. 물론 프레임워크의 차이야 조금은 있지만, 그건 마치 다른 버젼의 프레임웍 같은 느낌이고.. 사용 패턴등에 대해선 차이가 없다.

자. 이제 맥에서도 NSView가 NSWindow의 상위에 놓일지는 의문이다. 그렇게 되면 프로그래밍적으로 iOS와 OS X의 통합이 될거다.
NS*대신 UI*를 사용할텐데, 어느 쪽으로 통합될까? 혹 UI*는 아닐까? NS는 NextStep의 흔적이니까.

그래도 난 NS가 좋다. 왠지 UI*는 뭐랄까.. 히피같은 느낌?

그리고 iOS에선 Core Foundation 혹은 그 레벨에 준하는 것들을 Foundation보다 더 많이 사용하는데 (UIColor vs. CGColor) 앞으로 iOS 이전의 프레임워크처럼 CF*에 해당하는 해당하는 것에 대응하는 UI*를 빨리 빨리 만들어 주었으면 하는 바램이다.

Xcode 6.x에선 기본으로 Frameworks 혹은 Libraries 서브 그룹이 생기지 않습니다.

새 Xcode나 Obj-C 컴파일러가 나오거나 하면, 은근스레 바뀌는 것이 있다.

Outlet을 retain/assign 혹은 strong/weak 어떤 것으로 하느냐 (iOS/Mac)은 Mac에서만해도 벌써 여러번 바뀌었다. 근데 문서화가 안되다보니 사람들이 잘 모르고 지나가는 것 같다. 특히나 미국애들과 말하려면 이런 것 때문에 힘들다. 지네가 모르는 것을 남이 모른다고 생각하니…

오늘은 Xcode 6.0.x에서 바뀐 거..
이전 부터 슬금 슬금 Frameworks나 Libraries 그룹의 이름이 바뀌던가 간혹 없던가 싶더니, 요번엔 아예 없어졌다.
물론 타겟의 Build Phases에서 넣으면 좌측의 Project Navigator에 링크된 라이브러리가 뜨긴 하지만, 그들만의 그룹에 들어가진 않는다. 왜 일까?

하긴 Xcode는 Project Builder 때부터 사람들을 헷갈리게 많이 했다.
프로젝트 세팅과 타겟 세팅이 똑같이 생긴 것도 헷갈려했고 (지금 일하는 회사에서도, 더럽게들 아는 척은 하는데 이 둘을 구별을 잘 안하고 쓴다. 지금은 충분히 구별가능하고 프로젝트 세팅을 애용하면 아주 편한데), Build Phases의 Link Binary with Libraries에 넣느냐, 아니면 Build Settings의 Link 섹션의 해당 엔트리에 넣으냐…
전자는 좀 착 눈에 띄어서 좋고, 후자는 Unix 스럽게 쓸 수 있다. 물론 전자로 해도, 실제 링크시에 사용되는 환경 변수는 후자에 한 것과 같게 되지만…
때론 후자가 편할 수도 있다. 왜냐하면 후자를 쓰면 Debug build냐 Release 빌드냐에 따라 다른 것을 링크할 수가 있다. 즉 Debug build엔 Debug 용으로 빌드된 라이브러리들을 링크하고, Release 빌드엔 역시 그런 라이브러리를 링크할 수 있다.
이건 문서화 안된 거지만 그동안은, 다른 프로젝트가 만든 라이브러리 Product를 시각적으로 Drag & Drop을 하면, Debug/Release 빌드 신경 안쓰고 지가 연결해 주곤 했지만, 다른 툴 체인을 이용했던가, 라이브러리들은 유닉스틱하게 makefile이나 configure, 혹은 CMake등을 이용해서 빌드해주고 링크할 때, 후자가 유용하긴 하다.

암튼..
Frameworks 그룹이 사라진게 아쉽다. 왜 이렇게 했을까? 그거 참 좋았는데.

물론 하나 문제를 알고 있는게 있다.
Xcode는 사실 무엇을 프로젝트에 넣는지 그다지 제한적이지 않다.
그래서 Frameworks에 어떤 Framework를 만드는 프로젝트 자체를 넣을 수도 있다. 안되는 건 아니다. 하지만 생각해 보자. 그게 뭔 짓인가? 그럼 깔끔해야할, 탁 봐서, 아 이 프로젝트는 어떤 라이브러리들을 쓰는구나 대번에 알 수 있어야 할 그 부분이 굉장히 복잡해지고 지저분해진다.

Xcode는 예전에 Workspace라고 부르지 않고 Project file이라고 불렀을 때부터, 프로젝트가 프로젝트를 포함할 수 있었다. 그리고 만약 한 프로젝트 파일 내에서 여러 프로젝트 파일을 포함할 때, 그 각각의 프로덕트 즉 build 되어서 나온 것을 다른 서브 프로젝트가 의존하는, 즉 사용하는 라이브러리로 넣을 수있었다. (물론 지금도 가능하다) 즉 그렇게 함으로써 한 프로젝트 내의 app sub project는 library sub project에 의존성을 갖게 된다. 그래서 app을 빌드하면 혹 그 라이브러리가 빌드되어 있지 않으면 먼저 그 라이브러리를 빌드하고 그 후에 그 앱을 빌드한다. 물론 지금도 이렇게 사용 가능하고, Target Dependency가 그 관계를 명확하게 해 줄 때 사용될 수 있다.

근데 문제는 그 Frameworks 서브 그룹 내에 한 프로젝트 전체를 때려 넣는 것 사람들이 있다.
일전에 일하던 회사에서 러시아쪽 사람들이, 내가 분명 스크린 샷까지 넣어서 보여 줬는데도 그짓을 했고, 오히려 나더러 뭐라고 그런다. 되는데 뭐가 잘못이냐는.
되고 말고가 문제가 아니라, 얼마나 관리성이 좋느냐의 문제인거다.

한국애들도 요샌 그렇지만 서양애들은 자기 방어는 필사적으로 한다. 근데 가만보면 회사내에서 그런 놈들이 자기가 남에게 뭘 알려줘야 할땐 굉장히 비싸게 군다.
한국 사람들은 버릇이 없거나, 아니면 완전 수능 세대들부터 그런거 같은데, 서양애들은 교육과정이 좀 그딴 식인지 러시아건 미국이건 영국이건 상관없이 그런다. (인도도 여기에 포함된다.)
아 짜증나.

암튼. Xcode 6에선 그렇다.
(Xcode 5에서부터 슬금 슬금 없어지기 시작했다는거)

libiconv from MacPort and OS X framework

Somehow libiconv has given me lots of headache since I knew its existence.

Today, I ran into a problem with it. (again!)
Although I linked libiconv from OS X framework and included its header files, it complaint in building.

It somehow said there is no _iconv, _iconv_open and _iconv_close defined.
I wonder why and started to think that it may somehow confused with the libconv from MacPort.
Since I’ve used Unix, which is late 80’s, I had questions on libiconv and others. There are libraries of which official page say that the latest version is 1.4.2, for example. But strangely on my Linux machine or Sun machine I used, there are lib<the_library>.2.x.x.a or lib<the_library>.2.so.
Where the 2.x version comes from?

It’s also same with libiconv. The official page says its latest version is 1.14, but somehow Mac OS X has libiconv.2.dylib.
Header files are a little different. But they are anyway the same, iconv, iconv_open and iconv_close.
Then it should be able to find it.

However, this is what’s there.

symbols in libiconv from MacPort
JongAms-MacBookPro:opt jongp$ nm -a local/lib/libiconv.2.dylib | grep iconv
00000000000f90c0 D __libiconv_version
0000000000003000 T _iconv_canonicalize
0000000000002760 T _libiconv
0000000000002790 T _libiconv_close
0000000000001350 T _libiconv_open
00000000000027a0 T _libiconv_open_into
0000000000017980 t _libiconv_relocate
00000000000fa7a8 b _libiconv_relocate.initialized.b
00000000000178c0 T _libiconv_set_relocation_prefix
0000000000002cc0 T _libiconvctl
0000000000002dd0 T _libiconvlist
symbols in libiconv from OS X framework
JongAms-MacBookPro:opt jongp$ nm -a /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libiconv.2.dylib  | grep iconv
00000000000f26c0 S ___iconv_2VersionNumber
00000000000f2690 S ___iconv_2VersionString
00000000000f60f0 D __libiconv_version
0000000000002f1f T _iconv
000000000000325d T _iconv_canonicalize
0000000000002f41 T _iconv_close
0000000000001c59 T _iconv_open
0000000000002f4e T _iconvctl
0000000000003064 T _iconvlist
00000000000158e2 T _libiconv_relocate
000000000001582d T _libiconv_set_relocation_prefix

It’s very odd.
Anyway, although the /opt/local/lib, the library path of MacPort is included in the library search path in my Xcode project, but what is actually linked by adding explicitly using Link Binary with Libraries phase of Xcode target project was the one from OS X framework.
Then Xcode should try to link with the version instead of the one from Mac Port.

However, in the messages, it just linked with this option : -liconv.2.
But it couldn’t . Somehow the libiconv from Mac Port still preventd the linkage. (again, MacPort version is not 2, but 1.x )
So, I had to remove /opt/local/lib. Then it linked without a problem.

It’s odd that why there are two different versions on Internet. But even though it is if the library is set to be linked using Xcode “Link Binary with Library”, shouldn’t Xcode or its linker abide by that specific one more strictly? It should try to link the libraries set to be linked such way first.

많은 Xcode의 문제 중 하나

그 말도 많고 탈도 많은 Xcode 4를 넘어서 이제 Xcode 5까지 왔다.

물론 그동안 개선이 된 것도 많지만, 오히려 더 나빠진 것들도 많다.
맥용 32bit 환경에서의 Obj-C의 동작은 iOS의 32비트 환경을 따라가지 않는다.
Xcode 5에서 기본을 64비트로 잡는 것으로 보아, iOS 32비트의 modern runtime 동작은 영원히 맥용으론 들어가지 않을 것으로 보인다.

이 포스트에선 그런 것들은 차치하고, 아주 기본적인 문제를 한 그림에서 나타내보자.
간단하지만 화면을 효율적지 않고, 즐겁게 사용하지 못하도록 만드는 요소들이다.
Xcode problems

Xcode 3에서 디자인이 몇번 확확 바뀌었었는데, 그 때는 상당히 좋았다. 아이콘들도 예쁠 뿐 아니라, 기능적이었다. 이를테면 프로젝트의 종류별로 아이콘이 있는데, 멋질 뿐 아니라, 아이콘만 봐도 무슨 종류의 프로젝트를 만드는지 쉽게 알 수있었다.
화면도 세련되었었다. 그런데  Xcode 4로 넘어오면서 완전 망조로 넘어갔다.

Xcode 4에는 기능적인 문제도 많은데, 이를테면 한 소스 파일을 두개의 pane에서 볼 때, Pane A에선 10번째 줄을, Pane B에선 500번째 줄을 보고 있다고 하면, A에서 10번째 줄에서 스페이스를 5개를 주면,  Pane B에선 5개의 줄이 변경된다. 논리적으로 말이 안된다. A에서 줄을 바꾸지 않고 스페이스를 넣었을 뿐이다. 그렇다면 밑의 줄을 보여주는 Pane B에선 스크롤이 생기면 안된다.
그리고 또 하나의 문제는 스크롤의 방향이다. 왜 윗줄을 보여주는 Pane A에서 글자를 추가하는데, Pane B에서 줄이 아래로 내려가는게 아니라 오히려 올라가는가? 또한 Pane B에서도 마찬가지다. 아래의 줄을 보고 있기 때문에, 거기서 글자를 추가하던 지우던 Pane B는 스크롤이 되면 안된다. 하지만 된다. Xcode 4에선.

코드 사이닝이나, 여러가지로 Xcode 4에 기능이 많이 들어가긴 했다. 즉 좋아진 면도 있다. 하지만 영 망가지는 것도 무척 많다.
Project Builder때부터 써 온 사람으로써, 아마 제일 괜찮았던 때는 Xcode 3였던 것으로 보인다. 이곳 저곳에서 세팅할 수있는 프로젝트/타켓 관련 세팅도 많이 정리가 되었고, 프로젝트 세팅과 타겟 세팅이 명확하게 용도가 있었다. 지금은 하도 사람들이 이해를 못하니까 (어려워서 못하는게 아니라 안하려고 하니까) 이젠 거의 타겟으로 세팅을 몰아가는 추세인거 같다. 예전처럼 여전히 프로젝트와 타겟 세팅이 동일한 부분도 있지만 다른 부분도 많다.

이런 저런 소문을 듣자하니 Xcode의 팀장이 무척이나 괴팍한 사람이라고 한다.
누가 IDE 디자인을 했는지 안다. 참.. 대책없는 사람이다. 하긴 애플 내에서도 Xcode 4가 나왔을때 성토들을 많이 했다는데, 그 팀장인지 책임자는 무슨 철밥통을 가졌는지 쫒겨 나지도 않는다. 참.. 뭘까? 그 사람의 백그라운드는…

Suggestion of interesting idea for Xcode IDE?

It became almost 25 years after the birth of the HyperCard and its HyperTalk language. Although it may be seen as hobbyists dev. environment, it suggested very interesting ideas like :

  • RAD (Rapid Application Development) tool
  • OOP
  • Hyper Links

However, probably due to J. Sculley’s speaking of overlooking of HyperCard as a missing of a chance to be a king of HTML era due to its hyper links, people seem to remember its Hyper Text/Links as a kind of the most important characteristics.

However, to me it was the future of OOP or the core of the OOP language.
If you know why OOP languages were born, and the concept of components are strongly tied with OOP, it could see its distinctive feature among OOP languages. That is, each object like window, buttons and etc contains its own code in itself. If you double-click a button in editing mode, it opens an editor window on which you write button handler code. Visually it looked like that those buttons and other objects contain code.
So, those buttons, windows etc can be thought as self-contained objects. If you copy those, the code inside was also copied.

This is very unique interpretation of OOP and it actually serves the original goal of OOP more well than other approaches.

If you are a long time Simula/C++ S/W engineer, you would have heard that C++ didn’t do something meaningful in S/W development in terms of modularized “production” of S/W product just like H/W components like transistors, registers, memory chips etc did. You can say C++ did a lot. I know. It did a lot, but you don’t see the point why people have said that way.
The “encapsulation” in C++ and MVC pattern, which is widely used in Objective-C/Cocoa are taking different approach than that of HyperTalk.
They, i.e. C++/Objective-C are more focused on how to allow modification of code more independently by not interfering with other components you already wrote.

Well, one drawback of HyperTalk is that it is not easy to print out the whole source code, because you had to open each buttons, windows etc to see their code and print it.

So, wouldn’t it be interesting to provide a new model for the IB module of the Xcode in that Xcode creates source files for “control” code for objects where we are supposed to write “notification handlers”, some protocols like “will…”, “did…”, etc and any additional messages, and visually make it look like that the code is inside of such objects?

So, you can have the best of the both world : easier to get the whole source files to print and check, and visual “OOP”ness.

BTW, after the booming of iOS programming, in Apple’s tech document, I see more “methods” rather than “message”. Although most newcomers will say that there is no difference between those and between saying “call a method” and “send a message”, but there are huge difference. Calling them messages and “send a message” somehow makes our brain to think things more OOP way. When I studied Obj-C at first, I was surprised that I thought more OOP way than I did before. ( I was already very OOP-savvy because they way I think and due to the Korean language. When my colleague student had difficult time in understanding OOP languages, OOP in C++ was a kind of very natural to me. Oh.. they were also Koreans, but somehow they were so glued to procedural language, although I wrote procedural language longer time than them. So, you can’t say that I didn’t think OOP way in C++.

static library를 링크했는데, dynamic library가 링크되는 경우에 대해

바로 며칠전에 이 주제로 글을 올렸었다.

그런데 오늘 objcguy님이 왜 이런 현상이 나오며 어떻게 해결하면 되는지에 대한 Apple의 문서를 twitter를 통해 보여주셨다.
아… 바로 이거다. Google을 통해서 찾으면, 맨 Xcode에서 링커 세팅하기 수준의 것들만 나오는데…

Mac OS X에서 같은 폴더에 static library와 dynamic library가 있으면 dynamic library를 찾아서 링크한단다. 아무리 static library로 링크하기로 정해놨어도.

Technical Q&A QA1393
Using static versions of existing dynamic libraries

%d bloggers like this: