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

Groups > comp.lang.c > #126171

Re: understanding C issues in geany install

Show all headers | View raw

fred flintstone <fred@server.invalid> writes:

> Hello NewsGroup,
>
> I can't wrap my head around the C issues that crop up in installing
> geany. When I'm forced back to C, I feel like I've been stripped of my
> rank and sent to Siberia or even relapsed, but those are just
> feelings, and probably an ego manifestation. Quite simply, I've
> forgotten most of what I knew about C, as I would have been most
> engaged with it whilst on MS architecture. I have high hopes for
> geany, including porting it to windholes, so I can use the gf's laptop
> to script.
>
> I found that the build environment played a huge role in getting code
> to work, and that I wouldn't be able to replicate the frequent posts
> on *nix architecture. The simple fact is, if you are posting C output,
> then it must have run on *some* implementation, so a detractor or an
> OS bigot can claim that it is "implementation-specific" and therefore
> OT. Eschewing MS, one has to be his own IT guy....
>
> Enough with the prologue.
>
> Q1) Does contemporary standard C have any defined relationship to the
> shell, from the point of view of C?

C does not, however the build scripts run in the shell.

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
>
> Q2) What does -c entail in the above?

% man install
<snip>
       -c     (ignored)
<snip>

Looks like no.

> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C
> source of mkdir on my machine to ascertain why?

You probably don't want to read the source for this; go to the man page

% man mkdir

       -p, --parents
              no error if existing, make parent directories as needed

So you're creating a directory named 'boulder'; if it's already there it
won't be an error

> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.3 LTS
> Release:	16.04
> Codename:	xenial
> $
>
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
>
> Nothing crazy looking here. Do I gather correctly that g is an alias
> for gcc?

No, -g is an option that can be passed to gcc to make it put extra stuff
in the compiled code that will let you use debuggers.  It's checking and
seeing that, yes, gcc accepts that option.

> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed

I don't know what you mean here.

> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
>
> Again, cloudy about -c in this context.

The -c option to gcc says to create object code, but not to link it
together.  This is checking to see whether you can both do that and
assign a name to the object (.o) file with the -o option.

> Finally, I have one Big Question:
>
> Does the C Programming Language, as defined by C99, define anything
> about the shells that surround it? It's alright if the answer is no; I
> just want to know what it is.

No.

> From C's point of view, what is bash? Does bash have a standard it
> adheres to? Is that POSIX?

C itself doesn't care about bash -- but the build scripts need it.

I wouldn't be surprised if there were a standard that shells should
adhere to, but I don't know if there is one.

> Thanks for your comment. It's nice to "see old faces." I won't stick
> around too long if you just answer my questions.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

understanding C issues in geany install fred flintstone <fred@server.invalid> - 2018-02-01 11:55 -0800
  Re: understanding C issues in geany install Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-01 12:04 -0800
  Re: understanding C issues in geany install Keith Thompson <kst-u@mib.org> - 2018-02-01 12:19 -0800
    Re: understanding C issues in geany install Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-04 19:24 +0000
      Re: understanding C issues in geany install David Kleinecke <dkleinecke@gmail.com> - 2018-02-04 16:02 -0800
  Re: understanding C issues in geany install "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-01 15:39 -0500
    Re: understanding C issues in geany install fred flintstone <fred@server.invalid> - 2018-02-07 07:44 -0800
  Re: understanding C issues in geany install Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-01 16:08 -0700
  Re: understanding C issues in geany install gordonb.669da@burditt.org (Gordon Burditt) - 2018-02-05 20:56 -0600
  Re: understanding C issues in geany install John Bode <jfbode1029@gmail.com> - 2018-02-06 09:26 -0800
    Re: understanding C issues in geany install Keith Thompson <kst-u@mib.org> - 2018-02-06 12:36 -0800
    Re: understanding C issues in geany install "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-06 15:49 -0500
      Re: understanding C issues in geany install scott@slp53.sl.home (Scott Lurndal) - 2018-02-06 21:37 +0000

csiph-web