Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / CodeWarrior / October 2005



Tip: Looking for answers? Try searching our database.

std library link errors

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Kurt Bigler - 28 Oct 2005 03:25 GMT
CW 9.6
XCode 2.2 (Seed)
MacOSX 10.4.2

I just created a Mach-O C++ target in a project.  Settings for the target
are identical with the settings for a Mach-O target in another project that
links succesfully.  The Mach-O target in both projects contain these
identical-looking referenes to:

   MSL_C++_BSD_C_Mach-O.lib
   BSD_Runtime_Mach-O.lib

and no other "standard" libraries are included in the Mach-O targets.  Yet
in the one project I get lots of C standard library undefined externals
(sprintf, strlen, memcpy, etc.) and in the other there is no such problem.
Both projects make ample use of sprintf and strlen.  I would have thought
that BSD_Runtime_Mach-O.lib would satisfy these externals.  Clearly the two
libraries listed above are included in the Mach-O target and show up with
the same Code and Data size in both projects.

Any thoughts?

Thanks in advance.

-Kurt Bigler
Kurt Bigler - 28 Oct 2005 06:45 GMT
> CW 9.6
> XCode 2.2 (Seed)
[quoted text clipped - 17 lines]
>
> Any thoughts?

I found out empirically that the C library symbols in question were
satisfied by adding the System framework.  This was a bit of a surprise to
me.  Info about this framework on the apple developer website varies from
advice to add the framework when preparing a CW project for import into
XCode, to the unexplained advice "Do not use" on this page:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Ov
erview/SystemFrameworks/chapter_9_section_1.html

However there is a helpful off-hand code comment in CallMachOFramework.c
which explains 'In this example I'm using "System.framework", which is the
framework that holds all the standard BSD functions'.

Nice to know!  Makes me confused about when to use gcc libraries or (in
CodeWarrior) MW libraries though!

Am I correct to assume the System framework is the preferred way to go,
rather than usiing libSystem, which as a post here a couple months ago by
Eric Albert informs me, is what the System framework actually symlinks to?

-Kurt
Eric Albert - 29 Oct 2005 04:05 GMT
> I found out empirically that the C library symbols in question were
> satisfied by adding the System framework.  This was a bit of a surprise to
[quoted text clipped - 4 lines]
> http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Ov
> erview/SystemFrameworks/chapter_9_section_1.html

There shouldn't be any point to adding the System framework because it
should be implicitly linked in for you.  Then again, maybe CodeWarrior
doesn't implicitly link it in.  Xcode and gcc certainly do.

> However there is a helpful off-hand code comment in CallMachOFramework.c
> which explains 'In this example I'm using "System.framework", which is the
[quoted text clipped - 6 lines]
> rather than usiing libSystem, which as a post here a couple months ago by
> Eric Albert informs me, is what the System framework actually symlinks to?

There's no difference between the two.  The "System framework" is just a
bit weird because it isn't a framework at all -- it's really just a
symlink.  I'm not sure why it exists.

-Eric

Signature

Eric Albert         ejalbert@cs.stanford.edu
http://outofcheese.org/

Alwyn - 31 Oct 2005 15:34 GMT
> The "System framework" is just a
> bit weird because it isn't a framework at all -- it's really just a
> symlink.  I'm not sure why it exists.

Maybe Apple put it there for the convenience of CodeWarrior users?

Alwyn
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.