[Help] Project Not Building in Xcode

[Vizon, Lowell]

Hi there!

I installed preview build DP3R77 and created a new Xcode project; it
won't build, failing with the following:

`/Developer/Platforms/Froth.platform/Developer/SDKs/FrothPlatform0.5.sdk/usr/lib/gcc/i386-ubuntu-linux/4.3.1/../../../../i386-ubuntu-linux/bin/ld:
crti.o: No such file: No such file or directory
collect2: ld returned 1 exit status
Command /Developer/Platforms/Froth.platform/Developer/Tools/xbuildtools
failed with exit code 1`

I installed only the most recent build; there were no prior Cocotron
or Froth SDK previews on this Mac OS X install.

Any ideas?

Build log and screen shot are attached.

Thanks!

[Ignacio Cases]

Hi Lowell,

The log states that ld can not find the library crti.o. You can find the same question here 

http://stackoverflow.com/questions/91576/crti-o-file-missing

In my own distribution the library is located under

/Developer/Platforms/Froth.platform/Developer/SDKs/FrothPlatform0.5.sdk/usr/i386-ubuntu-linux/lib/crti.o

Please verify that crti.o is there and follow the steps in the stackoverflow answer.

Hope it helps.

Cheers,

-Ignacio

[Vizon, Lowell]

Ignacio, thanks for the quick reply!

The SO link you provided had the OP eventually reinstall his toolchain
to resolve the problem, after first running through the suggested
steps. I figured that''d be a good place to start.

From my hard drive, I deleted the following:

/Users/lowell/Development/FrothSDK
/Developer/Platforms/Froth.platform
/var/receipts/com.thinkingcode.*.bom
/var/receipts/com.thinkingcode.*.plist

Closed all bash sessions and quit Xcode.

Opened FrothSDKSnowLeopard_DP3.pkg. Proceeded through the steps,
selecting a standard installation type.

Launched Xcode and created a new project of type Froth Platform >
Application > Web App.

Built the project; same issue as previously - ld still can''t find
crti.o. Square one; let''s begin.

Your crti.o lives at
/Developer/Platforms/Froth.platform/Developer/SDKs/FrothPlatform0.5.sdk/usr/i386-ubuntu-linux/lib.

A quick check verifies that mine does as well:

http://pastie.org/1077494

The SO link says that ld inherits its paths from gcc. Let''s see what
those paths are, using the gcc switch used in the post.

http://pastie.org/1077454

Next, let''s verify that those paths even exist.

http://pastie.org/1077490

It turns out that none of the search paths that gcc binary uses exist. :(

Is this where the problem is?

[Ignacio Cases]

Well, I would say that the fact that Froth's gcc version points to those non-existing directories is making the build to fail, and that you should be able to compile properly using Apple's gcc. Select you project icon in the Groups & Files pane, and do cmd-i to get the info. In the Build tab search for compiler and switch it to System default. Try to build the project.

As far as I know, the Cocotron uses a gcc patched version inside the CDT package. Maybe Allan would clarify if Apple gcc is not appropriate to build Froth-based applications.

Cheers,

-Ignacio

[Allan]

I'm not sure that this is the problem. Check the paths again using the
gcc located here... (As this is the one that froth uses.)

/Developer/Platforms/Froth.platform/Developer/SDKs/
FrothPlatform0.5.sdk/usr/bin/i386-ubuntu-linux-gcc -print-search-dirs

Do these path's exist in your install? crti.o should be in the last
library search path listing.

Regards,
-Allan

[Vizon, Lowell]

Hi again, Ignacio.

Wouldn't Apple's gcc be unable to build a Linux target?

The compiler set at the project level is already the system default;
it's overridden at the Linux target's level to
com.thinkingcode.froth.dp2.gcc.4.3.1. Changing it there introduces new
errors as it looks for gcc-4.2 in the Froth.platform folder.

Thanks for the help and apologies for bothering everyone.
Lowell

[Vizon, Lowell]

Hi there, Allan; thanks for the reply.

This (http://pastie.org/1078742) is what happens when I run
-print-search-dirs on that particular gcc, with line breaks added for
readability: all but one of the returned paths exist; the second to
last library path is the one that does not.

crti.o is in the last search path, as you predicted.

I noticed that one of the Linux target's LIBRARY_SEARCH_PATHS is set
to "$(DEVELOPER_DIR)/FrothSDK/Library/lib)", which doesn't exist, so I
added (/Developer/Platforms/Froth.platform/Developer/SDKs/FrothPlatform0.5.sdk/usr/i386-ubuntu-linux/lib)
to see if anything would happen. Nothing does.

There were a couple of other observations that probably don't have
anything to do with the problem, but I'll list them just in case:

1. The project's Frameworks and Libraries group references
/Developer/FrothSDK/Library/lib/libfroth.a, which is a nonexistent
path. libfroth.a doesn't seem to exist anywhere at all on the
filesystem.

2. The Linux target's GCC_VERSION is set to
com.thinkingcode.froth.dp2.gcc.4.3.1; should this be set to
com.thinkingcode.froth.dp3.gcc.4.3.1?

Thanks for the help and apologies for bothering you all.

Lowell

[Vizon, Lowell]

All:

I found the problem.

I have two user accounts on my MacBook Pro.

One is mine; I just copy my user folder from Mac to Mac as the years go by.

The other is named `default`. It's the automatic login account, and
it's designed as a sort of honeypot in the event my laptop is ever
stolen. On the surface, it has Safari, Firefox, Chrome and Opera for
the thieves convenience. Beneath it, it's got a running keylogger,
periodic iSight capture, remote access, auto upload & email, the works
- for mine.

Since there has to be an existing account in order for me to copy over
my user folder, I set up that auto login account first whenever I buy
new computer. This gives the auto login account a UID of 501, and me a
UID of 502.

The installer is installing Froth.platform with the auto login
account, `default`, as its owner - even though I'm authenticating with
/my/ user name and password. In other words, the installer seems to be
giving ownership of Froth to UID 501, regardless of which user
actually authenticates during the installation.

I verified this by installing Froth in a Mac OS X Server VMware image
where I have the 501 UID. Xcode was able to build and link a Froth
project without any problems; when I deleted Froth on that image,
created a second account and installed it again under that second
account, I was able to reproduce my problem in Xcode /exactly/, as it
again installed Froth as the 501 account instead of the account under
which I'd authenticated.

The build fails because the linker can't see the library and object
files needed (like crti.o) since they're owned by another user who has
them under rather strict permissions (0600 or -rw-------).

I've never run into this before on anything installed by
Installer.app. The files installed as part of the developer tools in
/Developer/usr are all owned by root - but with more flexible
permissions - 0644. It may prevent others from experiencing my same
problem down the road if Froth follows this permissions model. I'll
research the Installer.app ownership assignment issue independently,
as time allows, and I'll either report back or open an rdar://
depending on my findings.

For now, I've resolved the problem by doing `chown -R lowell
/Developer/Platforms/Froth.platform/`. Files therein have varying
permissions, and I don't know how to change only the ones that are
0600 to 0644, so this works just fine in my one (active) user
environment.

If anyone reading this is stuck in a similar predicament, please try
`dsmemberutil getid -U YOUR_SHORT_USER_NAME`. If it gives you anything
/other/ than `uid: 501`, I'd recommend trying the fix described in the
previous paragraph.

Hope you all have a great weekend!

Lowell

[Ignacio Cases]

Glad you found the problem!

Cheers,

Ignacio

Enviado desde mi iPad

[Allan]

Great!

I will look into fixing the installer permissions for the next
release.

Regards,
Allan

Sent from my iPad