• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: leopard: No universal libjpeg.dylib in 10.4SDK?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: leopard: No universal libjpeg.dylib in 10.4SDK?


  • Subject: Re: leopard: No universal libjpeg.dylib in 10.4SDK?
  • From: Alastair Houghton <email@hidden>
  • Date: Mon, 21 Jan 2008 11:41:13 +0000

On 21 Jan 2008, at 07:33, Bill Bumgarner wrote:

On Jan 20, 2008, at 11:07 PM, Marc Lohse wrote:
thanks for your quick answer. i thought i'd have to do
that - i was just surprised that the universal 10.4SDK
supplied with the Xcode tools does contain non-fat libs.
would it be impudent to ask how much sense it makes to
call it _universal_ SDK then?

From my response:

(The library in question was not from Apple, btw. The alternative is
to use the various APIs on the system that deal with JPEGs.)

You have a flat version of the library installed in /usr/local/lib. It was not supplied with the SDK nor installed by Apple. The SDK contains a symlink from |SDKROOT|/usr/local/lib to /usr/local/lib. Generally, stuff installed in /usr/local/lib -- mostly from random open source libraries -- is not platform specific and, thus, the symlink makes sense. Kind of.

I'm pretty certain, actually, that the symlink is currently causing more problems than it's worth. We seem to be getting at least one of these questions a week (mostly on xcode-users), and it's made worse by the fact that one of the frameworks in the SDK pulls in libjpeg, libTIFF et al. from /usr/local/lib if they're there. As a result, you don't even have to link against one of these libraries explicitly to cause yourself a problem, which is why people are assuming that the problem is in the SDK itself. In fact, you can easily end up in a situation where it's impossible to build even the Cocoa Application template, simply as a result of this problem.


Moreover the errors generated by this problem are often quite hard to understand. IIRC I had error messages because of $UNIX2003 symbols that were being used by a library that happened to be in /usr/local/ lib and that was being pulled in by one of the system frameworks.

I contend that the symlink is fundamentally at odds with the idea behind the SDK system:

o System frameworks can end up pulling-in libraries from /usr/ local/lib rather than the expected versions

o /usr/local/lib contains libraries that may be built for the *current* system, not the SDK target

o /usr/local/lib often contains libraries that are single- architecture

o Different machines' /usr/local/lib folders may contain different libraries

For all of those reasons, I think the symlink should be removed.

I just filed a bug report, <rdar://5697302>, to that effect.

Kind regards,

Alastair.

p.s. Apologies for cross-posting to xcode-users, but I think it's useful in this case.

--
http://alastairs-place.net


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Prev by Date: NSImage in NSTableView, how I change column data type?
  • Next by Date: Re: NSImage in NSTableView, how I change column data type?
  • Previous by thread: Re: NSImage in NSTableView, how I change column data type?
  • Next by thread: Dead-code stripping in Xc3
  • Index(es):
    • Date
    • Thread