On 07/02/2024 15:27, Scott Lurndal wrote:
> 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 = .;
>
So what the hell is that? What does it mean? How am i supposed to fix it
if it goes wrong?
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/7/24 08:21, bart wrote:
> 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?

It depends on the distro. apt is exclusive to Debian/Ubuntu. Other
distros do have their own package managers though.
--
user <candycane> is generated from /dev/urandom

On 2/7/24 09:30, Scott Lurndal wrote:
> 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

Weird. IG i haven't reinstalled in a while..
--
user <candycane> is generated from /dev/urandom

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

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

Which is beside the point. You said you "get gcc and other development
tools". Which distribution(s) did you install?

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 07/02/2024 15:27, Scott Lurndal wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>>>

>>
>So what the hell is that? What does it mean? How am i supposed to fix it
>if it goes wrong?

I suspect you've been the internet long enough to have seen the
phrase RTFM...

candycanearter07 <no@thanks.net> writes:
> On 2/7/24 09:30, Scott Lurndal wrote:
>> 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
[43 lines deleted]
>> apt -y install clang-format
>> apt -y install xfce4 xfce4-goodies
>
> Weird. IG i haven't reinstalled in a while..

When you post a followup to a long article, please delete any quoted
material that isn't relevant to your followup, as I've done here.
Thanks.

--
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 */

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> 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.
>
> Which is beside the point. You said you "get gcc and other development
> tools". Which distribution(s) did you install?

Did you reply via email by accident, or would you rather not answer
here?

--
Ben.

On 2/7/24 10:40, Keith Thompson wrote:
> candycanearter07 <no@thanks.net> writes:
>> On 2/7/24 09:30, Scott Lurndal wrote:
>>> 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
> [43 lines deleted]
>>> apt -y install clang-format
>>> apt -y install xfce4 xfce4-goodies
>>
>> Weird. IG i haven't reinstalled in a while..
>
> When you post a followup to a long article, please delete any quoted
> material that isn't relevant to your followup, as I've done here.
> Thanks.

Sorry.
--
user <candycane> is generated from /dev/urandom

On 2024-02-07, Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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

Which "Linux"?

There are numerous distros which have their own install systems
with their own rules.

> development tools, and I don't think there's even a way of setting up
> the install to say you don't want them.

In 27 years, I dont' remember a major Linux distro foisting the compiler
on me as a required base package.

Typically it's an opt-in during package selection.

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

On Wed, 7 Feb 2024 15:02:07 -0000 (UTC), Lew Pitcher wrote:

> LD_LIBRARY_PATH is not a GNUism, but part of the Unix heritage.

This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark to
the lawyers and those with enough money to pay them. We just get on and do
our work on “*nix” systems.

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

We don’t have “DLL hell” because we don’t have “DLLs”, we have “shared
objects” which can be versioned.

On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:

> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.
>
> This proposal comes under 'convenient' rather than 'automatic'. (I did
> try an automatic scheme in the past, but that only worked for specially
> written projects.)
>
> Here, the method is straightforward: the necessary info is simply listed
> in the designated lead module, within a set of #pragma lines.
>
> For my go-to small project demo, which comprises the three source files
> cipher.c, hmac.c, sha2.c, there are two ways to do it:
>
> (1) Add the info to top of the lead module cipher.c:
>
> #pragma module "hmac.c"
> #pragma module "sha2.c"
> ....
>
> I wasn't intending to actually implement it, but it didn't take long,
> and it seems to work:
>
> c:\cx>mcc cipher Compiling cipher.c to cipher.exe Adding module
> hmac.c Adding module sha2.c
>
> (2) Create an extra lead module and add it to the project.
>
> This allows the scheme to be superimposed on an existing codebase
> without having to modify it. If I try that on the above cipher project
> in a new module demo.c, it will contain:
>
> #pragma module "cipher.c"
> #pragma module "hmac.c"
> #pragma module "sha2.c"
>
> It works like this (in the real version those "Adding" lines will be
> silent):
>
> c:\cx>mcc demo Compiling demo.c to demo.exe Adding module cipher.c
> Adding module hmac.c Adding module sha2.c
>
> To get the original cipher.exe output needs an override option, but see
> below.
>
> Method (2) is attractive as it provides a means to easily set up
> different configurations of an applications, but mix-and-matching
> modules.
>
> Pragma Directives -----------------
>
> These are the ones I had in mind:
>
> module "file.c" As used above. Possibly, wildcards can work here
>
> import "file.c Incorporate a separate project which has its own
> set of pragma directives
>
> link "file.dll" Any binary libraries
>
> header "file.h" Specify a program-wide shared header
>
> Possibly the 'import' one can be dispensed with; it is simple enough to
> manually copy and past the necessary info. However that means it is
> listed in more than one place, and the original can change.
>
> The idea of 'header' is to specify big headers (windows.h, sdl2.h, etc)
> which are independent of anything else, which are then processed just
> once in the compiler, rather than once for each module that includes
> them. The usual '#include's are still needed.
>
> (The intention is not to create a whole-program compiler, or to
> introduce a module scheme, although this provides some of the benefits.
> The C language is unchanged.)
>
> Possibly, there can be a directive called 'name' to specify an
> executable file name.
>
> Working with Other Compilers ----------------------------
>
> Clearly, my scheme will only work with a suitable modified compiler.
> Without that, then I considered doing something like this, adding this
> block to my example from (2):
>
> #pragma module "cipher.c"
> #pragma module "hmac.c"
> #pragma module "sha2.c"
>
> #ifndef __MCC__
> #include "runcc.c"
>
> int main(void) {
> runcc(__FILE__);
> }
> #endif
>
> When run a compiler that is not MCC, this builds a small program (here
> still called demo.exe), which calls a function to read from this file,
> process the relevant #pragma lines, and use that info to invoke a
> conventional compiler.
>
> I haven't tested it, but it would mean a two-step process that looks
> something like this (possibly, it can pick up the name of the compiler
> that /is/ used, and invoke that on the actual program):
>
> c:\cx\tcc demo.c c:\cx\demo ... invoke tcc to build cipher.c hmac.c
> sha2.c ...
>
> (Tcc of course also has the -run option to save that second line)
>
> For this to work, the pragma stuff must be cleanly written: the runcc()
> function will only do basic string processing, it is not a C compiler.
>
>
> Using a Makefile ----------------
>
> One use-case for this would be if /I/ supplied a multi-module C program,
> or packaged someone else's.
>
> But people are mad about makefiles so, sure, I can also supply a 2-line
> makefile to do the above.
>
> Dependencies and Incremental Compilation
> ----------------------------------------
>
> This project is not about that, and is for cases where compiling all
> sources in one go is viable, or where a one-off build time is not
> relevant.
>
> That can mean when using fast a compiler and/or the scale of the project
> allows.
>
> Although the 'header' directive will also help, in cases where the
> application itself is small, but has dependencies on large complex
> headers. (I haven't quite figured out how it might work though.)

We already had some similar topics here. I think I have sugested
pragma source.

I am using a build system that is a C program.

This is the "build" file I use to build cake. It works on
windows and linux. gcc etc..

https://github.com/thradams/cake/blob/main/src/build.c

I will call "pragma module" as automaticaly source discover.
We can break the build in sub problems, one of then is source
code discovery.
The build I am using has a manual list of sources.

#define SOURCE_FILES \
" file1.c " \
" file2.c " \
...

The other problems are for instance, settings, like flags etc.

I also have "#pragma directory" to inform where the include dir are.

I think everthing should be controled with pragmas then we have a
choice to use a separated file, for instance a file just with
pragma modulo, or include pragma module inside normal source code.

I am not sure you realized this, but it is possible to create a tool,
with a C preprocessor that can scan source and discovery all the
sources automatically. It also could be a special comment instead of
pragma. Doing this the build system can be created without a new compiler,}
it is just a tool that collects source code and then call the compiler.

build source.c

where build is a program compiled to use gcc for instance.
The first pass it will scan the source.c and find all sources.
The next step it will compile each source.

my point is that this can be done today without changes in gcc clang etc..

I think "pragma source" or pragma module should be implemented in clang
etc... It does not need to be on the standard initially, all we need is a
tool and then compiler implementing this feature.

I think setting like warnings , include dir, library dir, also needs to
be controled inside source files.

On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:

> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.

I have also created a tool that generates the build program.

https://github.com/thradams/buildgen

I also have in my build
- unit tests
- documentation
-

On Wed, 7 Feb 2024 09:56:03 +0000, Malcolm McLean wrote:

> If you install Linux you get gcc and other development tools ...

Normally, no. Considering a distro like Debian, essentially you don’t
get anything unless you ask for it.

Also on distros based on prebuilt binaries, there is a distinction
between a “runtime” library package (needed for running programs that
use the library) and a corresponding “development” package (needed for
building such programs).

So, for example, looking at the Cairo 2D graphics library, the runtime
package (called “libcairo2”) provides the actual shareable library:

lrwxrwxrwx 1 root root 21 Jan 6 08:05 /usr/lib/x86_64-linux-gnu/libcairo.so.2 -> libcairo.so.2.11800.0
-rw-r--r-- 1 root root 1325768 Jan 6 08:05 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11800.0

while the development package (called “libcairo-dev”) provides the C
include files and other stuff, as well as this additional symlink to
the same shareable library:

lrwxrwxrwx 1 root root 13 Jan 6 08:05 /usr/lib/x86_64-linux-gnu/libcairo.so -> libcairo.so.2

On Wed, 7 Feb 2024 14:21:44 +0000, bart wrote:

> The ones that used to come CDs for you to boot
> on a Windows PC.

Those would be “live CDs”. They might be trying to cater to a wider
audience, of both techy and non techy types.

Normal distro installers can assume the user is non-techy, and set up
defaults accordingly, since the techy ones would know how to ask for more.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 7 Feb 2024 15:02:07 -0000 (UTC), Lew Pitcher wrote:
>
>> LD_LIBRARY_PATH is not a GNUism, but part of the Unix heritage.
>
>This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark to
>the lawyers and those with enough money to pay them. We just get on and do
>our work on “*nix” systems.

That's why 'you' say it. Don't speak for others.

On Wed, 07 Feb 2024 11:10:09 +0000, Ben Bacarisse wrote:

> It's not uncommon to have Linux installs without gcc.

The very first non-Apple PC I bought was a Shuttle small-form-factor unit
that came with a copy of Mandrake 9.1 “Discovery Edition” in the box. (Go
on, look up that name and version. That should give you an idea of how
long ago it was.)

I soon discovered that “Discovery Edition” meant it was lacking the third
CD containing GCC and other development tools. So my first lesson in
hacking my new Linux system was figuring out a) where to find the relevant
packages online, and b) how to download and install them. Preferably by
not having to do so one at a time.

On 07/02/2024 15:21, bart wrote:
> 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?

No, but it is all very easily available. I don't know of any distros
that don't have an easy way to install a C compiler.

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

It is on any Debian-based distros. There are plenty of other package
managers, with different details in their commands (and the names of
packages), which is why I wrote "or equivalent".

On 07/02/2024 16:48, Malcolm McLean wrote:
> On 07/02/2024 15:27, Scott Lurndal wrote:
>> 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 = .;
<snip>
> So what the hell is that? What does it mean? How am i supposed to fix it
> if it goes wrong?

It's all pretty straightforward if you are willing to spend a little
effort learning it.

But you can also consider it as just "under the bonnet magic" that the
compiler and linker know about and get right - that will be fine for the
kind of things you do. (If it were not, then you would already know
about linker scripts.) You don't need to know how /everything/ works in
order to use a tool.

And if you are curious, the binutils ld manual is online.

On Wed, 07 Feb 2024 20:48:56 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Wed, 7 Feb 2024 15:02:07 -0000 (UTC), Lew Pitcher wrote:
>>
>>> LD_LIBRARY_PATH is not a GNUism, but part of the Unix heritage.
>>
>>This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark to
>>the lawyers and those with enough money to pay them. We just get on and
>>do our work on “*nix” systems.
>
> That's why 'you' say it. Don't speak for others.

I certainly wouldn’t speak for those who weren’t even alive when I first
started using a *nix system.

On 07.02.2024 21:36, Lawrence D'Oliveiro wrote:
> On Wed, 7 Feb 2024 15:02:07 -0000 (UTC), Lew Pitcher wrote:
>
>> LD_LIBRARY_PATH is not a GNUism, but part of the Unix heritage.
>
> This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark to
> the lawyers and those with enough money to pay them. We just get on and do
> our work on “*nix” systems.

The trademark is UNIX.

I've since long used "Unix" as a generic name, and meanwhile (for
quite some time now) "Unix" also seems to have got used much more
widely for that; I see it even described in common sources, like
in various Wikipedias.

(Some folks prefer using a '*' in a descriptive name. Feel free.
Not worth a dispute, IMO.)

Janis

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 07 Feb 2024 20:48:56 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>On Wed, 7 Feb 2024 15:02:07 -0000 (UTC), Lew Pitcher wrote:
>>>
>>>> LD_LIBRARY_PATH is not a GNUism, but part of the Unix heritage.
>>>
>>>This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark to
>>>the lawyers and those with enough money to pay them. We just get on and
>>>do our work on “*nix” systems.
>>
>> That's why 'you' say it. Don't speak for others.
>
>I certainly wouldn’t speak for those who weren’t even alive when I first
>started using a *nix system.

I doubt you'll find many of those here. I was using computers in 1974 and unix in 1979.

On Wed, 7 Feb 2024 22:48:52 +0100, Janis Papanagnou wrote:

> I've since long used "Unix" as a generic name ...

Many do. For example, CMake, the build tool we have discussed elsewhere.
As a result of which you see CMake directives like this in some cross-
platform software:

if(UNIX AND NOT APPLE)

Anybody surprised that the one system still in common use that is entitled
to use the “Unix” trademark does not behave sufficiently like that generic
sense you were talking about?

On Wed, 07 Feb 2024 23:15:43 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Wed, 07 Feb 2024 20:48:56 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>>This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark
>>>>to the lawyers and those with enough money to pay them. We just get on
>>>>and do our work on “*nix” systems.
>>>
>>> That's why 'you' say it. Don't speak for others.
>>
>>I certainly wouldn’t speak for those who weren’t even alive when I first
>>started using a *nix system.
>
> I doubt you'll find many of those here. I was using computers in 1974
> and unix in 1979.

With such a long history of being so cavalier about the term, you must
have been cautioned at some point about the legal implications of such
trademark usage. It would have been mentioned in just about every AT&T
publication.

On Wed, 07 Feb 2024 16:30:02 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote in <eeOwN.308695$7sbb.80772@fx16.iad>:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On 07/02/2024 15:27, Scott Lurndal wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>>>>
>
>>>
>>So what the hell is that? What does it mean? How am i supposed to fix it
>>if it goes wrong?
>
> I suspect you've been the internet long enough to have seen the
> phrase RTFM...

He quoted the link to the documentation that Lawrence provided (thank
you, Lawrence).

--
-v

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 07 Feb 2024 23:15:43 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>On Wed, 07 Feb 2024 20:48:56 GMT, Scott Lurndal wrote:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>>>This is why we say “*nix”, not “Unix”. We leave the “Unix” trademark
>>>>>to the lawyers and those with enough money to pay them. We just get on
>>>>>and do our work on “*nix” systems.
>>>>
>>>> That's why 'you' say it. Don't speak for others.
>>>
>>>I certainly wouldn’t speak for those who weren’t even alive when I first
>>>started using a *nix system.
>>
>> I doubt you'll find many of those here. I was using computers in 1974
>> and unix in 1979.
>
>With such a long history of being so cavalier about the term, you must
>have been cautioned at some point about the legal implications of such
>trademark usage. It would have been mentioned in just about every AT&T
>publication.

I spent four years working with the USL engineers directly, and another six
or so years working on the XPG working group. I'm quite aware of the
legal ramifications of the use of the trademark.

None of those ramifications matter in casual usage, such as here in this
newsgroup.