Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Fri, 31 May 2024 16:19:37 +0300
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <20240531161937.000063af@yahoo.com>
References: <v2l828$18v7f$1@dont-email.me>
	<00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
	<v2lji1$1bbcp$1@dont-email.me>
	<87msoh5uh6.fsf@nosuchdomain.example.com>
	<f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
	<v2nbp4$1o9h6$1@dont-email.me>
	<v2ng4n$1p3o2$1@dont-email.me>
	<87y18047jk.fsf@nosuchdomain.example.com>
	<87msoe1xxo.fsf@nosuchdomain.example.com>
	<v2sh19$2rle2$2@dont-email.me>
	<87ikz11osy.fsf@nosuchdomain.example.com>
	<v2v59g$3cr0f$1@dont-email.me>
	<v30l15$3mcj6$1@dont-email.me>
	<v30lls$3mepf$1@dont-email.me>
	<v30sai$3rilf$1@dont-email.me>
	<v320am$1km5$1@dont-email.me>
	<v33ggr$e0ph$1@dont-email.me>
	<v34bne$i85p$1@dont-email.me>
	<v3758s$14hfp$1@raubtier-asyl.eternal-september.org>
	<v38of2$1gsj2$1@dont-email.me>
	<v39v87$1n7bk$1@dont-email.me>
	<20240530170836.00005fa0@yahoo.com>
	<v3a3k5$1ntrn$1@dont-email.me>
	<20240530180345.00003d9f@yahoo.com>
	<v3chc4$27uij$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 31 May 2024 15:19:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="319c9bbb49675ac68434cef6b0b3335d";
	logging-data="2273624"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18huP1t4G8qWl82W2y8CLTy7DtgAqDJkkg="
Cancel-Lock: sha1:AZ4q7jZKeszZzF3fq/5mF9XA7bI=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 5841

On Fri, 31 May 2024 13:55:33 +0100
bart <bc@freeuk.com> wrote:

> On 30/05/2024 16:03, Michael S wrote:
> > On Thu, 30 May 2024 15:48:39 +0100
> > bart <bc@freeuk.com> wrote:
> >   
> >>
> >> Where do the _binary_logo_bmp_start and ...-size symbols come from?
> >> That is, how do they get into the object file.
> >>  
> > 
> > objcopy generates names of the symbols from the name of input binary
> > file. I would think that it is possible to change these symbols to
> > something else, but I am not sure that it is possible withing the
> > same invocation of objcopy. It certainly is possible with a second
> > pass. Lawrence probably can give more authoritative answer.
> > Or as a last resort you can RTFM.
> >   
> I gave myself the simple task of incorporating the source text of 
> hello.c into a program, and printing it out.
> 
> My C program looked like this to start, as an initial test (ignoring 
> declaring the size as an array, unless I had to):
> 
>    #include <stdio.h>
>    typedef unsigned char byte;
> 
>    extern byte _binary_hello_c_start[];
>    extern int _binary_hello_c_size;
> 
>    int main(void) {
>       printf("%d\n", _binary_hello_c_size);
>    }
>

No, it does not work like that.
First, copy *exactly* what I said in my previous post.
Only after you reproduced, start to be smart.
_binary_hello_c_size is a link simbol rather than variable.

Declaration:
extern char _binary_hello_c_size[];

Usage:
  printf("%zd\n", (size_t)_binary_hello_c_size);

> One small matter is those ugly, long identifiers. A bigger one in
> this case is that I really want that embedded text to be zero
> terminated; here it's unlikely to be.
> 

The tool is not made specifically for ASCII strings, it is more generic.
I don't want it zero-terminated, the same as I don't want output of
fread() zero-terminated.  I want it exactly like it is in the
input file.

> However I still have to create the object file with the data. I tried
> this:
> 
>    objcopy -I binary -O pe-x86-64 hello.c hello.obj
> 
> The contents looked about right when I looked inside.
> 
> Now to build my program. Because my C compiler can't link object
> files itself, I have to get it to generate an object file for the
> program, then use an external linker:
> 
>    C:\c>mcc -c c.c  
>    Compiling c.c to c.obj
> 
>    C:\c>gcc c.obj hello.obj  
>    hello.obj: file not recognized: file format not recognized
>    collect2.exe: error: ld returned 1 exit status
> 
> Unfortunately gcc/ld doesn't recognise the output of objcopy. Even 
> though it accepts the output of mcc which is the same COFF format.
> 

It recognizes it if lye to objcopy about format.
Specify elf64-x86-64 instead of pe-x86-64 and everything suddenly
works.
It's all was said in my posts from yesterday. It does not sound like you
had read them.

> But even if it worked, you can see it would be a bit of a palaver.
> 
> Here's how builtin embedding worked using a feature of my older C
> compiler:
> 
>    #include <stdio.h>
>    #include <string.h>
> 
>    char hello[] = strinclude("hello.c");
> 
>    int main(void) {
>        printf("hello =\n%s\n", hello);
>        printf("strlen(hello) = %zu\n", strlen(hello));
>        printf("sizeof(hello) = %zu\n", sizeof(hello));
>    }
> 
> 
> I build it and run it like this:
> 
>    C:\c>bcc c  
>    Compiling c.c to c.exe
> 
>    C:\c>c  
>    hello =
>    #include "stdio.h"
> 
>    int main(void) {
>        printf("Hello, World!\n");
>    }
> 
>    strlen(hello) = 70
>    sizeof(hello) = 71
> 
>    C:\c>dir hello.c  
>    31/05/2024  13:48                70 hello.c
> 
> 
> It just works; no messing about with objcopy parameters; no long 
> unwieldy names; no link errors due to unsupported file formats; no 
> problems with missing terminators for embedded text files imported as 
> strings; no funny ways of getting size info.
>