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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#101736

On 14/01/2017 11:49, Michael Holiday wrote:

> 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.

If you have more than one version of gcc on a Windows machine, my 
experience is that they will clash with each other.

You would think that, if you start the main executable from a place like 
c:\gcc\bin\gcc.exe, that it would look for associated files in the same 
location or using a relative path from that location. But gcc favoured 
searching through all the PATH paths until it found a file with the 
right name. Never mind that it belonged to a different version or even a 
different application!

-- 
Bartc

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

#101746

On 14/01/17 13:03, BartC wrote:
> On 14/01/2017 11:49, Michael Holiday wrote:
>
>> 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.
>
> If you have more than one version of gcc on a Windows machine, my
> experience is that they will clash with each other.
>
> You would think that, if you start the main executable from a place like
> c:\gcc\bin\gcc.exe, that it would look for associated files in the same
> location or using a relative path from that location. But gcc favoured
> searching through all the PATH paths until it found a file with the
> right name. Never mind that it belonged to a different version or even a
> different application!
>

The sensible way to handle this is not to put more than one version of 
gcc in your path.  This is true on Linux too - I have "normal" system 
gcc on the path, and dozens of different gcc's (for a variety of 
targets) in directory trees that are not on my path.  My Makefiles for 
project specify exactly where to find the relevant compiler for the 
project, and all other files, executables, headers, libraries, etc., are 
found based on that path.  It works in exactly the same way on Linux and 
Windows.

Of course, I know you Bart will run away screaming at the mention of 
"Makefile", but for almost everyone else who does C programming, it is 
convenient tool.

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

#101753

On 14/01/2017 13:02, David Brown wrote:
> On 14/01/17 13:03, BartC wrote:
>> On 14/01/2017 11:49, Michael Holiday wrote:
>>
>>> 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.
>>
>> If you have more than one version of gcc on a Windows machine, my
>> experience is that they will clash with each other.
>>
>> You would think that, if you start the main executable from a place like
>> c:\gcc\bin\gcc.exe, that it would look for associated files in the same
>> location or using a relative path from that location. But gcc favoured
>> searching through all the PATH paths until it found a file with the
>> right name. Never mind that it belonged to a different version or even a
>> different application!
>>
>
> The sensible way to handle this is not to put more than one version of
> gcc in your path.  This is true on Linux too - I have "normal" system
> gcc on the path, and dozens of different gcc's (for a variety of
> targets) in directory trees that are not on my path.  My Makefiles for
> project specify exactly where to find the relevant compiler for the
> project, and all other files, executables, headers, libraries, etc., are
> found based on that path.  It works in exactly the same way on Linux and
> Windows.

The difference is this: if I start an application as:

   > /abc/def/program[.exe]

Then under Windows, program.exe will be able to pick up the 
'/abc/def/program.exe' path to the executable, and use /abc/def/ as the 
base location for associated support files needed from inside the program.

I understand that that is not possible under Linux; it can only get the 
'program' part of the program invocation. so it has to use a whole 
different approach to the problem of where to find the files associated 
with /abc/def/program.

(I think there are ways ways to do it but it seems to go against the 
whole Unix/Linux ethos: 'Why on earth would you ever /need/ to know the 
path of the current executable?!'. Well, getting gcc to work properly 
for a start!)

> Of course, I know you Bart will run away screaming at the mention of
> "Makefile", but for almost everyone else who does C programming, it is
> convenient tool.

I have a set of sources for Tiny C comprising 16 .c files.

The makefile to build that is 349 lines. The configure file to go with 
it (and which doesn't run under Windows) is 540 lines.

I'm not making any judgement here, as people can draw their own 
conclusions. But the words 'sledgehammer' and 'nut' spring to mind!

But at least, you can rely on sledgehammer to do the job...

-- 
Bartc

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

#101762

In article <o5da1a$bvt$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
...
>The difference is this: if I start an application as:
>
>   > /abc/def/program[.exe]
>
>Then under Windows, program.exe will be able to pick up the 
>'/abc/def/program.exe' path to the executable, and use /abc/def/ as the 
>base location for associated support files needed from inside the program.
>
>I understand that that is not possible under Linux; it can only get the 
>'program' part of the program invocation. so it has to use a whole 
>different approach to the problem of where to find the files associated 
>with /abc/def/program.

You *CAN* do it in Linux, by doing a readlink on /proc/self/exe.  This is
guaranteed to work on any (more or less current - that is, later than about
1996) version of Linux.

But this might not work on generic Unix (aka, POSIX).  I think that you
(BartC) use Linux as if were synonymous with Unix.

Note that under many (but not necessarily all) circumstances, argv[0] does,
in fact, contain a full path - not just the tail - on Linux.

-- 
"Unattended children will be given an espresso and a free kitten."

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

#101764

BartC <bc@freeuk.com> writes:
<snip>
> The difference is this: if I start an application as:
>
>   > /abc/def/program[.exe]
>
> Then under Windows, program.exe will be able to pick up the
> '/abc/def/program.exe' path to the executable, and use /abc/def/ as
> the base location for associated support files needed from inside the
> program.
>
> I understand that that is not possible under Linux;

You understand incorrectly.  To find out the details, you know where to
ask.

<snip>
> (I think there are ways ways to do it but it seems to go against the
> whole Unix/Linux ethos: 'Why on earth would you ever /need/ to know
> the path of the current executable?!'. Well, getting gcc to work
> properly for a start!)

No, that is not needed to get gcc to work.  gcc has worked just fine for
me for decades without it ever having to know where I put the binary.

<snip>
-- 
Ben.

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

#101776

On 14/01/2017 14:31, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>> The difference is this: if I start an application as:
>>
>>   > /abc/def/program[.exe]
>>
>> Then under Windows, program.exe will be able to pick up the
>> '/abc/def/program.exe' path to the executable, and use /abc/def/ as
>> the base location for associated support files needed from inside the
>> program.
>>
>> I understand that that is not possible under Linux;
>
> You understand incorrectly.  To find out the details, you know where to
> ask.
>
> <snip>
>> (I think there are ways ways to do it but it seems to go against the
>> whole Unix/Linux ethos: 'Why on earth would you ever /need/ to know
>> the path of the current executable?!'. Well, getting gcc to work
>> properly for a start!)
>
> No, that is not needed to get gcc to work.  gcc has worked just fine for
> me for decades without it ever having to know where I put the binary.

On Windows, the files for gcc are stored together in the gcc-specific 
directory tree.

If you invoke it as \path\bin\gcc hello.c, how does it know where to 
find things such as 'cc1', or include files, or lib files?

One very easy way is, if it knows the location of itself, gcc.exe, then 
it can use that same path for cc1, or path\..\include for headers and so on.

But you would do away with that, and use what scheme instead?

I understand that on Linux, files associated with an application are 
disseminated all over the file system, and it has had to evolve schemes 
to deal with that, which people have come to think of it as normal.


-- 
Bartc

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

#101781

On 14/01/17 17:18, BartC wrote:
> On 14/01/2017 14:31, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>> The difference is this: if I start an application as:
>>>
>>>   > /abc/def/program[.exe]
>>>
>>> Then under Windows, program.exe will be able to pick up the
>>> '/abc/def/program.exe' path to the executable, and use /abc/def/ as
>>> the base location for associated support files needed from inside the
>>> program.
>>>
>>> I understand that that is not possible under Linux;
>>
>> You understand incorrectly.  To find out the details, you know where to
>> ask.
>>
>> <snip>
>>> (I think there are ways ways to do it but it seems to go against the
>>> whole Unix/Linux ethos: 'Why on earth would you ever /need/ to know
>>> the path of the current executable?!'. Well, getting gcc to work
>>> properly for a start!)
>>
>> No, that is not needed to get gcc to work.  gcc has worked just fine for
>> me for decades without it ever having to know where I put the binary.
>
> On Windows, the files for gcc are stored together in the gcc-specific
> directory tree.
>
> If you invoke it as \path\bin\gcc hello.c, how does it know where to
> find things such as 'cc1', or include files, or lib files?
>
> One very easy way is, if it knows the location of itself, gcc.exe, then
> it can use that same path for cc1, or path\..\include for headers and so
> on.
>
> But you would do away with that, and use what scheme instead?
>
> I understand that on Linux, files associated with an application are
> disseminated all over the file system, and it has had to evolve schemes
> to deal with that, which people have come to think of it as normal.
>

Again, you understand incorrectly.

An application may have a variety of files placed in a variety of 
standard directories - executables under /usr/bin, dynamic libraries in 
/usr/lib, and so on.  They are not "all over the file system" - the 
directories are well documented.  Some of the directory usage is 
"historical", but most is logical and practical.

Alternatively, an application may have its all its subdirectories (bin, 
usr, etc.) collected in one place.  This is common for software that is 
not part of the standard distribution software, and is in /opt or 
/usr/local.

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

#101782

On 14/01/2017 16:49, David Brown wrote:
> On 14/01/17 17:18, BartC wrote:

>> I understand that on Linux, files associated with an application are
>> disseminated all over the file system, and it has had to evolve schemes
>> to deal with that, which people have come to think of it as normal.
>>
>
> Again, you understand incorrectly.
>
> An application may have a variety of files placed in a variety of
> standard directories - executables under /usr/bin, dynamic libraries in
> /usr/lib, and so on.  They are not "all over the file system" - the
> directories are well documented.  Some of the directory usage is
> "historical", but most is logical and practical.

Yes, if I want to see the headers used by gcc, I can look in /usr/include.

However, if there are multiple gcc versions, or (inconceivable, I know) 
there are other C compilers not connected with gcc, where are /their/ 
include files?

If I have compiler X, and I want to make a copy of X and all its files, 
is it as simple as duplicating one directory tree, or do I have to 
duplicate multiple trees?

If I wanted to copy X (or any app) and its dependent files to a memory 
stick, how would /that/ be done?

It sounds a mess. I gave an analogy once which is still apt: it's like, 
instead of everyone having their kitchen in their own house, all the 
kitchens were located in their own quarter of town!

An advantage I suppose if your house burned down, as you'd still have a 
kitchen. But otherwise a little inconvenient.

> Alternatively, an application may have its all its subdirectories (bin,
> usr, etc.) collected in one place.  This is common for software that is
> not part of the standard distribution software, and is in /opt or
> /usr/local.

OK, let's go with that. I have a version of my app in /opt/A, (and maybe 
another version in /opt/B) and I run my program X from elsewhere using:

   /opt/A/X

Now X wants to access files a,b,c,d associated with X and which it knows 
are in the same place. But to do that it needs to find the path /opt/A/. 
Apparently this can be done, but when I was asking about it a few years 
ago, people seemed incredulous; why would I want to do that? It's not 
the Linux way; etc.

One scheme I used once was to package extra data files at the end of an 
executable (without re-building: take a working executable and add stuff 
to it). If the executable was invoked with no params, then it would look 
at that data. But to do that, again it needs the exact path of that 
executable. (For example, a self-installing executable downloaded with 
Firefox, which will be in some temp location anyway.)


-- 
Bartc

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

#101803

On 01/15/17 06:21 AM, BartC wrote:
> On 14/01/2017 16:49, David Brown wrote:
>> On 14/01/17 17:18, BartC wrote:
>
>>> I understand that on Linux, files associated with an application are
>>> disseminated all over the file system, and it has had to evolve schemes
>>> to deal with that, which people have come to think of it as normal.
>>>
>>
>> Again, you understand incorrectly.
>>
>> An application may have a variety of files placed in a variety of
>> standard directories - executables under /usr/bin, dynamic libraries in
>> /usr/lib, and so on.  They are not "all over the file system" - the
>> directories are well documented.  Some of the directory usage is
>> "historical", but most is logical and practical.
>
> Yes, if I want to see the headers used by gcc, I can look in /usr/include.

If you want to see the *system* headers used by all compilers on a Unix 
system, look in /usr/include.

If you want to find the *local* headers used by a gcc install, ask it 
(gcc -v).

> However, if there are multiple gcc versions, or (inconceivable, I know)
> there are other C compilers not connected with gcc, where are /their/
> include files?

Ask them, or read their documentation.

> If I have compiler X, and I want to make a copy of X and all its files,
> is it as simple as duplicating one directory tree, or do I have to
> duplicate multiple trees?

For my builds, just everything under the configured prefix.

>> Alternatively, an application may have its all its subdirectories (bin,
>> usr, etc.) collected in one place.  This is common for software that is
>> not part of the standard distribution software, and is in /opt or
>> /usr/local.
>
> OK, let's go with that. I have a version of my app in /opt/A, (and maybe
> another version in /opt/B) and I run my program X from elsewhere using:
>
>     /opt/A/X
>
> Now X wants to access files a,b,c,d associated with X and which it knows
> are in the same place. But to do that it needs to find the path /opt/A/.
> Apparently this can be done, but when I was asking about it a few years
> ago, people seemed incredulous; why would I want to do that? It's not
> the Linux way; etc.

It's oh so very hard, possibly beyond your grasp, bit we'll try anyway:

 > cat ~/temp/x.c
#include <stdio.h>

int main( int argc, char** argv ) { puts( argv[0] ); }

 > cc -o wibble ~/temp/x.c
 > cp wibble /opt/local/bin/
 > /opt/local/bin/wibble
/opt/local/bin/wibble

Oh look, it knows where it is!

-- 
Ian

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

#101809

On 14/01/2017 21:12, Ian Collins wrote:
> On 01/15/17 06:21 AM, BartC wrote:

>>     /opt/A/X
>>
>> Now X wants to access files a,b,c,d associated with X and which it knows
>> are in the same place. But to do that it needs to find the path /opt/A/.

> It's oh so very hard, possibly beyond your grasp, bit we'll try anyway:
>
>> cat ~/temp/x.c
> #include <stdio.h>
>
> int main( int argc, char** argv ) { puts( argv[0] ); }
>
>> cc -o wibble ~/temp/x.c
>> cp wibble /opt/local/bin/
>> /opt/local/bin/wibble
> /opt/local/bin/wibble
>
> Oh look, it knows where it is!

argv[0] displays the file path used to start the program.

In my example, that would actually be enough to locate it as it's fully 
qualified.

In other cases it will be relative (to the current directory), and you 
might need to do some messing about to get the full path (and that is 
now introduces an unnecessary platform dependency).

In yet other cases, someone types in a name that has to be looked up in 
a succession of locations until it's found. But it that case, argv[0] 
will not give that location, only what has been typed.

In one more another example, if the program in question is invoked by 
another program X that contains system("..."), and I run program X, 
argv[0] will only show is inside that "...", not the path that was used 
to invoke X.

In other words, argv[0] by itself is not a general solution to the problem.

Now, it's not in my nature to get personal and call people simple minded 
or ignorant or say they're talking nonsense, so I won't start now.

-- 
Bartc

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

#101811

On Saturday, January 14, 2017 at 3:59:56 PM UTC-6, Bart wrote:
> In yet other cases, someone types in a name that has to be looked up in 
> a succession of locations until it's found. But it that case, argv[0] 
> will not give that location, only what has been typed.

> Now, it's not in my nature to get personal and call people simple minded 
> or ignorant or say they're talking nonsense, so I won't start now.

Many of the platforms Unix people look down upon make the fully-qualified
path available to an application.  Such a feature is so obviously useful
to the users of platforms that supply it that people who use such
platforms may easily forget that some other platforms (Unix among them, by
the sound of it) don't supply it.

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

#101818

On 01/15/17 10:59 AM, BartC wrote:
> On 14/01/2017 21:12, Ian Collins wrote:
>> On 01/15/17 06:21 AM, BartC wrote:
>
>>>      /opt/A/X
>>>
>>> Now X wants to access files a,b,c,d associated with X and which it knows
>>> are in the same place. But to do that it needs to find the path /opt/A/.
>
>> It's oh so very hard, possibly beyond your grasp, bit we'll try anyway:
>>
>>> cat ~/temp/x.c
>> #include <stdio.h>
>>
>> int main( int argc, char** argv ) { puts( argv[0] ); }
>>
>>> cc -o wibble ~/temp/x.c
>>> cp wibble /opt/local/bin/
>>> /opt/local/bin/wibble
>> /opt/local/bin/wibble
>>
>> Oh look, it knows where it is!
>
> argv[0] displays the file path used to start the program.
>
> In my example, that would actually be enough to locate it as it's fully
> qualified.
>
> In other cases it will be relative (to the current directory), and you
> might need to do some messing about to get the full path (and that is
> now introduces an unnecessary platform dependency).

Well that's the crux of the issue: to be 100% reliable at run time 
you'll have to use a platform specific method.  This is why 
cross-platform tools like gcc either bake their paths in at build time 
though configure options, or use run-time configuration options.

-- 
Ian

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

#101830

On Saturday, January 14, 2017 at 10:39:37 PM UTC, Ian Collins wrote:
>
> Well that's the crux of the issue: to be 100% reliable at run time 
> you'll have to use a platform specific method.  This is why 
> cross-platform tools like gcc either bake their paths in at build time 
> though configure options, or use run-time configuration options.
> 
Paths are a complete nuisance.

That's fundamentally why Yahoo is in trouble whilst Google is almost
a monopoly. Hierarchy is good for organising information, but not
for finding it. You need content-addressable memory. I spend a lot
of time with installations finding that things don't work because
the paths aren't set up correctly and it's not obvious what the
setting should be, or if they should be relative or absolute or
relative to the user's root folder. Then you get spelling errors and
people use inconsistent capitalisation and don't always use English
words for file names. Then the quotes are sometimes mandatory,
and if the path is a directory sometimes it kicks up a fuss about
the trailing path-separator.

So you can end up running the script ten or twenty times before the
paths link.  

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

#102110

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Saturday, January 14, 2017 at 10:39:37 PM UTC, Ian Collins wrote:
> >
> > Well that's the crux of the issue: to be 100% reliable at run time 
> > you'll have to use a platform specific method.  This is why 
> > cross-platform tools like gcc either bake their paths in at build time 
> > though configure options, or use run-time configuration options.
> > 
> Paths are a complete nuisance.
> 
> That's fundamentally why Yahoo is in trouble whilst Google is almost
> a monopoly.

It's also why MS-DOS and Unix failed, and CP/M was so much more
succesful. Oh, and of course Microdrives have taken over from diskettes
entirely.

Richard

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

#101838

On 1/14/2017 1:12 PM, Ian Collins wrote:
> On 01/15/17 06:21 AM, BartC wrote:
>> On 14/01/2017 16:49, David Brown wrote:
>>> On 14/01/17 17:18, BartC wrote:
>>
>>>> I understand that on Linux, files associated with an application are
>>>> disseminated all over the file system, and it has had to evolve schemes
>>>> to deal with that, which people have come to think of it as normal.
>>>>
>>>
>>> Again, you understand incorrectly.
>>>
>>> An application may have a variety of files placed in a variety of
>>> standard directories - executables under /usr/bin, dynamic libraries in
>>> /usr/lib, and so on.  They are not "all over the file system" - the
>>> directories are well documented.  Some of the directory usage is
>>> "historical", but most is logical and practical.
>>
>> Yes, if I want to see the headers used by gcc, I can look in
>> /usr/include.
>
> If you want to see the *system* headers used by all compilers on a Unix
> system, look in /usr/include.
>
> If you want to find the *local* headers used by a gcc install, ask it
> (gcc -v).
>

Thx, Ian. I established this when I went down this rabbit hole but 
forgot its relevance.

C:\Users\Fred\Documents>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Strawberry/c/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --prefix=/mingw64 
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ 
--enable-shared --enable-static --disable-multilib 
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes 
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto 
--enable-graphite --enable-checking=release 
--enable-fully-dynamic-string --enable-version-specific-runtime-libs 
--enable-sjlj-exceptions --disable-isl-version-check 
--disable-cloog-version-check --disable-libstdcxx-pch 
--disable-libstdcxx-debug --disable-bootstrap --disable-rpath 
--disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona 
--with-tune=core2 --with-libiconv --with-system-zlib 
--with-gmp=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-mpfr=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-mpc=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-isl=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-cloog=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--enable-cloog-backend=isl --with-pkgversion='x86_64-posix-sjlj, built 
by strawberryperl.com project' CFLAGS='-O2 -pipe 
-I/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/include 
-I/opt/build/prerequisites/x86_64-zlib-static/include 
-I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' 
CXXFLAGS='-O2 -pipe 
-I/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/include 
-I/opt/build/prerequisites/x86_64-zlib-static/include 
-I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= 
LDFLAGS='-pipe 
-L/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/lib 
-L/opt/build/prerequisites/x86_64-zlib-static/lib 
-L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 4.9.2 (x86_64-posix-sjlj, built by strawberryperl.com project)

C:\Users\Fred\Documents>


<snip>
-- 
Michael

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

#101821

On 14/01/17 18:21, BartC wrote:
>
> OK, let's go with that. I have a version of my app in /opt/A, (and maybe
> another version in /opt/B) and I run my program X from elsewhere using:
>
>   /opt/A/X
>
> Now X wants to access files a,b,c,d associated with X and which it knows
> are in the same place. But to do that it needs to find the path /opt/A/.
> Apparently this can be done, but when I was asking about it a few years
> ago, people seemed incredulous; why would I want to do that? It's not
> the Linux way; etc.
>
> One scheme I used once was to package extra data files at the end of an
> executable (without re-building: take a working executable and add stuff
> to it). If the executable was invoked with no params, then it would look
> at that data. But to do that, again it needs the exact path of that
> executable. (For example, a self-installing executable downloaded with
> Firefox, which will be in some temp location anyway.)
>
>

To be entirely honest, I don't know how gcc does it.  I can think of a 
few different methods, but I don't know - and really, I don't care.  It 
works perfectly well - which I /do/ care about - but it does not matter 
to me whether it was a configuration option when gcc was build, reading 
/proc, or whatever.

I have lots of copies of gcc, of various versions, on a variety of 
systems.  Some of these I have build myself from source (it's sometimes 
just a few commands - but usually for my more specialised tools I follow 
a simple web page with instructions), and most have come as pre-built 
packages of compiler, libraries, and other tools.  I typically copy them 
from machine to machine with "scp".  I also have lots of copies of gcc 
on my Windows machine, again either built myself on Windows or from 
pre-built packages.  Usually these tools are a direct match for the 
Linux ones, with identical compiler and library versions and generating 
bit-perfect identical executables.

It all works.

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

#101801

BartC <bc@freeuk.com> writes:

> On 14/01/2017 14:31, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>> The difference is this: if I start an application as:
>>>
>>>   > /abc/def/program[.exe]
>>>
>>> Then under Windows, program.exe will be able to pick up the
>>> '/abc/def/program.exe' path to the executable, and use /abc/def/ as
>>> the base location for associated support files needed from inside the
>>> program.
>>>
>>> I understand that that is not possible under Linux;
>>
>> You understand incorrectly.  To find out the details, you know where to
>> ask.
>>
>> <snip>
>>> (I think there are ways ways to do it but it seems to go against the
>>> whole Unix/Linux ethos: 'Why on earth would you ever /need/ to know
>>> the path of the current executable?!'. Well, getting gcc to work
>>> properly for a start!)
>>
>> No, that is not needed to get gcc to work.  gcc has worked just fine for
>> me for decades without it ever having to know where I put the binary.
>
> On Windows, the files for gcc are stored together in the gcc-specific
> directory tree.

Your rhetorical question ("Why on earth would you ever /need/ to know
the path of the current executable?") suggests you are complaining about
Unix, but that feature is not needed to get gcc to run properly on Unix
systems.

It's obvious why that feature was needed on Windows -- that's how you
used to find configuration files before Microsoft thought that more than
one user account might be useful.

> If you invoke it as \path\bin\gcc hello.c, how does it know where to
> find things such as 'cc1', or include files, or lib files?

I don't know, but whenever I've used gcc on Windows it worked.

> One very easy way is, if it knows the location of itself, gcc.exe,
> then it can use that same path for cc1, or path\..\include for headers
> and so on.
>
> But you would do away with that, and use what scheme instead?

I would not do away with that at all.  I have no view on how a Windows
port of gcc should or should not work.

<snip>
-- 
Ben.

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

#101759 — The Unix way vs. the Windows way (Was: linking precedence rules)

In article <o5d400$p1e$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
>On 14/01/2017 11:49, Michael Holiday wrote:
>
>> 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.
>
>If you have more than one version of gcc on a Windows machine, my 
>experience is that they will clash with each other.

Yes, probably.  But why would you want to?

>You would think that, if you start the main executable from a place like 
>c:\gcc\bin\gcc.exe, that it would look for associated files in the same 
>location or using a relative path from that location. But gcc favoured 
>searching through all the PATH paths until it found a file with the 
>right name. Never mind that it belonged to a different version or even a 
>different application!

That's the Windows way - basing things on where they are installed.
It is not the Unix way - which is to assume a single monolithic setup,
where everything is in /usr/bin.

However, with GCC, you can work around it, using the env var
GCC_EXEC_PREFIX.  I have done so in the past and it works well.

P.S.  I *like* the "Windows Way" and think it is a lot more flexible than
the monolithic Unix way.  It is the wave of the future, and Linux is
evolving towards it.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Voltaire

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

#101763 — Re: The Unix way vs. the Windows way (Was: linking precedence rules)

On 14/01/2017 14:14, Kenny McCormack wrote:
> In article <o5d400$p1e$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
>> On 14/01/2017 11:49, Michael Holiday wrote:
>>
>>> 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.
>>
>> If you have more than one version of gcc on a Windows machine, my
>> experience is that they will clash with each other.
>
> Yes, probably.  But why would you want to?

The first gcc could only do 32-bit and not 64-bit.

The second one could only do 64-bit and not 32-bit.

The third might have been g++; I can't remember how many bits that was, 
but I'd imagine there would still be clashes.

If you had clang installed, it would piggy-back onto the first gcc it 
would find, and there would be a problem if the bit-size didn't match.

(Of course, it was totally against the rules for it to mention this tiny 
detail. I think I used clang for a year or two thinking it was a 
self-contained compiler - Jeez, for a 400MB download, you might think 
so! - until it stopped working when the gcc installation was messed up.

Now it doesn't work at all because new downloads piggy-bank onto MSVC 
and there's a problem with my MSVC or maybe I need VS or something.

So I had a 400MB C compiler that couldn't compile 'Hello World'. I never 
dreamt I would live to see such advances in compiler technology!)

> However, with GCC, you can work around it, using the env var
> GCC_EXEC_PREFIX.  I have done so in the past and it works well.

I'm not too worried about gcc at minute. I have one version that does 
both 32- and 64-bit, and it's working.

But on Linux I will look into using that /proc/... symbolic link thing 
to emulate GetModuleFileName for my own projects.

-- 
Bartc

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

#101813 — Re: The Unix way vs. the Windows way (Was: linking precedence rules)

On Saturday, January 14, 2017 at 8:14:28 AM UTC-6, Kenny McCormack wrote:
> Yes, probably.  But why would you want to?

As a simple example, testing out a new version of gcc while being able to
use the current well-tested version for production code.

As another example, being able to cross-compile for multiple target systems.

Whether or not all of the files associated with an executable should be
in subdirectories of its installation directory, having configuration
info in the application path seems like a nicer approach than having it
elsewhere [if the application path is read-only, information there could
direct an application to some other, writable, location].

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web