Problems sharing my programs?

Code?
What Frameworks did you use?
Did you give them instructions on how to run it from, say, the command line?
How did you bundle it, zip?
When they 'installed' it did the permissions and execute bit work out ok?

EDIT: Also, when you say 'Unix Executable File' I assume you mean a Mac Mach-O binary.

 

If your program only links to <stdio.h> where is the harm in just posting the code?

All I could do is guess, that either A: you have a bug in your code. B: something went wrong in the compilation step. C: you compiled with 10.6+ and your friend is on <=10.5.

Otherwise zip up your program and post it here. *note that if he does this you probably shouldn't run the program, instead use gdb to step through or decompile the application.

 

I would say it is one of three things:

1. Permissions Error
2. They are on a different version of OS X than you (Snow Leopard instead of Lion for example)
3. Bug in your source code

 

You're not going to get much help if you're not going to post your code.

If you're using Mountain Lion (I can't imagine why you would be) then that's the problem.

 

chmod the file to 700 and chown it to his user account

If you need more information on File Permissions in OS X, check out this document: http://support.apple.com/kb/HT2963

Try using the '-arch i386' argument when building your program if he still can't run it

 

Then compile the plain ordinary Hello World C program. Give that to your friend. Post that code. Also post the complete error messages (copy and paste from Terminal window).

When something fails, you should know how to make a simple isolated test case that can show the problem, so someone else can try to duplicate the problem. This is a basic debugging skill. If the isolated test case doesn't show the problem, then you've learned something.

 

Step #1. Read all the advice, e.g. I brought up permissions in my first post.
Step #2. Use Xcode. There will be more build options, more target options, the ability to compile multiple targets at once (for multiple OS's) etc. Yes all (most??) of these are available as command line or makefile stuff, but you don't really know all of them do you??


That said, since we don't know WHAT your program does it is hard to tell what the issues are. e.g permissions could be that your code is trying to write to /etc/hosts OR it could be writing to /Users/SuperAdmin/Desktop and is not able to because A: there is no user, and B: the program doesn't have privileges to make the folder.

EDIT:
Step #3. Learn from this so that in the future you can say, "oh you can't run my command line application by clicking it, here is a laundry list of things to check."

 

Compiles and runs just fine.

 

Can you compile it again and attach it to your reply as a zip file?

 

Are you saying that your friend is using 10.7 and still cannot run the program?
I would suggest zipping it (right click-> compress) and sending it to your friend that way. Some transmission methods are not necessarily binary safe with any file format, using something like a dmg or zip file is the answer to that.

Make sure your friend puts it on their desktop or something so they for sure have privileges in the unpacked folder.

Now for some unsolicited style advice.
#1. Things like int main() vs int main(int argc, char **argv) and return(0) vs return 0
They may seem archaic and magical but it is a good idea to use them and learn them anyway. (btw, the number and type of arguments is important for linking properly I'm not saying that is your problem just be aware of it. and return is not a function, it is a keyword you wrote return(0), you could have wrote return (((0))) for all the compiler cares. Like foo = 5+(6). Sometimes you see ( ) around a longer expression after return. Almost always with a space after, and ultimately whatever the expression evaluates to is what is returned.)

#2. Whenever you find yourself getting up to variableName# where # is above 2 or 3, you might want to think about are they really necessary. In this case, the variables monday-saturday could just be replaced by a counter like 'totalHours' that you add to at each step of the program.

#3. Some of the repeat typing could be simplified with functions, which I'm going to assume you haven't really gotten around to.

Here is a slight rewrite just to see some of these in work. (also note the [ code ] block)

Code:

#include <stdio.h>

#define kTAXRATE 0.2f

float howManyHours(const char *);
int workedSunday(void);

int main (int argc, const char * argv[]) {
    float rateOfPay, pay, tax;
    float hours = 0;

    printf("\n*** My Wages Calculator ***\n");

    printf("What is your hourly pay rate before tax?\n");
    scanf("%f", &rateOfPay);
    
    hours += howManyHours("Monday");
    hours += howManyHours("Tuesday");
    hours += howManyHours("Wednesday");
    hours += howManyHours("Thursday");
    hours += howManyHours("Friday");
    hours += howManyHours("Saturday");
    
    if(workedSunday()) {
        hours += howManyHours("Sunday");
    }
    
    pay = hours * rateOfPay;
    tax = pay * kTAXRATE;
    
    printf("\nThis week you worked:\n%.2f hours!\n\n", hours);
    printf("You earned £%.2f before tax\n", pay);
    printf("After tax deduction you earned £%.2f\n\n", pay - tax);
    
    return 0;
}

float howManyHours(const char *s) {
    float x;
    printf("How many hours did you work on %s?\n", s);
    scanf("%f", &x);
    return x;
}

int workedSunday() {
    char ch;
    while (1) {
        fpurge(stdin);
        printf("Do you work on a Sunday? (Y/N)?\n");
        ch = getchar();
        if (ch == 'Y' || ch == 'y') {
            return 1;
        } else if (ch == 'N' || ch == 'n') {
            return 0;
        }
    }
}

*note the workedSunday() function doesn't bail if they enter a non Y/N answer. In practice you might want to write a counter into it to let the user out if they keep messing up.

 

Nice rewrite, but I have to throw in that using fpurge() is not recommended because it is not a standard part of the C library, and probably won't work on other systems.

 

I didn't really know what it did, but since it was part of the original I decided to err on the side of caution and keep it rather than simply throwing it away or learning more about it.