On 05/02/2024 21:57, Kenny McCormack wrote:
> In article <8734u6lhop.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/5/2024 6:48 AM, Tim Rentsch wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 2/4/2024 8:41 PM, Keith Thompson wrote:
>>>>>> [...]
>>>>>>
>>>>>> Better yet, if you could cut down on the followups that don't add
>>>>>> anything relevant, I for one would appreciate it.
>>>> For what it's worth, I second Keith's request, and strenuously
>>>> support it.
>>>
>>> I was trying to lighten the mood, so to speak. Well, it backfired on me. ;^o
>>
>> Does that mean you're going to stop? You're just about to land in my
>> killfile, but I'm willing to reconsider. You do sometimes post relevant
>> content, but it's just not worth digging through the noise.
>
> The best possible thing that can happen to a CLC poster is to be killfiled
> by Keith - as I was (and still am) long ago. Then you are spared Keith's
> incessant bitching and whining about your posts.
>
> I am hoping Chris is lucky enough to be given this honor.
>

Ah. So of course Keith couldn't understand what I was saying.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Ah. So of course Keith couldn't understand what I was saying.

Malcolm, stop making personal comments about me. (Everyone else, please
don't respond to Malcolm's personal comments about me.)

--
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 2/4/2024 10:46 PM, Chris M. Thomasson wrote:
> On 2/4/2024 10:00 PM, Kenny McCormack wrote:
>> In article <87jznjle00.fsf@nosuchdomain.example.com>,
>> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 2/4/2024 5:45 PM, Lawrence D'Oliveiro wrote:
>>>>> On Mon, 5 Feb 2024 00:07:33 +0000, Malcolm McLean wrote:
>>>>>> On Windows you can't assume that the end user will be interested in
>>>>>> development or have any develoment tools available.
>>>>> Worse than that, the assumption is that development will be done in a
>>>>> proprietary, self-contained IDE, primarily sourced from a single
>>>>> vendor.
>>>>
>>>> https://youtu.be/i_6zPIWQaUI ;^)
>>>
>>> If you must post random YouTube links, can you at least include a 1-line
>>> description so we don't waste *too* much time?
>>>
>>> Better yet, if you could cut down on the followups that don't add
>>> anything relevant, I for one would appreciate it.
>>
>> Nice to see you back, Keith.  I've been worried about you.
>>
>> "14   A View to a Kill   Opening Theme 1985"
>>
>
> Right. I posted that link because totally relying on an IDE can be a
> view to a kill... ;^)

Our team is migrating to a new platform. Oh my, will my IDE work on this
new system... A view to a kill... ;^)

On 05/02/2024 22:47, Kaz Kylheku wrote:
> On 2024-02-05, bart <bc@freeuk.com> wrote:
>> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory
>
> This indicates that the thing you're trying to build was converted
> to Windows format. See that ^M? It's a carriage return; what's that
> doing in a POSIX shell script? Someone likely did that on purpose.
>
> Firstly, projects with ./configure shell scripts are often not ported to
> Windows at all. If that is the case, you could be the first one trying
> that. In that situation, the best bet is Cygwin. (Or WSL2, but that's
> basically not Windows.)
>
> The .zip file containing files converted to Windows format suggests
> that the package is ported to Windows, using some build environment that
> uses CR-LF files like MinGW.
>
> Your best bet is to consult the project and ask them, how is it ported
> to Windows? Then do it their way. Otherwise you're on your own.
>
> Another pattern that occurs is that FOSS projects which port their code
> to Windows themselves provide binaries for Windows, so they don't expect
> users to build those. Thus their procedure for building on Windows might not
> be well documented.
>
>> This is all quite typical.
>
> You not knowing where to get a glue and generally being lost
> at sea with no rudder or sail?
>
> Don't you have some nephew or niece in the fifth grade who could
> help with this?
>
> When I go to the NASM site (https://www.nasm.us) there is a clear
> Download link.
>
> In the download link, there are versioned and dated release
> directories.
>
> In the most recent one, there are Win32 and Win64 subdirectories.
>
> There is a file
>
> nasm-2.16.02rc9-installer-x64.exe
>
> Doh?
>
> They've gone out of the way to support Windows users with an executable
> installer.
>
> If you want to know how they built that, they may have documentation
> elsewhere. There might be instructions in the accompanying .zip or else
> you just have to as in the mailing list.

Yes I know there is an executable available for Windows. I first used
Nasm at least 20 years ago, perhaps 25.

But since it's supposed to be open source, I thought I'd have a go at
building it. And of course I tried it under Windows first.

I'm surprised that they went to the trouble of supplying configure
scripts with CRLF line-endings, given that you can't actually run it
under Windows.

In any case, LF line endings on Windows tend not to be a problem. My
editors generate LF not CRLF.

Anyway, if I fix those line endings in 'configure', then it says:

configure: error: cannot run /bin/bash autoconf/helpers/config.sub

On 2024-02-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote:
>
>> It /is/ a consumer platform, yes. And because it has no standard ways
>> to build software, and no one (approximately) using it wants to build
>> software on it, the norm is to distribute code in binary form for
>> Windows. That works out fine for almost all Windows users. That
>> includes libraries - even C programmers on Windows don't want to build
>> "libjpeg" or whatever, they want a DLL.
>
> But without integrated package management, how do you keep it all up to
> date? If two separate apps use the same library, do they each end up with
> their own version, or do they share one version? Does each app have to run
> its own periodic background updater task to tell you there’s a new version
> available?

Windows has solved this problem. Executables find .DLL libraries in
their own directory.

You ship a program with the exact libraries it needs which you
tested with and those are the ones it will use.

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

On 2024-02-05, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 05/02/2024 22:51, Lawrence D'Oliveiro wrote:
>> On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote:
>>
>>> It /is/ a consumer platform, yes. And because it has no standard ways
>>> to build software, and no one (approximately) using it wants to build
>>> software on it, the norm is to distribute code in binary form for
>>> Windows. That works out fine for almost all Windows users. That
>>> includes libraries - even C programmers on Windows don't want to build
>>> "libjpeg" or whatever, they want a DLL.
>>
>> But without integrated package management, how do you keep it all up to
>> date? If two separate apps use the same library, do they each end up with
>> their own version, or do they share one version? Does each app have to run
>> its own periodic background updater task to tell you there’s a new version
>> available?
>
> The term is DLL hell.

DLL hell is mostly historic term.

DLL hell occured on Windows when programs installed DLL files in the
System folder. In particular Common DLLs such Microsoft Visual Studio
run-time files.

Today, the situation that most closely fits the term is the situation on
Linux distributions.

The Glibc shared library loading mechanism doesn't implement the nice
strategy of finding libraries in the same directory as the executable.

Libraries must be dumped into a common respository, where you get issues
when programs need different versions of the same library and those
library versions are not cleanly distinguished by having a different
soname.

> If a DLL changes, does that means that apps which called the old DLL and
> are were buggy should call the new DLL and will now be fixed?

DLLs like kernel32.dll and user32.dll simply don't change, or not in
such a way.

Non-system things, you ship with the app, so they don't change unless
you issue an update.

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

In article <uprqfk$gcv2$2@dont-email.me>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>> I am hoping Chris is lucky enough to be given this honor.
>>
>
>Ah. So of course Keith couldn't understand what I was saying.

As you have correctly noted, Keith is clearly of a different psychological
type than you (and me). So, it is unlikely that useful communication will
ever happen between the two of you. Thus, it is best if he KF's you.

--
Many people in the American South think that DJT is, and will be remembered
as, one of the best presidents in US history. They are absolutely correct.

He is currently at number 46 on the list. High praise, indeed!

On 05/02/2024 23:41, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>> Ah. So of course Keith couldn't understand what I was saying.
>
> Malcolm, stop making personal comments about me. (Everyone else, please
> don't respond to Malcolm's personal comments about me.)
>

Ok. I'll agree. Sorry. I'm annoyed by the dismissive way in which I have
been treated and that's why I did it. But it's not really constructive
and I shouldn't have responded like that.

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

On 06/02/2024 01:07, Kaz Kylheku wrote:
> On 2024-02-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote:
>>
>>> It /is/ a consumer platform, yes. And because it has no standard ways
>>> to build software, and no one (approximately) using it wants to build
>>> software on it, the norm is to distribute code in binary form for
>>> Windows. That works out fine for almost all Windows users. That
>>> includes libraries - even C programmers on Windows don't want to build
>>> "libjpeg" or whatever, they want a DLL.
>>
>> But without integrated package management, how do you keep it all up to
>> date? If two separate apps use the same library, do they each end up with
>> their own version, or do they share one version? Does each app have to run
>> its own periodic background updater task to tell you there’s a new version
>> available?
>
> Windows has solved this problem. Executables find .DLL libraries in
> their own directory.
>
> You ship a program with the exact libraries it needs which you
> tested with and those are the ones it will use.
>

The two methods - a repository for common libraries, and individual
copies of the libraries for each program - have their advantages and
disadvantages.

If you have copies of the libraries for each program, that is
inefficient - bigger downloads and installs (which don't bother me, but
do bother some people), and extra copies in ram when running (which can
sometimes slow things down). The main problem, however, is that when a
serious bug is fixed, you need to wait for every individual program that
uses the library to be updated and provide a new release, then you have
to download them all anew.

If you have a common place for common libraries, updates of that library
are easy and only need to be done once when there is a fix. But now the
programs that are using it are not tested with the same version that you
have on your system, and there can be trouble if the API details change.
And you have the "DLL hell" possibility, though careful version
numbering and symbol links reduces that risk significantly.

There is no single "best" solution here.

On Fri, 2 Feb 2024 16:26:12 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 02/02/2024 14:45, Michael S wrote:
> >
> > Actually, nowadays monolithic tools are solid majority in
> > programming. I mean, programming in general, not C/C++/Fortran
> > programming which by itself is a [sizable] minority.
> > Even in C++, a majority uses non-monolithic tools well-hidden behind
> > front end (IDE) that makes them indistinguishable from monolithic.
> >
>
> It can often be helpful to have a single point of interaction - a
> front-end that combines tools. But usually these are made of parts.
>
> For many of the microcontrollers I work with, the manufacturer's
> standard development toolset is based around Eclipse and gcc. From
> the user point of view, it looks a lot like one monolithic IDE that
> lets you write your code, compile and link it, and download and debug
> it on the microcontroller. Under the hood, it is far from a
> monolithic application. Different bits come from many different
> places. This means the microcontroller manufacturer is only making
> the bits that are specific to /their/ needs - such as special views
> while debugging, or "wizards" for configuring chip pins. The Eclipse
> folk are experts at making an editor and IDE, the gcc folks are
> experts at the compiler, the openocd folks know about jtag debugging,
> and so on. And to a fair extent, advanced users can use the bits
> they want and leave out other bits. I sometimes use other editors,
> but might still use the toolchain provided with the manufacturer's
> tools. I might swap out the debugger connection. I might use the
> IDE for something completely different. I might install additional
> features in the IDE. I might use different toolchains.
> Manufacturers, when putting things together, might change where they
> get their toolchains, or what debugging connectors they use. It's
> even been known for them to swap out the base IDE while keeping most
> of the rest the same (VS Code has become a popular choice now, and a
> few use NetBeans rather than Eclipse).
>
> (Oh, and for those that don't believe "make" and "gcc" work on
> Windows, these development tools invariably have "make" and almost
> invariably use gcc as their toolchain, all working in almost exactly
> the same way on Linux and Windows. The only difference is builds are
> faster on Linux.)
>
> This is getting the best (or at least, trying to) from all worlds.
> It gives people the ease-of-use advantages of monolithic tools
> without the key disadvantages of real monolithic tools - half-arse
> editors, half-arsed project managers, half-arsed compilers, and poor
> extensibility because the suppliers are trying to do far too much
> themselves.
>
> I don't think it is common now to have /real/ monolithic development
> tools. But it is common to have front-ends aimed at making the
> underlying tools easier and more efficient to use, and to provide
> all-in-one base packages.
>
>
>

First, you moved a goal post from monolithic compiler to monolithic IDE.
Second, you are still talking about C/C++/Fortran.
That's not where majority of software development goes this days.

The first most used language is JavaScript. Where exactly JavaScript dev
sees separate compiler and linker?
The second most used language is python. The same question here.
Even in more traditional compiled/jitted and mostly statically typed
programming environments like Java/Cotlin, .net, Swift, go, Rust, even
if they use separate tools for compiling, assembling, linking and build
management, it's all integrated in a way that even die-hard command-line
user does not know about separation.

On 06/02/2024 12:59, Michael S wrote:
> On Fri, 2 Feb 2024 16:26:12 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 02/02/2024 14:45, Michael S wrote:
>>>
>>> Actually, nowadays monolithic tools are solid majority in
>>> programming. I mean, programming in general, not C/C++/Fortran
>>> programming which by itself is a [sizable] minority.
>>> Even in C++, a majority uses non-monolithic tools well-hidden behind
>>> front end (IDE) that makes them indistinguishable from monolithic.
>>>
>>
>> It can often be helpful to have a single point of interaction - a
>> front-end that combines tools. But usually these are made of parts.
>>
>> For many of the microcontrollers I work with, the manufacturer's
>> standard development toolset is based around Eclipse and gcc. From
>> the user point of view, it looks a lot like one monolithic IDE that
>> lets you write your code, compile and link it, and download and debug
>> it on the microcontroller. Under the hood, it is far from a
>> monolithic application. Different bits come from many different
>> places. This means the microcontroller manufacturer is only making
>> the bits that are specific to /their/ needs - such as special views
>> while debugging, or "wizards" for configuring chip pins. The Eclipse
>> folk are experts at making an editor and IDE, the gcc folks are
>> experts at the compiler, the openocd folks know about jtag debugging,
>> and so on. And to a fair extent, advanced users can use the bits
>> they want and leave out other bits. I sometimes use other editors,
>> but might still use the toolchain provided with the manufacturer's
>> tools. I might swap out the debugger connection. I might use the
>> IDE for something completely different. I might install additional
>> features in the IDE. I might use different toolchains.
>> Manufacturers, when putting things together, might change where they
>> get their toolchains, or what debugging connectors they use. It's
>> even been known for them to swap out the base IDE while keeping most
>> of the rest the same (VS Code has become a popular choice now, and a
>> few use NetBeans rather than Eclipse).
>>
>> (Oh, and for those that don't believe "make" and "gcc" work on
>> Windows, these development tools invariably have "make" and almost
>> invariably use gcc as their toolchain, all working in almost exactly
>> the same way on Linux and Windows. The only difference is builds are
>> faster on Linux.)
>>
>> This is getting the best (or at least, trying to) from all worlds.
>> It gives people the ease-of-use advantages of monolithic tools
>> without the key disadvantages of real monolithic tools - half-arse
>> editors, half-arsed project managers, half-arsed compilers, and poor
>> extensibility because the suppliers are trying to do far too much
>> themselves.
>>
>> I don't think it is common now to have /real/ monolithic development
>> tools. But it is common to have front-ends aimed at making the
>> underlying tools easier and more efficient to use, and to provide
>> all-in-one base packages.
>>
>>
>>
>
> First, you moved a goal post from monolithic compiler to monolithic IDE.
> Second, you are still talking about C/C++/Fortran.

I was thinking of compiled languages, yes.

> That's not where majority of software development goes this days.

Agreed.

>
> The first most used language is JavaScript. Where exactly JavaScript dev
> sees separate compiler and linker?
> The second most used language is python. The same question here.

Interpreted, byte-code compiled or JIT languages have a different model
entirely. But again, you have a front-end that appears monolithic,
hiding back-ends that are very far from monolithic. The language
front-end can come from one place, libraries from somewhere else, the VM
may be totally independent, and the JIT could be separate again. And if
you are using an IDE for it, as many do (regardless of the language),
you've got all the editors, revision control system, gui designer, HTML
previewer, and whatever else from another dozen independent sources and
all acting as one.

It is not monolithic by any means - but it /looks/ that way for user
convenience.

> Even in more traditional compiled/jitted and mostly statically typed
> programming environments like Java/Cotlin, .net, Swift, go, Rust, even
> if they use separate tools for compiling, assembling, linking and build
> management, it's all integrated in a way that even die-hard command-line
> user does not know about separation.
>

On Tue, 6 Feb 2024 13:14:14 +0100
David Brown <david.brown@hesbynett.no> wrote:
>
> It is not monolithic by any means - but it /looks/ that way for user
> convenience.
>

And Bart wants the same for slightly extended variant of C, that's all.
According to my understanding, he does not care deeply about
distinction between "true monolithic" and integrated compiler + linker
+ build system as long as it looks like monolithic.
Or may be I should say that he will certainly express his unhappiness
about size and speed of looks-monolithic tool and about the fact that
they have to be installed, if they have to be installed, at least 20
times per week, but at least he will be reasonably satisfied with
functionality.

On 06/02/2024 12:32, Michael S wrote:
> On Tue, 6 Feb 2024 13:14:14 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> It is not monolithic by any means - but it /looks/ that way for user
>> convenience.
>>
>
> And Bart wants the same for slightly extended variant of C, that's all.
> According to my understanding, he does not care deeply about
> distinction between "true monolithic" and integrated compiler + linker
> + build system as long as it looks like monolithic.
> Or may be I should say that he will certainly express his unhappiness
> about size and speed of looks-monolithic tool and about the fact that
> they have to be installed, if they have to be installed, at least 20
> times per week, but at least he will be reasonably satisfied with
> functionality.
>
>

The packaging of language installations is certainly one aspect that I'm
interested in. And my preference is to have as few files involved as
possible.

There is a trend now for newer languages to come as one giant
executable, although in practice they need a few more bits.

My own language projects do each come in one self-contained executable,
and are from 0.1MB to 0.6MB.

My original C compiler was also a single file, about 1MB.

My current one, because it is now private, is in 2-3 parts (mcc.exe,
aa.exe, about 360KB, and a discrete windows.h which was what took up
most of that 1MB). It behaves as though it is monolithic.

Regarding Tiny C, as it seems to be distributed, it requires a minimum
of 3 binaries (tcc.exe, libtcc.dll, libtcc1-64.a, about 220KB) in order
to build any of my generated-C applications. But for general use, it
needs a bunch of C header files too.

There are also products like Pico C, an interpreter, about 130KB
self-contained in one file, although it has limitations and is very slow
even for an interpreter. It could be adequate though for scripting builds.

I know David Brown doesn't like 'toy' implementations of C, but if you
need to bundle something for example, then the smaller and more
self-contained the better.

(FWIW, if I apply UPX compression to those examples, then Pico C reduces
to 32KB; my mcc/aa combo to 123KB, and tcc exe/lib/a combo to 141KB. But
the latter still needs discrete std header files.)

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.

scott@slp53.sl.home (Scott Lurndal) writes:
>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.
>

The tool we build consists of 157 shared objects. The libraries
are stored in tool-specific library directory; the main application
consists of a shared object and a very small executable containing
'main' (or a python 'shim' built using swig(1)).

The remaining shared objects are dynamically loaded if and as
necessary. There is no possibility of a library clash with either other
applications or different versions of the same application, yet
all active instances of the same version of the tool executing
on a given host will share the memory resident library text pages.

On 06/02/2024 15:16, bart wrote:
> There are also products like Pico C, an interpreter, about 130KB
> self-contained in one file, although it has limitations and is very slow
> even for an interpreter. It could be adequate though for scripting builds.
>
> I know David Brown doesn't like 'toy' implementations of C, but if you
> need to bundle something for example, then the smaller and more
> self-contained the better.
>

Just to be clear - you can have as many "toy" implementations of C as
you like. And sometimes small, fast, limited tools are useful - such as
if you want to have a C "interpreter".

(I can't see the point myself - there are better languages for
scripting, and they are not difficult to learn to the level you need for
scripting. Even your own scripting languages are a better choice than
interpreted C for pretty much any use.)

What I don't agree with is the idea that such small C implementations
are a viable replace for, or even better than, serious tools like gcc,
clang, icc, MSVC, Green Hills, Metrowerks, and other major compilers.

I am quite happy to accept that "small and fast" is a good thing - I
just don't give it anything like the weighting you do, at least for
normal compiler use.

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.

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