Klemens Nanni <[email protected]> wrote:

> On Sat, Dec 18, 2021 at 04:37:17PM +0300, Andrew Krasavin wrote:
> > On Fri, Dec 17, 2021 at 01:04:35PM +0000, Klemens Nanni wrote:
> > > An upcoming port uses ElfW().  I first patched the port, but looking
> > > around shows that both NetBSD and FreeBSD adopted the macro:
> > > 
> > > https://mail-index.netbsd.org/source-changes-hg/2018/07/31/msg027523.html
> > > +#define        ElfW(x)         CONCAT(Elf,CONCAT(ELFSIZE,CONCAT(_,x)))
> > > 
> > > https://cgit.freebsd.org/src/commit/sys/sys/elf_generic.h?id=34e7e4b6a059eee5e4e3e34de5b9d5f0d6e589f9
> > > +/* Define ElfW for compatibility with Linux, prefer __ElfN() in FreeBSD 
> > > code */
> > > +#define  ElfW(x)         __ElfN(x)
> > > 
> > > So I suggest providing it as well.
> > > 
> > > I have yet to put this through a release build on amd64 and/or sparc64
> > > to check if there is any fallout, but I don't suspect there will be.
> > > 
> > > Feedback? Objections? OK (given the build succeeds)?
> > > 
> > > 
> > > Index: sys/sys/exec_elf.h
> > > ===================================================================
> > > RCS file: /cvs/src/sys/sys/exec_elf.h,v
> > > retrieving revision 1.93
> > > diff -u -p -r1.93 exec_elf.h
> > > --- sys/sys/exec_elf.h    7 Dec 2021 22:17:03 -0000       1.93
> > > +++ sys/sys/exec_elf.h    17 Dec 2021 12:36:39 -0000
> > > @@ -725,6 +725,7 @@ struct elf_args {
> > > #define CONCAT(x,y)       __CONCAT(x,y)
> > > #define ELFNAME(x)        CONCAT(elf,CONCAT(ELFSIZE,CONCAT(_,x)))
> > > #define ELFDEFNNAME(x)    CONCAT(ELF,CONCAT(ELFSIZE,CONCAT(_,x)))
> > > +#define ElfW(x)          CONCAT(Elf,CONCAT(ELFSIZE,CONCAT(_,x)))
> > > #endif
> > > 
> > > #if defined(ELFSIZE) && (ELFSIZE == 32)
> > > 
> > 
> > The code that requires this macro in sys/sys/exec_elf.h was
> > eventually removed from the upcoming port (devel/abseil-cpp).
> > 
> > I have no opinion on what you should do with this patch now, but
> > I feel it is necessary to report that this change is no longer
> > needed for my port.
> 
> Even better!
> 
> Unless there are objections, I'll make sure that this doesn't break
> anything and then commit it, so that future ports that do require it
> will build -- there is no downside to providing it, imho.

Why would you commit an unneccessary line to a protected namespace
which doesn't need it?

Reply via email to