On 2024-02-06, Nicolas George <nicolas$george@salle-s.org> wrote:
> Kaz Kylheku , dans le message <20240205160715.244@kylheku.com>, a
> écrit :
>> The Glibc shared library loading mechanism doesn't implement the nice
>> strategy of finding libraries in the same directory as the executable.
>
> This is not true, you know?

Yes, I see that there is $ORIGIN mechanism now.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-02-06, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>On 2024-02-05, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>
>>>
>>>The Glibc shared library loading mechanism doesn't implement the nice
>>>strategy of finding libraries in the same directory as the executable.
>>
>> Sure it does, if you tell it to. viz. LD_LIBRARY_PATH.
>
>Ah, that has this $ORIGIN mechanism now.
>
>Even if the distro doesn't have that in its LD_LIBRARY_PATH,
>you can put that into your executable's rpath.

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.

On Tue, 6 Feb 2024 14:16:59 +0000, bart wrote:

> There is a trend now for newer languages to come as one giant
> executable ...

I don’t know where you get that idea:

ldo@theon:~> dpkg-query -L python3.11
/.
/usr
/usr/bin
/usr/bin/pydoc3.11
/usr/bin/pygettext3.11
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3.11
/usr/lib/python3.11/lib-dynload
/usr/share
/usr/share/applications
/usr/share/applications/python3.11.desktop
/usr/share/doc
/usr/share/doc/python3.11
/usr/share/doc/python3.11/ACKS.gz
/usr/share/doc/python3.11/NEWS.gz
/usr/share/doc/python3.11/README.Debian
/usr/share/doc/python3.11/README.rst.gz
/usr/share/doc/python3.11/README.venv
/usr/share/doc/python3.11/changelog.Debian.gz
/usr/share/doc/python3.11/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/python3.11
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/pdb3.11.1.gz
/usr/share/man/man1/pydoc3.11.1.gz
/usr/share/man/man1/pygettext3.11.1.gz
/usr/share/man/man1/pysetup3.11.1.gz
/usr/share/pixmaps
/usr/share/pixmaps/python3.11.xpm
/usr/bin/pdb3.11
/usr/share/doc/python3.11/changelog.gz

Of course, that isn’t all of it:

ldo@theon:~> apt-cache depends python3.11
python3.11
Depends: python3.11-minimal
Depends: libpython3.11-stdlib
|Depends: media-types
Depends: mime-support
Breaks: python3-all
Breaks: python3-dev
Breaks: python3-venv
Recommends: ca-certificates
Suggests: python3.11-venv
Suggests: python3.11-doc
Suggests: binutils

The actual “python3” executable is in here:

ldo@theon:~> dpkg-query -L python3.11-minimal
/.
/usr
/usr/bin
/usr/bin/python3.11
/usr/lib
/usr/lib/binfmt.d
/usr/lib/binfmt.d/python3.11.conf
/usr/share
/usr/share/binfmts
/usr/share/binfmts/python3.11
/usr/share/doc
/usr/share/doc/python3.11-minimal
/usr/share/doc/python3.11-minimal/README.Debian.gz
/usr/share/doc/python3.11-minimal/changelog.Debian.gz
/usr/share/doc/python3.11-minimal/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/python3.11-minimal
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/python3.11.1.gz

Is this your idea of a “giant” executable?

ldo@theon:~> ls -lL /usr/bin/python3
-rwxr-xr-x 1 root root 6784920 Dec 9 03:22 /usr/bin/python3

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.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>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.

LD_LIBRARY_PATH was originally a "sunos" thing, and was adopted
by SVR4 when they added support for shared objects.

Predates GNU.

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.

--
Lew Pitcher
"In Skills We Trust"

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.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>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.

I suspect Lew meant lower-case unix, from whence it originated
(sunos -> svr4 -> linux), rather than the Single Unix Specification
from which the trademark derives and which has been folded in with
POSIX 1003.

The SuS doesn't discuss the details of run-time linking outside
of specifying dlopen/dlsym/dlclose/dlerror:

"The class of executable object files eligible for this operation
and the manner of their construction are implementation-defined,
though typically such files are shared libraries or programs."

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