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

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

linking precedence rules

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

Contents

  linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-07 23:49 -0800
    Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-08 21:20 +1300
      Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-08 01:32 -0800
        Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 11:08 -0500
          Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 03:25 -0800
            Re: linking precedence rules Noob <root@127.0.0.1> - 2017-01-12 13:31 +0100
              OT Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 01:18 -0800
        Re: linking precedence rules Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 15:38 -0800
          Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 18:46 -0500
          Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 04:13 -0800
            Re: linking precedence rules Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 12:21 +0000
              Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 00:23 -0800
                Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-16 06:20 -0800
                  Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:10 -0800
                Re: linking precedence rules Manfred <noname@invalid.add> - 2017-02-04 17:12 +0100
                  Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 20:47 -0800
            Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:31 +0000
              Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-13 01:58 -0800
                Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:41 +0000
                  Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 03:49 -0800
                    Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 12:03 +0000
                      Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 14:02 +0100
                        Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 13:46 +0000
                          Re: linking precedence rules gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:23 +0000
                          Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:31 +0000
                            Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 16:18 +0000
                              Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 17:49 +0100
                                Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 17:21 +0000
                                  Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:12 +1300
                                    Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 21:59 +0000
                                      Re: linking precedence rules supercat@casperkitty.com - 2017-01-14 14:12 -0800
                                      Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 11:39 +1300
                                        Re: linking precedence rules Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 16:03 -0800
                                          Re: linking precedence rules raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:51 +0000
                                    Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 02:04 -0800
                                  Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 23:48 +0100
                              Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:28 +0000
                      The Unix way vs. the Windows way (Was: linking precedence rules) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:14 +0000
                        Re: The Unix way vs. the Windows way (Was: linking precedence rules) BartC <bc@freeuk.com> - 2017-01-14 14:29 +0000
                        Re: The Unix way vs. the Windows way (Was: linking precedence rules) supercat@casperkitty.com - 2017-01-14 14:20 -0800
                      Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 01:40 -0800
                        Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-15 11:43 +0000
                      Re: linking precedence rules antispam@math.uni.wroc.pl - 2017-01-18 19:55 +0000
                    Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:22 +0000
                Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 16:05 +0100
                  Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 15:37 +0000
                  Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 16:06 +0000
                    Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 19:37 +0100
                      Re: comparison logic BartC <bc@freeuk.com> - 2017-01-13 18:42 +0000
                      Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:49 +0000
                      Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 20:50 +0000
                        Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 01:05 -0800
                          Re: comparison logic Michael Holiday <Mike@example.invalid> - 2017-01-14 01:27 -0800
                          Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-14 13:56 -0800
                            Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 14:45 +0000
                            Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:42 -0800
                              Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-15 21:04 -0800
                                Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:47 -0800
                                  Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-30 11:40 -0800
                                    Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 16:42 -0800
                                      Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-03 18:45 -0800
                                        Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:03 -0800
                                          Re: comparison logic supercat@casperkitty.com - 2017-02-09 08:07 -0800
                                            Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 08:50 -0800
                                              Re: comparison logic supercat@casperkitty.com - 2017-02-09 12:15 -0800
                                                Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 12:38 -0800
                                                  Re: comparison logic supercat@casperkitty.com - 2017-02-09 14:13 -0800
                                                    Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 14:45 -0800
                                            Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 10:20 -0800
            Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-12 14:32 +0000
            Re: linking precedence rules James Kuyper <jameskuyper@verizon.net> - 2017-01-12 13:33 -0500

Page 1 of 4  [1] 2 3 4  Next page →

#101278 — linking precedence rules

I return to c.l.c with a closer focus on my c-compiling and linking 
woes, and would like to state my 2 questions as follows:

Q1) How does one see the results of the preprocessor?

Q2) in a standard conforming implementation such as gnu, what rules are 
used to sort out precedence with -I inclusion tags?

Specifically, if winbase.h is in 2 consecutive paths, which one is to be 
included, the former or latter?

BartC posted about just using first principles to compile and link. I 
wonder how that works with mingw.
--
Michael

[toc] | [next] | [standalone]

#101279

On 01/ 8/17 08:49 PM, Michael Holiday wrote:
> I return to c.l.c with a closer focus on my c-compiling and linking
> woes, and would like to state my 2 questions as follows:
>
> Q1) How does one see the results of the preprocessor?

The most common compiler option for this is -E.

> Q2) in a standard conforming implementation such as gnu, what rules are
> used to sort out precedence with -I inclusion tags?
>
> Specifically, if winbase.h is in 2 consecutive paths, which one is to be
> included, the former or latter?

That is a detail left to the implementation, the compiler documentation 
is the best place to look.

-- 
Ian

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

#101283

On 1/8/2017 12:20 AM, Ian Collins wrote:
> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>> I return to c.l.c with a closer focus on my c-compiling and linking
>> woes, and would like to state my 2 questions as follows:
>>
>> Q1) How does one see the results of the preprocessor?
>
> The most common compiler option for this is -E.

Ok. Thx. That will allow me to know whether execution has gone through a 
given path.

>> Q2) in a standard conforming implementation such as gnu, what rules are
>> used to sort out precedence with -I inclusion tags?
>>
>> Specifically, if winbase.h is in 2 consecutive paths, which one is to be
>> included, the former or latter?
>
> That is a detail left to the implementation, the compiler documentation
> is the best place to look.
>

Ok. I asked this question wrong. It's not about headers but rather the 
linking. I think I should have asked what the precedence rules are for 
the -L tag:

LDDLFLAGS = -mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" 
-static-libgcc -static-libstdc++
LDFLAGS = -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"

Also, there is no C:\STRAWB~1\perl\lib\CORE directory, which makes me 
think I need to link that with something real.
--
Mike

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

#101296

On 01/08/2017 04:32 AM, Michael Holiday wrote:
> On 1/8/2017 12:20 AM, Ian Collins wrote:
...
> Ok. I asked this question wrong. It's not about headers but rather the
> linking. I think I should have asked what the precedence rules are for
> the -L tag:
>
> LDDLFLAGS = -mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"
> -static-libgcc -static-libstdc++
> LDFLAGS = -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"

Note that LDDLFLAGS and LDFLAGS have no special meaning for gcc. Your 
directory names suggest that you're using a Windows system, so I'm not 
sure what significance those names have on your system, but on typical 
Unix-like systems, LDFLAGS is significant in the default rules used by 
the make routine. The following lines were extracted from the default 
make rules on my system:

     LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)

     %: %.c
     #  commands to execute (built-in):
	    $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@

I would presume that your system does something comparable with LDDLFLAGS.

> Also, there is no C:\STRAWB~1\perl\lib\CORE directory, which makes me
> think I need to link that with something real.

This is also something that is specific to the particular compiler 
you're using, and is best asked in compiler-specific forum. The man page 
for gcc on the computer I'm currently using says:

"You can mix options. For the most part, the order you use doesn’t 
matter.  Order does matter when you use several options of the same 
kind; for example, if you specify -L more than once, the directories are 
searched in the order specified.  Also, the placement of the -l option 
is significant."

Re: -l:
"The directories searched include several standard system directories 
plus any that you specify with -L."

"Note that you can also specify places to search using options such as 
-B, -I and -L.  These take precedence over places specified using 
environment variables, which in turn take precedence over those 
specified by the configuration of GCC." For -L, the relevant environment 
variable is LIBRARY_PATH.

Based upon my actual experience with gcc, a given -L option is used only 
when resolving external links while processing files that are specified 
after the -L option. This applies equally to source code files, object 
files, libraries specified with a full path, and libraries specified 
using -l. Thus, given the following command line:

gcc -L/A main.c -L/B subroutine.o -L/C /usr/lib/libXi.so.6 -L/D -lmylib

When resolving external links in main.c, it searches /A. When resolving 
them in subroutine.o, it search /A, and /B, in that order. When 
resolving them in libXi.so.6, it searches in /A, /B, and /C, in that 
order. It searches for libmylib.a (or .so), and any external links 
referred to by that library, in /A, /B, /C, and /D, in that order. In 
each of those cases, it then searches and places specified by 
LIBRARY_PATH, and those specified during the configuration of gcc, in 
that order (I have not actually tested this).

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

#101511

On 1/8/2017 8:08 AM, James R. Kuyper wrote:
> On 01/08/2017 04:32 AM, Michael Holiday wrote:
>> On 1/8/2017 12:20 AM, Ian Collins wrote:
> ...
>> Ok. I asked this question wrong. It's not about headers but rather the
>> linking. I think I should have asked what the precedence rules are for
>> the -L tag:
>>
>> LDDLFLAGS = -mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"
>> -static-libgcc -static-libstdc++
>> LDFLAGS = -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"
>
> Note that LDDLFLAGS and LDFLAGS have no special meaning for gcc. Your
> directory names suggest that you're using a Windows system, so I'm not
> sure what significance those names have on your system, but on typical
> Unix-like systems, LDFLAGS is significant in the default rules used by
> the make routine. The following lines were extracted from the default
> make rules on my system:
>
>     LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
>
>     %: %.c
>     #  commands to execute (built-in):
>         $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
>
> I would presume that your system does something comparable with LDDLFLAGS.

Alright, so LDDLFLAGS is implementation-specific. Which implementation? 
windows, gnu, perl, or mingw? (Yes, I am that clueless on getting this 
linked when it doesn't happen easily.)

I thought BartC's thread regarding "have we forgotten how to program?" 
was equal parts interesting and challenging. I have a problem described 
there: not having a module build automatically using cpan and after 
weeks in this rabbit hole, I find my first output. It's crushing me, and 
fates simply have it that I don't have linux on this machine right now, 
so I'm stuck on windows 10.

I've got all the pieces to put this thing together, I just need to link 
it to an updated mingw install. Apparently mingw 3.4.5 is pretty old 
now, and I find no easy means to update as a strawberry perl user.
>
>> Also, there is no C:\STRAWB~1\perl\lib\CORE directory, which makes me
>> think I need to link that with something real.
>
> This is also something that is specific to the particular compiler
> you're using, and is best asked in compiler-specific forum. The man page
> for gcc on the computer I'm currently using says:
>
> "You can mix options. For the most part, the order you use doesn’t
> matter.  Order does matter when you use several options of the same
> kind; for example, if you specify -L more than once, the directories are
> searched in the order specified.  Also, the placement of the -l option
> is significant."
>
> Re: -l:
> "The directories searched include several standard system directories
> plus any that you specify with -L."
>
> "Note that you can also specify places to search using options such as
> -B, -I and -L.  These take precedence over places specified using
> environment variables, which in turn take precedence over those
> specified by the configuration of GCC." For -L, the relevant environment
> variable is LIBRARY_PATH.
>
> Based upon my actual experience with gcc, a given -L option is used only
> when resolving external links while processing files that are specified
> after the -L option. This applies equally to source code files, object
> files, libraries specified with a full path, and libraries specified
> using -l. Thus, given the following command line:
>
> gcc -L/A main.c -L/B subroutine.o -L/C /usr/lib/libXi.so.6 -L/D -lmylib
>
> When resolving external links in main.c, it searches /A. When resolving
> them in subroutine.o, it search /A, and /B, in that order. When
> resolving them in libXi.so.6, it searches in /A, /B, and /C, in that
> order. It searches for libmylib.a (or .so), and any external links
> referred to by that library, in /A, /B, /C, and /D, in that order. In
> each of those cases, it then searches and places specified by
> LIBRARY_PATH, and those specified during the configuration of gcc, in
> that order (I have not actually tested this).

ok. I read that as gnu's linker finding linking libraries from left to 
right without replacement.

I believe this is where I need be finding headers. Is it also what the 
linker needs?

C:\MinGW>findstr /s SYMBOLIC_LINK_FLAG_DIRECTORY *.h
include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY  0x1
include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY 0x1

C:\MinGW>

Also, is that defined as 1?
-- 
Michael

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

#101517

On 12/01/2017 12:25, Michael Holiday wrote:

> ok. I read that as gnu's linker finding linking libraries from left to 
> right without replacement.
> 
> I believe this is where I need be finding headers. Is it also what the 
> linker needs?
> 
> C:\MinGW>findstr /s SYMBOLIC_LINK_FLAG_DIRECTORY *.h
> include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY  0x1
> include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY 0x1
> 
> C:\MinGW>
> 
> Also, is that defined as 1?

For those wondering how this might be on-topic for comp.lang.c
look closely at the path... He's working on the C: drive.

/me runs for the hills

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

#101728 — OT Re: linking precedence rules

On 1/12/2017 4:31 AM, Noob wrote:
> On 12/01/2017 12:25, Michael Holiday wrote:
>
>> ok. I read that as gnu's linker finding linking libraries from left to
>> right without replacement.
>>
>> I believe this is where I need be finding headers. Is it also what the
>> linker needs?
>>
>> C:\MinGW>findstr /s SYMBOLIC_LINK_FLAG_DIRECTORY *.h
>> include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY  0x1
>> include\winbase.h:#define SYMBOLIC_LINK_FLAG_DIRECTORY 0x1
>>
>> C:\MinGW>
>>
>> Also, is that defined as 1?
>
> For those wondering how this might be on-topic for comp.lang.c
> look closely at the path... He's working on the C: drive.
>
> /me runs for the hills
>

<OT>

You quoted me without answering my question. OP does not have to 
apologize that he has an implementation for his OS, his compiler, his 
linker. What makes mine unusual is the mix. I'm not happy about it. 
That's why I'm using this blizzard to assess it.

#if (_WIN32_WINNT >= 0x0600)
#define CreateSymbolicLink CreateSymbolicLinkW
#endif

I searched to find this perfectly-syntactical C in my header files, but 
I'm not sure what the value is on the RHS of the comparison.
-- 
Michael

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

#101321

On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday
<Mike@example.invalid> wrote:

>On 1/8/2017 12:20 AM, Ian Collins wrote:
>> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>>> I return to c.l.c with a closer focus on my c-compiling and linking
>>> woes, and would like to state my 2 questions as follows:
>>>
>>> Q1) How does one see the results of the preprocessor?
>>
>> The most common compiler option for this is -E.
>
>Ok. Thx. That will allow me to know whether execution has gone through a 
>given path.

The preprocessor has nothing to do with execution paths

-- 
Remove del for email

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

#101322

On 01/08/2017 06:38 PM, Barry Schwarz wrote:
> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday
> <Mike@example.invalid> wrote:
>
>> On 1/8/2017 12:20 AM, Ian Collins wrote:
>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>>>> I return to c.l.c with a closer focus on my c-compiling and linking
>>>> woes, and would like to state my 2 questions as follows:
>>>>
>>>> Q1) How does one see the results of the preprocessor?
>>>
>>> The most common compiler option for this is -E.
>>
>> Ok. Thx. That will allow me to know whether execution has gone through a
>> given path.
>
> The preprocessor has nothing to do with execution paths

I think he's thinking of conditional compilation (the #if family of 
preprocessor directives) rather than conditional execution. -E will 
address that issue.

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

#101515

On 1/8/2017 3:38 PM, Barry Schwarz wrote:
> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday
> <Mike@example.invalid> wrote:
>
>> On 1/8/2017 12:20 AM, Ian Collins wrote:
>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>>>> I return to c.l.c with a closer focus on my c-compiling and linking
>>>> woes, and would like to state my 2 questions as follows:
>>>>
>>>> Q1) How does one see the results of the preprocessor?
>>>
>>> The most common compiler option for this is -E.
>>
>> Ok. Thx. That will allow me to know whether execution has gone through a
>> given path.
>
> The preprocessor has nothing to do with execution paths
>

whether parsing has been performed. If I write the standard "hello 
world" program, how do I figure out which stdio.h is being used from the 
compiler's perspective?
--
Michael

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

#101516

On 12/01/17 12:13, Michael Holiday wrote:
> On 1/8/2017 3:38 PM, Barry Schwarz wrote:
>> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday
>> <Mike@example.invalid> wrote:
>>
>>> On 1/8/2017 12:20 AM, Ian Collins wrote:
>>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>>>>> I return to c.l.c with a closer focus on my c-compiling and linking
>>>>> woes, and would like to state my 2 questions as follows:
>>>>>
>>>>> Q1) How does one see the results of the preprocessor?
>>>>
>>>> The most common compiler option for this is -E.
>>>
>>> Ok. Thx. That will allow me to know whether execution has gone through a
>>> given path.
>>
>> The preprocessor has nothing to do with execution paths
>>
>
> whether parsing has been performed. If I write the standard "hello
> world" program, how do I figure out which stdio.h is being used from the
> compiler's perspective?

The Standard has nothing to say about this*, so this is properly a 
question for a newsgroup dealing with your specific implementation.

Your implementation's documentation may be able to answer your question.

* The Standard /does/ have something to say about a program supplying a 
header with the same name as a standard header: "If a file with the same 
name as one of the above < and > delimited sequences, not provided as 
part of the implementation, is placed in any of the standard places that 
are searched for included source files, the behavior is undefined." (So 
don't do that.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#101833

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 12/01/17 12:13, Michael Holiday wrote:
>> On 1/8/2017 3:38 PM, Barry Schwarz wrote:
>>> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday
>>> <Mike@example.invalid> wrote:
>>>
>>>> On 1/8/2017 12:20 AM, Ian Collins wrote:
>>>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote:
>>>>>> I return to c.l.c with a closer focus on my c-compiling and
>>>>>> linking woes, and would like to state my 2 questions as
>>>>>> follows:
>>>>>>
>>>>>> Q1) How does one see the results of the preprocessor?
>>>>>
>>>>> The most common compiler option for this is -E.
>>>>
>>>> Ok.  Thx.  That will allow me to know whether execution has
>>>> gone through a given path.
>>>
>>> The preprocessor has nothing to do with execution paths
>>
>> whether parsing has been performed.  If I write the standard
>> "hello world" program, how do I figure out which stdio.h is being
>> used from the compiler's perspective?
>
> The Standard has nothing to say about this*,

In a sense it does.  If stdio.h is included in the normal way,
ie,

    #include <stdio.h>

the Standard says this directive 

    searches a sequence of implementation-defined places for a
    header identified uniquely by the specified sequence between
    the < and > delimiters

to find the header.  (There are some other details - 6.10.2 p2.)
So in principle which <stdio.h> header is being used can be
discovered by looking at the implementation's documentation and
then checking out those places on your system.

> so this is properly a question for a newsgroup dealing with your
> specific implementation.
>
> Your implementation's documentation may be able to answer your
> question.

As I read the Standard, if the implementation is conforming, it
will (together with examining the identified places to see which
one has the <stdio.h> header).


> * The Standard /does/ have something to say about a program
> supplying a header with the same name as a standard header:  "If a
> file with the same name as one of the above < and > delimited
> sequences, not provided as part of the implementation, is placed
> in any of the standard places that are searched for included
> source files, the behavior is undefined."  (So don't do that.)

Here there is a subtlety that deserves amplification.  There are
two different kinds of #include lines, those with <>'s and those
with ""'s.  The first of these is covered by the passage given
above.  For the "" kind of #include line, that causes the line to
be replaced by a source file, where the file in question (per
6.10.2 p3)

    is searched for in an implementation-defined manner.

Now here is an interesting question: is the quoted excerpt above
(ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
is it also meant to apply to "places" (quoted because 6.10.2 p3
doesn't use the term) of 6.10.2 p3?  The use of 'standard places'
supports the view that it applies only to the 6.10.2 p2 places.
The use of 'included source files' supports the view that it also
applies to "places" where 6.10.2 p3 would find source files (note
though that a header, even a standard header, may be a source
file, even if it is not necessarily one).

I don't think either of the two positions above is absolutely
convincing.  I lean towards the view that only the places of
6.10.2 p2 are the ones that matter, because I think it makes more
sense:  after all, a #include <stdio.h> isn't going to go looking
in the 6.10.2 p3 "places" anyway, so there is no confusion if one
of those places has a file named stdio.h.  Furthermore it is
potentially useful to be able to supply a file that augments the
regular <stdio.h> header in some way, so #include "stdio.h" would
get that augmentation if it were there, or fall back to <stdio.h>
if it were not.  All upside, no downside - does anyone have a
different opinion on that assessment?

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

#101963

On 1/15/2017 12:23 AM, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 12/01/17 12:13, Michael Holiday wrote:

>> * The Standard /does/ have something to say about a program
>> supplying a header with the same name as a standard header:  "If a
>> file with the same name as one of the above < and > delimited
>> sequences, not provided as part of the implementation, is placed
>> in any of the standard places that are searched for included
>> source files, the behavior is undefined."  (So don't do that.)
>
> Here there is a subtlety that deserves amplification.  There are
> two different kinds of #include lines, those with <>'s and those
> with ""'s.  The first of these is covered by the passage given
> above.  For the "" kind of #include line, that causes the line to
> be replaced by a source file, where the file in question (per
> 6.10.2 p3)
>
>     is searched for in an implementation-defined manner.
>
> Now here is an interesting question: is the quoted excerpt above
> (ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
> is it also meant to apply to "places" (quoted because 6.10.2 p3
> doesn't use the term) of 6.10.2 p3?  The use of 'standard places'
> supports the view that it applies only to the 6.10.2 p2 places.
> The use of 'included source files' supports the view that it also
> applies to "places" where 6.10.2 p3 would find source files (note
> though that a header, even a standard header, may be a source
> file, even if it is not necessarily one).
>
> I don't think either of the two positions above is absolutely
> convincing.  I lean towards the view that only the places of
> 6.10.2 p2 are the ones that matter, because I think it makes more
> sense:  after all, a #include <stdio.h> isn't going to go looking
> in the 6.10.2 p3 "places" anyway, so there is no confusion if one
> of those places has a file named stdio.h.  Furthermore it is
> potentially useful to be able to supply a file that augments the
> regular <stdio.h> header in some way, so #include "stdio.h" would
> get that augmentation if it were there, or fall back to <stdio.h>
> if it were not.  All upside, no downside - does anyone have a
> different opinion on that assessment?
>

I don't understand you completely, Tim, so I won't edit you. I don't 
frankly know if it's fortran or c or ISO where they say the machine 
model for the syntax must be fulfilled by a conforming implementation, 
which gcc has been on windows ports.

Other parties might remain with their earlier versions of windows until 
their environmental variables work. Gosh, how did the washington crew 
screw up that one?

You too will have a loved one who is stuck on windows 10, so understand 
this as pioneering work. It's a real thing on windoze right now that you 
can't change the path in a usual fashion. I downloaded an app for it.

https://www.rapidee.com/en/about

It gave a lot of relevant values with highlighted controls. And after 
you look at the data a hundred times, all of a sudden it looks different:


08/25/2016  05:44 PM             1,306 rus1.txt
01/13/2017  10:55 PM                 0 SET
12/23/2016  12:39 AM             2,239 solstice1.pl
12/23/2016  12:01 AM             5,331 sunset1.pl
09/19/2016  07:19 PM             4,914 uncles11.txt
12/23/2016  01:46 AM           425,074 Untitled.xcf
07/19/2016  06:35 PM            66,627 Untitled55.png
12/21/2016  07:32 PM    <DIR>          Visual Studio 2012
12/20/2016  03:14 PM    <DIR>          Win32-LongPath-master
12/20/2016  03:09 PM            56,283 Win32-LongPath-master.zip
               58 File(s)      2,516,409 bytes
               19 Dir(s)  36,188,823,552 bytes free

C:\Users\Fred\Documents>del SET

The thing that stood out was the install of visual studio, pretty close 
to the time that this loss-of-footing occured. If authorized, it was a 
mistake. I think I've identified plenty of sources for my software train 
to have gone off-line, but what do you do when an OS puts a preferred 
compiling and linking system in your path?

For what it's worth, I worked through C Unleashed using MVC4 and then 
upgraded to 6, and never had a bad-linking experience. The terrain is 
shiftier for the cross-compiler.

I think this solves where gcc is looking for things now. There have been 
significant revisions with the number of compilers getting fewer.

C:\Users\Fred\Documents>gcc -E deque.c >>text1.txt

# 1 "deque.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "deque.c"
# 34 "deque.c"
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/string.h" 1 3
# 9 "C:/Strawberry/c/x86_64-w64-mingw32/include/string.h" 3
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/crtdefs.h" 1 3
# 10 "C:/Strawberry/c/x86_64-w64-mingw32/include/crtdefs.h" 3
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/_mingw.h" 1 3

-- 
Michael

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

#102750

Michael Holiday <Mike@example.invalid> writes:

> On 1/15/2017 12:23 AM, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 12/01/17 12:13, Michael Holiday wrote:
>>>
>>> * The Standard /does/ have something to say about a program
>>> supplying a header with the same name as a standard header:  "If a
>>> file with the same name as one of the above < and > delimited
>>> sequences, not provided as part of the implementation, is placed
>>> in any of the standard places that are searched for included
>>> source files, the behavior is undefined."  (So don't do that.)
>>
>> Here there is a subtlety that deserves amplification.  There are
>> two different kinds of #include lines, those with <>'s and those
>> with ""'s.  The first of these is covered by the passage given
>> above.  For the "" kind of #include line, that causes the line to
>> be replaced by a source file, where the file in question (per
>> 6.10.2 p3)
>>
>>     is searched for in an implementation-defined manner.
>>
>> Now here is an interesting question:  is the quoted excerpt above
>> (ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
>> is it also meant to apply to "places" (quoted because 6.10.2 p3
>> doesn't use the term) of 6.10.2 p3?  [...elaboration...]
>
> I don't understand you completely, Tim, [...]

My comment was basically irrelevant to your original question.
Good luck with your efforts to tame the vagaries of various
Microsoft environments.

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

#103142

On 1/15/2017 9:23 AM, Tim Rentsch wrote:
>> * The Standard /does/ have something to say about a program
>> supplying a header with the same name as a standard header:  "If a
>> file with the same name as one of the above < and > delimited
>> sequences, not provided as part of the implementation, is placed
>> in any of the standard places that are searched for included
>> source files, the behavior is undefined."  (So don't do that.)
>
> Here there is a subtlety that deserves amplification.  There are
> two different kinds of #include lines, those with <>'s and those
> with ""'s.  The first of these is covered by the passage given
> above.  For the "" kind of #include line, that causes the line to
> be replaced by a source file, where the file in question (per
> 6.10.2 p3)
>
>     is searched for in an implementation-defined manner.
>
> Now here is an interesting question: is the quoted excerpt above
> (ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
> is it also meant to apply to "places" (quoted because 6.10.2 p3
> doesn't use the term) of 6.10.2 p3?  The use of 'standard places'
> supports the view that it applies only to the 6.10.2 p2 places.
> The use of 'included source files' supports the view that it also
> applies to "places" where 6.10.2 p3 would find source files (note
> though that a header, even a standard header, may be a source
> file, even if it is not necessarily one).
>
> I don't think either of the two positions above is absolutely
> convincing.  I lean towards the view that only the places of
> 6.10.2 p2 are the ones that matter, because I think it makes more
> sense:  after all, a #include <stdio.h> isn't going to go looking
> in the 6.10.2 p3 "places" anyway, so there is no confusion if one
> of those places has a file named stdio.h.  Furthermore it is
> potentially useful to be able to supply a file that augments the
> regular <stdio.h> header in some way, so #include "stdio.h" would
> get that augmentation if it were there, or fall back to <stdio.h>
> if it were not.  All upside, no downside - does anyone have a
> different opinion on that assessment?
>
The way I read it, it is clear to me that the quoted excerpt (i.e. 7.1.2 
p3) only applies to #include directives as per  6.10.2 p2 (i.e. using <>).

An this makes perfectly sense (to me) if considering the rationale of 
6.10.2 p2 and 6.10.2 p3:

- when using <> inclusions the programmer explicitly wants to include 
one of the standard headers provided by the implementation (if it is not 
one of the standard headers, the syntax is meant to be used to #include 
some third-party header as provided by the supplier). In other words, 
the <> syntax is used to #include files as provided by the (supposedly 
trusted) suppliers. Obviously if one of the standard headers (say 
stdio.h) gets replaced with respect to the one provided by the 
implementation, the standard cannot guarantee the behaviour of the 
implementation.

- when using "" inclusions the programmer explicitly wants to the search 
to be extended first to other locations than the standard ones. i.e. the 
programmer is expected to know what he/she is doing, and in this respect 
the standard does not prevent #include "stdio.h" from including 
something else than the standard header (obviously if this happens you 
can't expect the implementation to behave as if #include <stdio.h> was 
written, so you are on your own).
On the other hand, I assume (I didn't check, but I am pretty sure) that 
the standard library uses the <> syntax to include headers, so if you 
write #include "stdio.h" and have stdio.h thus replaced, you may alter 
the behaviour of your own code, not of the library.

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

#103506

Manfred <noname@invalid.add> writes:

> On 1/15/2017 9:23 AM, Tim Rentsch wrote:
>>> * [7.1.2 p3] "If a
>>> file with the same name as one of the above < and > delimited
>>> sequences, not provided as part of the implementation, is placed
>>> in any of the standard places that are searched for included
>>> source files, the behavior is undefined."  [...]
>>
>> [...] here is an interesting question:  is the quoted excerpt above
>> (ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
>> is it also meant to apply to "places" (quoted because 6.10.2 p3
>> doesn't use the term) of 6.10.2 p3?  [...]
>
> The way I read it, it is clear to me that the quoted excerpt
> (i.e. 7.1.2 p3) only applies to #include directives as per  6.10.2 p2
> (i.e. using <>).

I agree this position is the more appealing one.  I still believe
there are plausible arguments on both sides, but this view
seems more like the common sense conclusion.

> An this makes perfectly sense (to me) if considering the rationale of
> 6.10.2 p2 and 6.10.2 p3: [..elaboration of why..]

And that's why I think so too.

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

#101518

Michael Holiday <Mike@example.invalid> writes:
<snip>
> whether parsing has been performed. If I write the standard "hello
> world" program, how do I figure out which stdio.h is being used from
> the compiler's perspective?

If you are using a gcc-derived compiler, you might find it has a -M
option.  This is intended for generating make files, but it has the
effect of showing you what files your source depends on which includes
all the systems files included either directly or indirectly.

-- 
Ben.

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

#101589

On 1/12/2017 5:31 AM, Ben Bacarisse wrote:
> Michael Holiday <Mike@example.invalid> writes:
> <snip>
>> whether parsing has been performed. If I write the standard "hello
>> world" program, how do I figure out which stdio.h is being used from
>> the compiler's perspective?
>
> If you are using a gcc-derived compiler, you might find it has a -M
> option.  This is intended for generating make files, but it has the
> effect of showing you what files your source depends on which includes
> all the systems files included either directly or indirectly.
>
C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>gcc 
-o differ -Wall diff1.c -IC:\MinGW\include
/mingw/lib/libmingw32.a(setargv.o):(.text+0x33): undefined reference to 
`__chkstk_ms'
...
/mingw/lib/libmingwex.a(glob.o):(.text+0xb2e): more undefined references 
to `__chkstk_ms' follow
collect2: ld returned 1 exit status

I took some C source from 
http://clc-wiki.net/wiki/K%26R2_solutions:Chapter_7:Exercise_6 , and 
added one more standard header, clearing the diagnostics which, I 
believe, precede the linking stage.

Then I thought, alright then, time to use that -M flag. I was expecting 
a bunch of parsed C in some form, but the command succeeds in creating 
an executable. When run, I get a window that tells me that a 16-bit 
application is not what this version of windows is gonna deal with:

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>gcc 
-o differ -Wall diff1.c -M -IC:\MinGW\include

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>differ 
Makefile Makefile.bak
This version of 
C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master\differ.exe 
is not compatible with the version of Windows you're running. Check your 
computer's system information and then contact the software publisher.

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>type 
diff1.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define MAXLINE 1000

void diff_line( char *lineone, char *linetwo, int linenumber )
{
   if(strcmp (lineone, linetwo) < 0 || strcmp (lineone, linetwo) > 0)
     printf( "%d<%s\n%d>%s\n", linenumber, lineone, linenumber, linetwo);
}

int main(int argc, char *argv[] )
{
   FILE *fp1, *fp2;
   char fp1_line[MAXLINE], fp2_line[MAXLINE];
   int i;

   if ( argc != 3 )
     {
       printf("differ fileone filetwo\n");
       exit(0);
     }

   fp1 = fopen( argv[1], "r" );
   if ( ! fp1 )
     {
       printf("Error opening file %s\n", argv[1]);
     }

   fp2 = fopen( argv[2], "r" );
   if ( ! fp2 )
     {
       printf("Error opening file %s\n", argv[2]);
     }
   i = 0;
   while ( (fgets(fp1_line, MAXLINE, fp1) != NULL)
           && (fgets(fp2_line, MAXLINE, fp2) != NULL))
   {
     diff_line( fp1_line, fp2_line, i );
     i++;
   }

   return 0;
}


The above is completely-standard C. How do I get this thing hooked up right?
-- 
Michael

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

#101593

Michael Holiday <Mike@example.invalid> writes:

> On 1/12/2017 5:31 AM, Ben Bacarisse wrote:
>> Michael Holiday <Mike@example.invalid> writes:
>> <snip>
>>> whether parsing has been performed. If I write the standard "hello
>>> world" program, how do I figure out which stdio.h is being used from
>>> the compiler's perspective?
>>
>> If you are using a gcc-derived compiler, you might find it has a -M
>> option.  This is intended for generating make files, but it has the
>> effect of showing you what files your source depends on which includes
>> all the systems files included either directly or indirectly.
>>
> C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>gcc
> -o differ -Wall diff1.c -IC:\MinGW\include
> /mingw/lib/libmingw32.a(setargv.o):(.text+0x33): undefined reference
> to `__chkstk_ms'
> ...
> /mingw/lib/libmingwex.a(glob.o):(.text+0xb2e): more undefined
> references to `__chkstk_ms' follow
> collect2: ld returned 1 exit status

These are linker errors.  I was answering your question about which
stdio.h is being used.

Some people, new to C, confuse the header file with the library that
eventually provides the code described by the header file.  If that's
the case here, I answered the question you asked but should have
consider the question you really intended.  For that (how to get your
version of gcc to link the right libraries) you will be much better off
asking people who know about mingw.

> I took some C source from
> http://clc-wiki.net/wiki/K%26R2_solutions:Chapter_7:Exercise_6 , and
> added one more standard header, clearing the diagnostics which, I
> believe, precede the linking stage.
>
> Then I thought, alright then, time to use that -M flag.

It's quite possible that the -M flag does something else when mingw sees
it.  But at the very best it would have answered the question about
include files.

<snip>
> The above is completely-standard C. How do I get this thing hooked up right?

You need to find out somewhere to ask that will find people who use
mingw.  It looks like something in your installation is broken.  Simple
program should be simple to compile (and indeed they were the few times
I ever used mingw).

-- 
Ben.

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

#101735

On 1/13/2017 2:41 AM, Ben Bacarisse wrote:
> Michael Holiday <Mike@example.invalid> writes:
>
>> On 1/12/2017 5:31 AM, Ben Bacarisse wrote:
>>> Michael Holiday <Mike@example.invalid> writes:
>>> <snip>
>>>> whether parsing has been performed. If I write the standard "hello
>>>> world" program, how do I figure out which stdio.h is being used from
>>>> the compiler's perspective?
>>>
>>> If you are using a gcc-derived compiler, you might find it has a -M
>>> option.  This is intended for generating make files, but it has the
>>> effect of showing you what files your source depends on which includes
>>> all the systems files included either directly or indirectly.
>>>
>> C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master\iuy\Win32-LongPath-master>gcc
>> -o differ -Wall diff1.c -IC:\MinGW\include
>> /mingw/lib/libmingw32.a(setargv.o):(.text+0x33): undefined reference
>> to `__chkstk_ms'
>> ...
>> /mingw/lib/libmingwex.a(glob.o):(.text+0xb2e): more undefined
>> references to `__chkstk_ms' follow
>> collect2: ld returned 1 exit status
>
> These are linker errors.  I was answering your question about which
> stdio.h is being used.
>
> Some people, new to C, confuse the header file with the library that
> eventually provides the code described by the header file.  If that's
> the case here, I answered the question you asked but should have
> consider the question you really intended.  For that (how to get your
> version of gcc to link the right libraries) you will be much better off
> asking people who know about mingw.

I was unclear about that in my own head, and it threw off the thread. 
It's hard to reel back one's own misconceptions.
>
>> I took some C source from
>> http://clc-wiki.net/wiki/K%26R2_solutions:Chapter_7:Exercise_6 , and
>> added one more standard header, clearing the diagnostics which, I
>> believe, precede the linking stage.
>>
>> Then I thought, alright then, time to use that -M flag.
>
> It's quite possible that the -M flag does something else when mingw sees
> it.  But at the very best it would have answered the question about
> include files.
>
> <snip>
>> The above is completely-standard C. How do I get this thing hooked up right?
>
> You need to find out somewhere to ask that will find people who use
> mingw.  It looks like something in your installation is broken.  Simple
> program should be simple to compile (and indeed they were the few times
> I ever used mingw).
>

I searched for mingw and windowsy-sounding places on usenet and didn't 
get much from the forum I posted on. I wasn't intending to make a career 
out of this. I'd be glad to hear of any ng's where gcc or mingw were 
more topical.

I disagree with you that my mingw install is broken. The one I'm trying 
to link to is hot off the presses, but there's 3 others on this machine 
that have altered paths and the like. One less tonight. What strikes me 
is how different they are in their architecture.
-- 
Michael

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web