Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #60857 > unrolled thread

Xcode issues, doesn't compile files

Back to article view | Back to comp.lang.c

Contents

  Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-23 02:53 -0700
    Re: Xcode issues, doesn't compile files Bartc <bc@freeuk.com> - 2015-04-23 11:51 +0100
      Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-23 04:39 -0700
        Re: Xcode issues, doesn't compile files Bartc <bc@freeuk.com> - 2015-04-23 13:19 +0100
          Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-23 07:20 -0700
            Re: Xcode issues, doesn't compile files Bartc <bc@freeuk.com> - 2015-04-23 15:33 +0100
              Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-23 08:50 -0700
    Re: Xcode issues, doesn't compile files Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-04-23 20:31 +0200
      Re: Xcode issues, doesn't compile files Robert Wessel <robertwessel2@yahoo.com> - 2015-04-23 14:25 -0500
      Re: x86_64 Noob <root@127.0.0.1> - 2015-04-23 21:39 +0200
    Re: Xcode issues, doesn't compile files G G <gdotone@gmail.com> - 2015-04-23 12:50 -0700
      Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-24 10:37 -0700
        Re: Xcode issues, doesn't compile files G G <gdotone@gmail.com> - 2015-04-24 11:15 -0700
    Re: Xcode issues, doesn't compile files Keith Thompson <kst-u@mib.org> - 2015-04-23 13:02 -0700
    Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-24 06:22 -0700
      Re: Xcode issues, doesn't compile files G G <gdotone@gmail.com> - 2015-04-24 10:13 -0700
        Re: Xcode issues, doesn't compile files Alla _ <modelling.data@gmail.com> - 2015-04-24 10:34 -0700
    Re: Xcode issues, doesn't compile files Hiidenkivi <hiidenkivi@nospam.no> - 2015-04-25 14:41 +0300
      Re: Xcode issues, doesn't compile files Hiidenkivi <hiidenkivi@nospam.no> - 2015-04-25 15:05 +0300
      Re: Xcode issues, doesn't compile files Keith Thompson <kst-u@mib.org> - 2015-04-25 13:25 -0700
        Re: Xcode issues, doesn't compile files Hiidenkivi <hiidenkivi@nospam.no> - 2015-05-03 23:29 +0300
          Re: Xcode issues, doesn't compile files Keith Thompson <kst-u@mib.org> - 2015-05-03 13:46 -0700
            Re: Xcode issues, doesn't compile files Hiidenkivi <hiidenkivi@nospam.no> - 2015-05-04 03:06 +0300
              Re: Xcode issues, doesn't compile files Keith Thompson <kst-u@mib.org> - 2015-05-03 18:06 -0700

Page 2 of 2 — ← Prev page 1 [2]

#61459

Keith Thompson kirjoitti:

>
> I can nearly guarantee that it won't.  On my system, both programs
> produce the same output.  On the OP's system, the original program
> doesn't produce any output at all, because it doesn't build.

However I can clearly see that the OP's source code has an issue which 
will cause build to fail in any normal C compiler conforming to ANSI C 
rules. OP's code is not correct C89 which XCode expects it to be in its 
default configuration.

At least the "result" has to be moved up to be with the other variable 
declarations like the x, y1, etc. or it will definitely not compile in a 
standard C89 compiler. And based on my experiences with the XCode, there 
are likely to be warnings about the type conversions which could lead to 
some weird compile errors.

Of course OP's code will work fine in a C++ compiler. Those are entirely 
different things since you can declare anything almost anywhere in C++ 
and it will compile. And C99 (which also allows declarations to be made 
everywhere) is still not the default for many environments.

By the way, I addressed the 2.55f in a message I sent almost immediately 
after because it was a brainfart of mine.


-- 
Hiidenkivi

[toc] | [prev] | [next] | [standalone]

#61464

Hiidenkivi <hiidenkivi@nospam.no> writes:
> Keith Thompson kirjoitti:
>> I can nearly guarantee that it won't.  On my system, both programs
>> produce the same output.  On the OP's system, the original program
>> doesn't produce any output at all, because it doesn't build.
>
> However I can clearly see that the OP's source code has an issue which
> will cause build to fail in any normal C compiler conforming to ANSI C
> rules. OP's code is not correct C89 which XCode expects it to be in
> its default configuration.

Fair enough, I likely didn't notice that.  (Incidentally, I advise
avoiding the phrase "ANSI C".  It commonly refers to the 1989 ANSI C
standard, but that standard is obsolete according to ANSI itself,
superseded by the 1990, 1999, and 2011 ISO C standards.  What you mean
is ANSI C89 or, equivalently, ISO C90.)

But that's not the problem the OP was asking about, and I reiterate that
your modified program almost certainly would not help the OP.  The
compiler didn't complain about the presence of a declaration followed by
a statement within a block; it complained that "_main" was an undefined
symbol, indicating that the C implementation has been installed and/or
configured incorrectly.

Compilers (and, in this case, linkers) print error messages for a
reason.  You can't just ignore them.  Once that prolem is corrected, we
can deal with any errors caused by the fact that the code doesn't
conform to a C standard published a quarter of a century ago, either by
modifying the code or, IMHO better, by learning how to configure Xcode
to compile modern C.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61472

Keith Thompson kirjoitti:
> compiler didn't complain about the presence of a declaration followed by
> a statement within a block; it complained that "_main" was an undefined
> symbol, indicating that the C implementation has been installed and/or
> configured incorrectly.
>

But we know that OP doesn't have an issue with compiling "void main 
(void){}". OP did state earlier that he has other programs which do 
compile properly:

 > 2) I have created a bunch of other programs,
 > but with only #include <stdio.h> header;
 > those did not cause me any problem.

I think that we can safely put the theory that there's something wrong 
with the development environment on-hold. I don't know about you. But 
XCode is a *horrible* development environment in my opinion. It does the 
job but its messages are at times unhelpful or outright misleading. In 
those situations it is ok to partially ignore the XCode's output.

And there are plenty of ways it can produce that compile error other 
than the problems in the code. For example if OP has a wrong project 
type (e.g. he uses something other than C or C++, e.g. Foundation type). 
We cannot go through them all without additional and constant flow of 
information from the OP:

https://discussions.apple.com/thread/7009089

The thing is that with beginners, and with the XCode, and in small 
tutorial programs like these you start looking at the project settings 
and the code first when weird errors like this one happen. The simplest 
explanation is usually the correct one.

Theory of the C development environment being broken is unlikely at the 
moment, in my opinion. It's more likely that there is a problem in the 
code or in the project settings. And I'm betting on the code.


-- 
Hiidenkivi

[toc] | [prev] | [next] | [standalone]

#61473

Hiidenkivi <hiidenkivi@nospam.no> writes:
> Keith Thompson kirjoitti:
>> compiler didn't complain about the presence of a declaration followed by
>> a statement within a block; it complained that "_main" was an undefined
>> symbol, indicating that the C implementation has been installed and/or
>> configured incorrectly.
>>
>
> But we know that OP doesn't have an issue with compiling "void main
> (void){}". OP did state earlier that he has other programs which do
> compile properly:
>
>> 2) I have created a bunch of other programs,
>> but with only #include <stdio.h> header;
>> those did not cause me any problem.

I hope you're aware that "void main(void){}" is at best non-portable.
The correct definition of an empty program is "int main(void){}".
I asked the OP to try that; I don't recall that he ever responded.

The quoted sentence is not enough to be sure that "int main(void){}"
actually worked for the OP.  There might not have been a main function,
and/or the OP might have used "gcc -c", which would not produce the
observed error.

> I think that we can safely put the theory that there's something wrong
> with the development environment on-hold. I don't know about you. But
> XCode is a *horrible* development environment in my opinion. It does
> the job but its messages are at times unhelpful or outright
> misleading. In those situations it is ok to partially ignore the
> XCode's output.

Here's the error message from the original message:

    Here is what I get after trying to compile:
    
    alla [11:41 AM]
    95-28-37-123:~ Alla$ gcc Prog3task6add.c -o Prog3task6add
    Undefined symbols for architecture x86_64:
     "_main", referenced from:
         start in crt1.10.6.o
    ld: symbol(s) not found for architecture x86_64
    collect2: ld returned 1 exit status

The OP wasn't even using Xcode.  He was invoking the "gcc" command from
a shell prompt.  The gcc command (whether it invokes the actual gcc C
compiler or the similar clang C compiler) would not produce that error
message for the OP's source file if gcc were installed and configured
correctly.  The compiler may have been installed via Xcode (I don't know
the details, and I haven't used Xcode much at all).

The default mode for gcc (assuming it invokes the GNU C compiler) is
equivalent to "-std=gnu90", which is C90 with GNU-specific extensions.
(gcc version 5 changes that to "-std=gnu11", but I'm sure the OP isn't
using such a recent version).  In that mode, gcc *does not complain*
about mixed declarations and statements (unless you add the "-pedantic"
option, which the OP did not).  If it instead invokes the clang compiler
(which is likely for Mac OSX), the behavior is similar.

Furthermore, the error is from the linker, not from the compiler, which
implies that the compiler successfully finished with no error or warning
messages.

> And there are plenty of ways it can produce that compile error other
> than the problems in the code. For example if OP has a wrong project
> type (e.g. he uses something other than C or C++, e.g. Foundation
> type). We cannot go through them all without additional and constant
> flow of information from the OP:
>
> https://discussions.apple.com/thread/7009089

The gcc command has no "project settings".  It might be affected by
environment variables, but for the most part such settings are
controlled by command-line options, which the OP did not use.

> The thing is that with beginners, and with the XCode, and in small
> tutorial programs like these you start looking at the project settings
> and the code first when weird errors like this one happen. The
> simplest explanation is usually the correct one.
>
> Theory of the C development environment being broken is unlikely at
> the moment, in my opinion. It's more likely that there is a problem in
> the code or in the project settings. And I'm betting on the code.

I'm betting that you're wrong.  There is no problem in the code that
would explain that message.

The simplest explanation is often the correct one, but only if it
actually explains the observed problem.

Something about the OP's gcc installation is missing or misconfigured.
Modifying the source program, as you suggested, would not help.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web