Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-02-06, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 06 Feb 2024 20:32:49 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>
>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>> interpreted by the dynamic linker. The dynamic linker has
>>>> a set of default paths that it uses, set by the distro,
>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>
>>> It’s a GNU thing, I think.
>>
>> It's a UNIX thing. GNU supports it, as it supports other
>> UNIX requirements.
>
>I can't find any mention of LD_LIBRARY_PATH in SuS.
>Not under dlopen or anywhere else.
>
>I'm looking at (pretty old) Solaris documentation. It has the $ORIGIN
>variable suppoted in both LD_LIBRARY_PATH and the internal path you can
>set in executables.
>
>I also found a 1998-08 commit from Ulrich Drepper adding the expansion
>support with ORIGIN.
>
>I think the documentation of it may have lagged behind, that's all,
>but we have had it "forever".

At least since circa 1989 when sunos added it. SVR4 was a merge between the
follow-on to SVR3 and sunos (which became Solaris), thus SVR4 inheritied
LD_LIBRARY_PATH from
sunos along with the sun dynamic linking capability (SVR3 had static
shared libraries - very painful to use as each library had to be linked
at a fixed VA, unique amongst all other shared libraries). Given a
2GB user va space, choosing an address for a new library became very
difficult.

Whether linux got it from Solaris or SVR4 probably doesn't much matter.

On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>
>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>> interpreted by the dynamic linker. The dynamic linker has
>> a set of default paths that it uses, set by the distro,
>> which can be overridden in LD_LIBRARY_PATH by each user.
>
> It’s a GNU thing, I think.

I think we've used it on AIX and HP-UX already.

Janis

On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>
>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>> interpreted by the dynamic linker. The dynamic linker has
>>> a set of default paths that it uses, set by the distro,
>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>
>> It’s a GNU thing, I think.
>
> I think we've used it on AIX and HP-UX already.

Some IBM documentation I was able to dig up on the web says that AIX 5.3
[2004] introduced LD_LIBRARY_PATH; before that it was LIBPATH in AIX
5.1, which continues to work. Nothing about the $SOURCE expansion.

The GCC Compile Farm Project has an AIX machine. I'm logging in there
now. Looks like the "load" and "dlopen" man pages reference
LD_LIBRARY_PATH. None of them mention any interpolation of parameters
being supported. It probably doesn't exist.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>:

> bart <bc@freeuk.com> writes:
>>On 04/02/2024 17:48, David Brown wrote:
>>> On 03/02/2024 20:35, bart wrote:
>>
>>>> It is Windows that places more store by file extensions, which Linux
>>>> people say is a bad thing.
>>>>
>>>
>>> Windows is too dependent on them, and too trusting.
>>
>>>> But above you say that is the advantage of Linux.
>>>
>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>>
>>Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
>
> I've never seen a '.x ' suffix. Ever. And I use linker scripts
> regularly.

This was the first I'd heard about them in this context, but Open
Network Computing's RPC (ONCRPC, was SunRPC) does use .x files
for its RPC specifications.

ONCRPC is a system for generating C stubs for network
services, and it is (was?) also used to specify
UNIX services like NFS and NIS. The Sun of yore
were, indeed, good denizens of the Net. (So, crossposting
conditions satisfied...I think?)

Anyway, if you have the "standard" .x files
installed on Linux Mint, they live in

/usr/include/rpcsvc/

Also, there are linker scripts that end in ".x"
which on my system live here:

/usr/lib/x86_64-linux-gnu/ldscripts/

Fascinating to read -- and way over my head. (The
man page for GNU ld says they are
"AT&T's Link Editor Command Language syntax".) I'm
not sure how often an average programmer would look
around in there.

In any event, the ".x" files in that directory are in
the minority...

--
-v
(cue music for "The X Files")
$ locate -r "\.x$"

On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:

> Also, there are linker scripts that end in ".x"
> which on my system live here:
>
> /usr/lib/x86_64-linux-gnu/ldscripts/
>
> Fascinating to read -- and way over my head. (The man page for GNU ld
> says they are "AT&T's Link Editor Command Language syntax".) I'm not
> sure how often an average programmer would look around in there.

Documentation on the script language here
<https://sourceware.org/binutils/docs/ld/Scripts.html>.

An obvious example of the need for a custom linker script would be
building the Linux kernel, where you need a special format for the
resulting binary that can be loaded by a bootloader.

I had a look through the Linux sources, and there is (no big surprise) a
different version of this script for each architecture, which is supposed
to have the name
arch/«architecture»/kernel/vmlinux.lds. I think this generated from the
corresponding vmlinux.lds.S file in the source tree.

On 07.02.2024 03:18, Kaz Kylheku wrote:
> On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>
>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>> interpreted by the dynamic linker. The dynamic linker has
>>>> a set of default paths that it uses, set by the distro,
>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>
>>> It’s a GNU thing, I think.
>>
>> I think we've used it on AIX and HP-UX already.
>
> Some IBM documentation I was able to dig up on the web says that AIX 5.3
> [2004] introduced LD_LIBRARY_PATH; before that it was LIBPATH in AIX
> 5.1, which continues to work. Nothing about the $SOURCE expansion.

My contact with AIX had been earlier, since the early 1990's, starting
with 3.5/3.6 (IIRC) to 4.1/4.3. A quick search did not show up much but
a later document (but earlier than your document) from 2001 explaining

"The LIBPATH environment variable is a colon-separated list of
directory paths, with the same syntax as the PATH environment
variable and indicates the search path for libraries. It has
the same function as the LD_LIBRARY_PATH environment variable
on SystemV." [ AIX Linking and Loading Mechanisms ]

Janis

> [...]

On 2/5/24 12:13, Kaz Kylheku wrote:
> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>> But the tools are *still preinstalled*, so installers can definitely
>> rely on compiling stuff.
>
> No, they aren't. It's common for devel tools not to be part of the base
> system of a distro.

Wait really?
--
user <candycane> is generated from /dev/urandom

On 07/02/2024 02:18, Kaz Kylheku wrote:
> On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>
>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>> interpreted by the dynamic linker. The dynamic linker has
>>>> a set of default paths that it uses, set by the distro,
>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>
>>> It’s a GNU thing, I think.
>>
>> I think we've used it on AIX and HP-UX already.
>
> Some IBM documentation I was able to dig up on the web says that AIX 5.3
> [2004] introduced LD_LIBRARY_PATH; before that it was LIBPATH in AIX
> 5.1, which continues to work. Nothing about the $SOURCE expansion.
>
> The GCC Compile Farm Project has an AIX machine. I'm logging in there
> now. Looks like the "load" and "dlopen" man pages reference
> LD_LIBRARY_PATH. None of them mention any interpolation of parameters
> being supported. It probably doesn't exist.
>

Wasn't it SHLIB_PATH on HP/UX?

On 07/02/2024 03:57, vallor wrote:
> On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal)
> wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>:
>
>> bart <bc@freeuk.com> writes:
>>> On 04/02/2024 17:48, David Brown wrote:
>>>> On 03/02/2024 20:35, bart wrote:
>>>
>>>>> It is Windows that places more store by file extensions, which Linux
>>>>> people say is a bad thing.
>>>>>
>>>>
>>>> Windows is too dependent on them, and too trusting.
>>>
>>>>> But above you say that is the advantage of Linux.
>>>>
>>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>>>
>>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
>>
>> I've never seen a '.x ' suffix. Ever. And I use linker scripts
>> regularly.
>
> This was the first I'd heard about them in this context, but Open
> Network Computing's RPC (ONCRPC, was SunRPC) does use .x files
> for its RPC specifications.
>
> ONCRPC is a system for generating C stubs for network
> services, and it is (was?) also used to specify
> UNIX services like NFS and NIS. The Sun of yore
> were, indeed, good denizens of the Net. (So, crossposting
> conditions satisfied...I think?)
>
> Anyway, if you have the "standard" .x files
> installed on Linux Mint, they live in
>
> /usr/include/rpcsvc/
>
> Also, there are linker scripts that end in ".x"
> which on my system live here:
>
> /usr/lib/x86_64-linux-gnu/ldscripts/
>
> Fascinating to read -- and way over my head. (The
> man page for GNU ld says they are
> "AT&T's Link Editor Command Language syntax".) I'm
> not sure how often an average programmer would look
> around in there.
>
> In any event, the ".x" files in that directory are in
> the minority...
>

If you look in that directory, you'll see all the files are ".x<flags>",
where <flags> are letters. So you get ".x", ".xbn", ".xc", ".xce", and
a dozen other combinations. I don't know the details of the flags, but
they generally refer to different arrangements of code and data (for
example, merging read-only data and executable code, or keeping them
separate).

There's no doubt that ".x", and ".x<flags>", are common extensions for
linker files, but that they do not act as file extensions in the same
way as for other source code. Instead, they are sets of flags. (That's
why gcc treats any unknown extension as a linker file.)

(Note to Bart - I am not saying I think this is a good idea - I am
saying how it is.)

I think most people writing their own linker scripts use different file
extensions - I use ".ld" myself.

On 07/02/2024 05:41, candycanearter07 wrote:
> On 2/5/24 12:13, Kaz Kylheku wrote:
>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>> But the tools are *still preinstalled*, so installers can definitely
>>> rely on compiling stuff.
>>
>> No, they aren't. It's common for devel tools not to be part of the base
>> system of a distro.
>
> Wait really?

If you install Windows you don't get Visual Studio and you have to
install it separately. If you install Linux you get gcc and other
development tools, and I don't think there's even a way of setting up
the install to say you don't want them.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 07/02/2024 08:42, David Brown wrote:
> On 07/02/2024 03:57, vallor wrote:
>> On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>:
>>
>>> bart <bc@freeuk.com> writes:
>>>> On 04/02/2024 17:48, David Brown wrote:
>>>>> On 03/02/2024 20:35, bart wrote:
>>>>
>>>>>> It is Windows that places more store by file extensions, which Linux
>>>>>> people say is a bad thing.
>>>>>>
>>>>>
>>>>> Windows is too dependent on them, and too trusting.
>>>>
>>>>>> But above you say that is the advantage of Linux.
>>>>>
>>>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>>>>
>>>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
>>>
>>> I've never seen a '.x ' suffix.  Ever.  And I use linker scripts
>>> regularly.
>>
>> This was the first I'd heard about them in this context, but Open
>> Network Computing's RPC (ONCRPC, was SunRPC) does use .x files
>> for its RPC specifications.
>>
>> ONCRPC is a system for generating C stubs for network
>> services, and it is (was?) also used to specify
>> UNIX services like NFS and NIS.  The Sun of yore
>> were, indeed, good denizens of the Net.  (So, crossposting
>> conditions satisfied...I think?)
>>
>> Anyway, if you have the "standard" .x files
>> installed on Linux Mint, they live in
>>
>> /usr/include/rpcsvc/
>>
>> Also, there are linker scripts that end in ".x"
>> which on my system live here:
>>
>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>
>> Fascinating to read -- and way over my head.  (The
>> man page for GNU ld says they are
>> "AT&T's Link Editor Command Language syntax".)  I'm
>> not sure how often an average programmer would look
>> around in there.
>>
>> In any event, the ".x" files in that directory are in
>> the minority...
>>
>
> If you look in that directory, you'll see all the files are ".x<flags>",
> where <flags> are letters.  So you get ".x", ".xbn", ".xc", ".xce", and
> a dozen other combinations.  I don't know the details of the flags, but
> they generally refer to different arrangements of code and data (for
> example, merging read-only data and executable code, or keeping them
> separate).
>
> There's no doubt that ".x", and ".x<flags>", are common extensions for
> linker files, but that they do not act as file extensions in the same
> way as for other source code.  Instead, they are sets of flags.  (That's
> why gcc treats any unknown extension as a linker file.)

A bit like my tools treat an unknown extension as a file of whatever
language the tool primarily works with?

Cool. But is gcc primarily used for linker files? I'm not even sure what
a linker file is!

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 07/02/2024 05:41, candycanearter07 wrote:
>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>> But the tools are *still preinstalled*, so installers can definitely
>>>> rely on compiling stuff.
>>>
>>> No, they aren't. It's common for devel tools not to be part of the base
>>> system of a distro.
>> Wait really?
>
> If you install Windows you don't get Visual Studio and you have to install
> it separately. If you install Linux you get gcc and other development
> tools, and I don't think there's even a way of setting up the install to
> say you don't want them.

Why do you say these things without checking? It's not uncommon to have
Linux installs without gcc.

--
Ben.

On 2024-02-07, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On 07/02/2024 05:41, candycanearter07 wrote:
>>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>>> But the tools are *still preinstalled*, so installers can definitely
>>>>> rely on compiling stuff.
>>>>
>>>> No, they aren't. It's common for devel tools not to be part of the base
>>>> system of a distro.
>>> Wait really?
>>
>> If you install Windows you don't get Visual Studio and you have to install
>> it separately. If you install Linux you get gcc and other development
>> tools, and I don't think there's even a way of setting up the install to
>> say you don't want them.
>
> Why do you say these things without checking? It's not uncommon to have
> Linux installs without gcc.

In fact, I haven't had Debian install build-essential (etc.) by default
in at least the past decade. It *might* be offered during the
installation phase, but the last time I reinstalled, I used their
netinst image (so certainly stripped down).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 07.02.2024 08:17, Richard Harnden wrote:
> On 07/02/2024 02:18, Kaz Kylheku wrote:
>> On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
>>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>>
>>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>>> interpreted by the dynamic linker. The dynamic linker has
>>>>> a set of default paths that it uses, set by the distro,
>>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>>
>>>> It’s a GNU thing, I think.
>>>
>>> I think we've used it on AIX and HP-UX already.
>>
>> Some IBM documentation I was able to dig up on the web says that AIX 5.3
>> [2004] introduced LD_LIBRARY_PATH; before that it was LIBPATH in AIX
>> 5.1, which continues to work. Nothing about the $SOURCE expansion.
>>
>> The GCC Compile Farm Project has an AIX machine. I'm logging in there
>> now. Looks like the "load" and "dlopen" man pages reference
>> LD_LIBRARY_PATH. None of them mention any interpolation of parameters
>> being supported. It probably doesn't exist.
>>
>
> Wasn't it SHLIB_PATH on HP/UX?

Maybe, I don't recall. My point was not so much the concrete name
of the environment variable but the availability of the function
connected with the respective variables.

Janis

On 07/02/2024 20:56, Malcolm McLean wrote:
> On 07/02/2024 05:41, candycanearter07 wrote:
>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>> But the tools are *still preinstalled*, so installers can definitely
>>>> rely on compiling stuff.
>>>
>>> No, they aren't. It's common for devel tools not to be part of the base
>>> system of a distro.
>>
>> Wait really?
>
> If you install Windows you don't get Visual Studio and you have to
> install it separately. If you install Linux you get gcc and other
> development tools, and I don't think there's even a way of setting up
> the install to say you don't want them.
>
If you install one of the Enterprise-aimed Linuxes, like RHEL or SLES,
they default is basically a machine with a console, and some basic services.

Cheers,
Gary B-)

On 07/02/2024 18:17, Richard Harnden wrote:
> On 07/02/2024 02:18, Kaz Kylheku wrote:
>> On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
>>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>>
>>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>>> interpreted by the dynamic linker.   The dynamic linker has
>>>>> a set of default paths that it uses, set by the distro,
>>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>>
>>>> It’s a GNU thing, I think.
>>>
>>> I think we've used it on AIX and HP-UX already.
>>
>> Some IBM documentation I was able to dig up on the web says that AIX 5.3
>> [2004] introduced LD_LIBRARY_PATH; before that it was LIBPATH in AIX
>> 5.1, which continues to work. Nothing about the $SOURCE expansion.
>>
>> The GCC Compile Farm Project has an AIX machine. I'm logging in there
>> now. Looks like the "load" and "dlopen" man pages reference
>> LD_LIBRARY_PATH. None of them mention any interpolation of parameters
>> being supported. It probably doesn't exist.
>>
>
> Wasn't it SHLIB_PATH on HP/UX?
>
It still is. (Yes, some of us have to maintain these boxes because,
although they were all amortised a decade or two ago, someone in a
bank/taxation department/insurance company/&c knows that replacing them
will be an expensive and time consuming process. So they'll be replaced
- after they collapse into a pile of rust - in a mad panic with Linux
boxes with something written in a mad rush in Python/PHP/Perl - by
people who don't understand the requirements, briefed by people who
don't understand the requirements - that sort of does the same job the
old machines did, if you squint really, really hard. And /don't/ get
audited by anyone competent. However, that one's *really* unlikely. :-) )

Cheers,
Gary B-)

On Wed, 7 Feb 2024 23:53:22 +1100
"Gary R. Schmidt" <grschmidt@acm.org> wrote:

> On 07/02/2024 18:17, Richard Harnden wrote:
> > On 07/02/2024 02:18, Kaz Kylheku wrote:
> >> On 2024-02-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
> >> wrote:
> >>> On 06.02.2024 21:32, Lawrence D'Oliveiro wrote:
> >>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
> >>>>
> >>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
> >>>>> interpreted by the dynamic linker.   The dynamic linker has
> >>>>> a set of default paths that it uses, set by the distro,
> >>>>> which can be overridden in LD_LIBRARY_PATH by each user.
> >>>>
> >>>> It’s a GNU thing, I think.
> >>>
> >>> I think we've used it on AIX and HP-UX already.
> >>
> >> Some IBM documentation I was able to dig up on the web says that
> >> AIX 5.3 [2004] introduced LD_LIBRARY_PATH; before that it was
> >> LIBPATH in AIX 5.1, which continues to work. Nothing about the
> >> $SOURCE expansion.
> >>
> >> The GCC Compile Farm Project has an AIX machine. I'm logging in
> >> there now. Looks like the "load" and "dlopen" man pages reference
> >> LD_LIBRARY_PATH. None of them mention any interpolation of
> >> parameters being supported. It probably doesn't exist.
> >>
> >
> > Wasn't it SHLIB_PATH on HP/UX?
> >
> It still is. (Yes, some of us have to maintain these boxes because,
> although they were all amortised a decade or two ago, someone in a
> bank/taxation department/insurance company/&c knows that replacing
> them will be an expensive and time consuming process. So they'll be
> replaced
> - after they collapse into a pile of rust - in a mad panic with
> Linux boxes with something written in a mad rush in Python/PHP/Perl -
> by people who don't understand the requirements, briefed by people
> who don't understand the requirements - that sort of does the same
> job the old machines did, if you squint really, really hard. And
> /don't/ get audited by anyone competent. However, that one's
> *really* unlikely. :-) )
>
> Cheers,
> Gary B-)

It does not have to be replaced with new solution even after original
hardware died.
https://www.stromasys.com/solution/charon-par/

For those that are currently on IPF variant of HP-UX, working hardware
is still easily available. However when it wouldn't be, I'd expect
that the same company will provide emulation solution. My theory is
that they already have it done, but as long as "real" HW is available
they are afraid to sell IPF emulators because of legal concerns.

On 07/02/2024 10:56, Malcolm McLean wrote:
> On 07/02/2024 05:41, candycanearter07 wrote:
>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>> But the tools are *still preinstalled*, so installers can definitely
>>>> rely on compiling stuff.
>>>
>>> No, they aren't. It's common for devel tools not to be part of the base
>>> system of a distro.
>>
>> Wait really?
>
> If you install Windows you don't get Visual Studio and you have to
> install it separately. If you install Linux you get gcc and other
> development tools, and I don't think there's even a way of setting up
> the install to say you don't want them.
>

There are several hundred Linux distributions, not including the niche
ones or outdated ones. Have you tried them all?

Most "normal user" oriented distros do not have gcc or related tools
installed by default, nor do most server systems, or firewall systems,
or small installations. Installing the tools is usually very simple
("apt-get install build-essentials", or equivalent), but they are not
included by default in the installation.

On 07/02/2024 14:09, David Brown wrote:
> On 07/02/2024 10:56, Malcolm McLean wrote:
>> On 07/02/2024 05:41, candycanearter07 wrote:
>>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>>> But the tools are *still preinstalled*, so installers can definitely
>>>>> rely on compiling stuff.
>>>>
>>>> No, they aren't. It's common for devel tools not to be part of the base
>>>> system of a distro.
>>>
>>> Wait really?
>>
>> If you install Windows you don't get Visual Studio and you have to
>> install it separately. If you install Linux you get gcc and other
>> development tools, and I don't think there's even a way of setting up
>> the install to say you don't want them.
>>
>
> There are several hundred Linux distributions, not including the niche
> ones or outdated ones.  Have you tried them all?
>
> Most "normal user" oriented distros do not have gcc or related tools
> installed by default, nor do most server systems, or firewall systems,
> or small installations.  Installing the tools is usually very simple
> ("apt-get install build-essentials", or equivalent), but they are not
> included by default in the installation.
>
>

I've tried a fair number. The ones that used to come CDs for you to boot
on a Windows PC. Ones installed on one or two crummy Linux notebooks.
The ones you downloaded to use with Virtual Box. The various versions
you downloaded and burned into an SD drive to plug into RPIs. And mostly
recently the ones that come with WSL.

I think pretty much all of them that I remember came with a C compiler.

So it is easy to make the assumption that gcc is always available.

But isn't this also supposed to be one big advantage of Linux over
Windows that this stuff is built-in?

> Installing the tools is usually very simple
> ("apt-get install build-essentials", or equivalent),

Is 'apt-get' always available?

On 07/02/2024 11:40, bart wrote:
> On 07/02/2024 08:42, David Brown wrote:
>> On 07/02/2024 03:57, vallor wrote:
>>> On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>> wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>> On 04/02/2024 17:48, David Brown wrote:
>>>>>> On 03/02/2024 20:35, bart wrote:
>>>>>
>>>>>>> It is Windows that places more store by file extensions, which Linux
>>>>>>> people say is a bad thing.
>>>>>>>
>>>>>>
>>>>>> Windows is too dependent on them, and too trusting.
>>>>>
>>>>>>> But above you say that is the advantage of Linux.
>>>>>>
>>>>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>>>>>
>>>>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
>>>>
>>>> I've never seen a '.x ' suffix.  Ever.  And I use linker scripts
>>>> regularly.
>>>
>>> This was the first I'd heard about them in this context, but Open
>>> Network Computing's RPC (ONCRPC, was SunRPC) does use .x files
>>> for its RPC specifications.
>>>
>>> ONCRPC is a system for generating C stubs for network
>>> services, and it is (was?) also used to specify
>>> UNIX services like NFS and NIS.  The Sun of yore
>>> were, indeed, good denizens of the Net.  (So, crossposting
>>> conditions satisfied...I think?)
>>>
>>> Anyway, if you have the "standard" .x files
>>> installed on Linux Mint, they live in
>>>
>>> /usr/include/rpcsvc/
>>>
>>> Also, there are linker scripts that end in ".x"
>>> which on my system live here:
>>>
>>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>>
>>> Fascinating to read -- and way over my head.  (The
>>> man page for GNU ld says they are
>>> "AT&T's Link Editor Command Language syntax".)  I'm
>>> not sure how often an average programmer would look
>>> around in there.
>>>
>>> In any event, the ".x" files in that directory are in
>>> the minority...
>>>
>>
>> If you look in that directory, you'll see all the files are
>> ".x<flags>", where <flags> are letters.  So you get ".x", ".xbn",
>> ".xc", ".xce", and a dozen other combinations.  I don't know the
>> details of the flags, but they generally refer to different
>> arrangements of code and data (for example, merging read-only data and
>> executable code, or keeping them separate).
>>
>> There's no doubt that ".x", and ".x<flags>", are common extensions for
>> linker files, but that they do not act as file extensions in the same
>> way as for other source code.  Instead, they are sets of flags.
>> (That's why gcc treats any unknown extension as a linker file.)
>
> A bit like my tools treat an unknown extension as a file of whatever
> language the tool primarily works with?
>
> Cool. But is gcc primarily used for linker files? I'm not even sure what
> a linker file is!
>

gcc (the program, as distinct from GCC the project) is a front-end - a
"driver". It passes its input files and flags on to the configured
tools, adding to or changing flags as appropriate, to run the C
compiler, C pre-processor, assembler, C++ compiler, other compilers
(Fortran, Ada, etc.), the linker, and so on. (The assembler and linker
are not part of the GCC project, but any given gcc build will usually be
configured to use an appropriate assembler and linker.)

Use of specific linker files is not common for building code on PC's -
the standard linker setups are usually fine. But it is quite common in
embedded development and other most specialised builds. Then you pass
one or more linker files to the linker, generally via the gcc front-end.

On 07/02/2024 14:09, David Brown wrote:
> On 07/02/2024 10:56, Malcolm McLean wrote:
>> On 07/02/2024 05:41, candycanearter07 wrote:
>>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>>> But the tools are *still preinstalled*, so installers can definitely
>>>>> rely on compiling stuff.
>>>>
>>>> No, they aren't. It's common for devel tools not to be part of the base
>>>> system of a distro.
>>>
>>> Wait really?
>>
>> If you install Windows you don't get Visual Studio and you have to
>> install it separately. If you install Linux you get gcc and other
>> development tools, and I don't think there's even a way of setting up
>> the install to say you don't want them.
>>
>
> There are several hundred Linux distributions, not including the niche
> ones or outdated ones.  Have you tried them all?
>
> Most "normal user" oriented distros do not have gcc or related tools
> installed by default, nor do most server systems, or firewall systems,
> or small installations.  Installing the tools is usually very simple
> ("apt-get install build-essentials", or equivalent), but they are not
> included by default in the installation.
>
>
I've installed Linux several times on a desktop machine. I can never
remember being given an option to not install gcc. It might be buried
away somewhere. Whilst there is embedded Linux, which is a rather
different matter, I've never seen a "normal user" distribution. Since as
you say there are hundreds than they might exist. But the regular
distributions are so easy to find that I'd be sceptical that a normal
user would obtain a "normal user" one.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Tue, 06 Feb 2024 13:07:31 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 06 Feb 2024 20:32:49 +0000, Lawrence D'Oliveiro wrote:
>>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>>> interpreted by the dynamic linker. The dynamic linker has
>>>> a set of default paths that it uses, set by the distro,
>>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>>
>>> It’s a GNU thing, I think.
>>
>> It's a UNIX thing. GNU supports it, as it supports other
>> UNIX requirements.
>
> Where is it documented as a UNIX requirement? POSIX doesn't seem to
> mention it.

You are correct; it's not mentioned in any of the POSIX or SUS
documentation that I could get my hands on.

However, it /is/ mentioned in the Solaris and SysV documentation,
so it comes from (some specific) Unix (system).

My (poorly made) point was that GNU didn't "invent" LD_LIBRARY_PATH
(as Lawrence's post implied to me), but copied it from existing Unix
systems. LD_LIBRARY_PATH is not a GNUism, but part of the Unix
heritage.

FWIW, GNU /could have/ used SHLIB_PATH (the HPUX equivalent of
LD_LIBRARY_PATH) instead. And my point here is that, when "shared
objects" became popular, Unix system authors/vendors tried to
mitigate "DLL hell", often by "inventing" the same mechanism
under different names.

--
Lew Pitcher
"In Skills We Trust"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>
>> Also, there are linker scripts that end in ".x"
>> which on my system live here:
>>
>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>
>> Fascinating to read -- and way over my head. (The man page for GNU ld
>> says they are "AT&T's Link Editor Command Language syntax".) I'm not
>> sure how often an average programmer would look around in there.
>
>Documentation on the script language here
><https://sourceware.org/binutils/docs/ld/Scripts.html>.
>
>An obvious example of the need for a custom linker script would be
>building the Linux kernel, where you need a special format for the
>resulting binary that can be loaded by a bootloader.

Indeed, that's been my primary use of custome linker scripts since
1989. Various operating systems, hypervisors, and even today for
processor firmware. Mainly we used the .ld suffix for such
scripts.

partial example for a bare-metal hypervisor written in C++:

OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)

ENTRY(dvmmstart)

SECTIONS
{ . = 0xffff808000000000;
percpu.data : {
*(percpu.data)
}
. = 0xffff830000100000;

_start = .;

. = ALIGN(16);
_stext = .;
.text : {
*(inittext)
*(.text)
*(.text.*)
*(.gnu.linkonce.t*)
}
_etext = .;

. = ALIGN(32);
_srodata = .;
.rodata : {
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r*)
*(.got)
*(.got.*)

__CTOR_LIST__ = .;
LONG((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
*(.ctors)
LONG(0)
__CTOR_END__ = .;

__DTOR_LIST__ = .;
LONG((__DTOR_END__ - __DTOR_LIST__) / 8 - 2)
*(.dtors)
LONG(0)
__DTOR_END__ = .;
}
_erodata = .;

. = ALIGN(32);
_sdata = .;
.data : {
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
}
_edata = .;

candycanearter07 <no@thanks.net> writes:
>On 2/5/24 12:13, Kaz Kylheku wrote:
>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>> But the tools are *still preinstalled*, so installers can definitely
>>> rely on compiling stuff.
>>
>> No, they aren't. It's common for devel tools not to be part of the base
>> system of a distro.
>
>Wait really?

Yes, most distros won't install -devel packages, just the binary packages.

Including ubuntu, just some of the packages we need to install
on a clean ubuntu:

apt-get update -y
apt -y install ksh
apt -y install csh
apt -y install tcsh
apt -y install nis
apt -y install autofs
apt -y install make
apt -y install libedit
apt -y install libedit-dev
apt -y install zlib1g
apt -y install zlib1g-dev
apt -y install ghostscript
apt -y install python3
apt -y install python3-config
apt -y install libelf-dev
apt -y install libboost-all-dev
apt -y install libpcap-dev
apt -y install libssl-dev
apt -y install libgmp-dev
apt -y install libattr1-dev
apt -y install environment-modules
apt -y install tclsh
apt -y install xterm
apt -y install libnss3-dev
apt -y install libatk1.0-0
apt -y install libatk-bridge-2.0-0-udeb
apt -y install libatk-bridge-2.0-0-udeb
apt -y install libatk-bridge-2.0
apt -y install libatk-bridge2.0-0
apt -y install libgtk2.0-0
apt -y install libgtk-3-0
apt -y install libgbm-dev
apt -y install libasound2
apt -y install yum-utils
apt -y install python-requests
apt -y install python-pexpect
apt -y install emacs
apt -y install vim-gtk
apt -y install numactl
apt -y install libmotif-dev
apt -y install tightvncserver
apt -y install patchelf
apt -y install p7zip-full
apt -y install meld
apt -y install ctags
apt -y install clang-format
apt -y install xfce4 xfce4-goodies
....

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 07/02/2024 05:41, candycanearter07 wrote:
>> On 2/5/24 12:13, Kaz Kylheku wrote:
>>> On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
>>>> But the tools are *still preinstalled*, so installers can definitely
>>>> rely on compiling stuff.
>>>
>>> No, they aren't. It's common for devel tools not to be part of the base
>>> system of a distro.
>>
>> Wait really?
>
>If you install Windows you don't get Visual Studio and you have to
>install it separately. If you install Linux you get gcc and other
>development tools, and I don't think there's even a way of setting up
>the install to say you don't want them.

That's 100% incorrect.

"install Linux" is ambiguous, since there are dozens of different
linux distributions, each with their own installation behavior.