Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Sjoerd Simons <sjoerd@debian.org>]

On Mon, 2020-01-06 at 16:58 +0000, Anton Ivanov wrote:
> 
> On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:
> > Control: tag -1 +help
> > 
> > On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> > > On my sid system:
> > > ```
> > > $ strings /usr/bin/linux.uml | grep port-helper
> > > /usr/lib//uml/port-helper
> > > ```
> > > 
> > > So the path is still incorrect even with newer upstream kernels.
> > 
> > I spent some time today looking at the new build but I haven't been
> > able to ascertain why this isn't setting the correct path.
> 
> It is used in a "user" side file - xterm.c
> 
> None of these sees "CONFIG_" so it considers it undef-ed which
> defaults 
> to 32 bit.

Is there any reason why the port helper is in the weird `/usr/lib64`
that seems more like a redhat-ism; On Debian if it's proper multi arch
under `/usr/lib/x86_64-linux-gnu/`..

However uml-utilities can't be installed for multiple architectures on
one system anyway (as it ships binaries). So there is little point in
try to being multi-arch-like (or just awkward :p)...

So to me the most practical and straight-forward solution would
probably be to revert the broken kernel patch and change the uml-
utilities package instead to always install in a single spot.

> You need to use some other way to figure out what is the build or to
> set 
> OS_LIB_PATH for this case.
> 
> > ```
> > $ strings `which  linux.uml` | grep port-helper
> > /usr/lib/uml/port-helper
> > ```
> > 
> > First, for context to the readers here, the port-helper binary is
> > shipped with uml-utilities package. This package, depending on the
> > architecture, installs the binary to a architecture specific
> > location.
> > 
> > https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10
> > 
> > Which on an amd64 machine is: /usr/lib64/uml/port-helper
> > 
> > ```
> > $ dpkg  -S /usr/lib64/uml/port-helper
> > uml-utilities: /usr/lib64/uml/port-helper
> > ```
> > 
> > The UML setup on my box always worked because long back, when I
> > first
> > encountered this problem, I had created a symlink of the path to
> > /usr/lib/ too. And had completely forgotten about it. My apologies.
> > 
> > 
> > But that said, the current problem is with the UML binary built by
> > the
> > kernel sources.
> > Problem is that, as mentioned above and other reports too on this
> > bug
> > report thread, the path resolved at build time is always
> > "/usr/lib/uml/".
> > 
> > The build configuration and the code are all correct.
> > 
> > ```
> > $ grep 64BIT .config
> > CONFIG_64BIT=y
> > CONFIG_64BIT_TIME=y
> > CONFIG_PHYS_ADDR_T_64BIT=y
> > CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> > ```
> > 
> > 
> > Snipped from: arch/um/include/shared/os.h
> > 
> > ```
> > #ifdef CONFIG_64BIT
> > #define OS_LIB_PATH     "/usr/lib64/"
> > #else
> > #define OS_LIB_PATH     "/usr/lib/"
> > #endif
> > ```
> > 
> > I also checked the generated include headers and they are correct
> > for
> > the amd64 .config file.
> > 
> > ```
> > linux-source-5.4/include/generated$ grep 64BIT autoconf.h
> > #define CONFIG_64BIT_TIME 1
> > #define CONFIG_PHYS_ADDR_T_64BIT 1
> > #define CONFIG_64BIT 1
> > #define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
> > ```
> > 
> > I'll keep looking as time permits but if anyone else has ideas on
> > what
> > I may be doing wrong, please do mention.
> > 
> > Thanks,
> > Ritesh
> > 
> > 
> > _______________________________________________
> > linux-um mailing list
> > linux-um@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-um
> > 

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um