Re: backupfile and backup-rename are introducing the same object to make

[(GalaxyMaster)]

Bruno,

On Wed, Jan 25, 2023 at 06:53:57PM +0100, Bruno Haible wrote:
> Hi,
> 
> (GalaxyMaster) wrote:
> > backup-replace
> You mean 'backup-rename', right?

Yeah, it was a typo, it was in the middle of the night and my brain was not
working efficiently.

> > I just stumbled upon the following: when I include both backupfile and
> > backup-replace modules I am getting a broken build due to multiple 
> > definitions
> > of "simple_backup_suffix'.
> 
> This is not expected, because usually the .o files are collected in a .a file,
> from which one of the two backupfile.o will be picked, and it does not matter
> which one since they are identical.

This makes sense.  My use case in not standard since I am actually building
these into a shared library using libtool, so libtool sees the same object file
listed twice and tries to resolve it by renaming one of them and then includes
both in the resulting link command to produce a shared object.  The linker
rightfully complains about duplicates.  Anyway, I think my use case is out of
scope for this project, but the reason why I reported it was that it just does
not look tidy to have two modules claiming ownership of the same files and
including the same configuration to configure.ac/Makefile.am files.

For my project, I am just patching backup-rename module's definition to only
include parts that are different from backupfile and I also made a dependency
on backupfile.

> Please describe your situation:
>   - operating system?

I am building a Linux distribution from ground up.

>   - building what kind of library or binary in which way?

I am basically building what is directly against GNU Lib's philosophy (section
2.2 of the manual), a shared library containing every single compilable module
with all functions defined as weak symbols.  The resulting shared library then
also stripped of all DT_NEEDED sections except for the system libc one, so that
it does not have lots of dependencies (and with weak symbols it is usable in
parts even if the dependencies are not met as long as the corresponding
functions are not called).

I clearly understand that my use case is not something supported or endorsed by
the GNU Lib project and am not trying to change that, but it is another avenue
to test stuff, which may be valueable to the project.

>   - which compiler: $CC = ? $CFLAGS = ? $CPPFLAGS = ? $LDFLAGS = ?
>   - which linker is being used by the compiler?,

I am not sure this would be helpful, since as I described my use case is
definitely not something GNU Lib supports, but for the context purposes: the
system is musl based with GCC as the primary compiler.

So, as you wrote in your message, I think there is no bug and the way how these
two modules are currently set up is fine (unless one does something
non-standard like myself).  However, I would argue that it would still be nicer
not to polute project's build files with duplicate entries if possible, but
this is up to you of course.

-- 
(GM)