Project

General

Profile

Bug #7316

Problem when executing #/bin/sh

Added by r a over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-08-21
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

I have been trying to build HandBrake for a while and have now currently built HandBrake 10.5.0 CLI executable on OpenIndiana Hipster.

I traced the build issue to the how the ./configure script is executed during the build of the libvpx library.
The libvpx configure script is set to use #/bin/sh which on OpenIndiana is a symbollic link to sh -> i86/ksh93.
When I temporarily changed this sh to point to /usr/gnu/bin/sh which in turn is a link to /usr/bin/bash the build completes normally.

/tmp/HandBrake-0.10.5$ CC=gcc ./configure --prefix=/opt/gnu --launch

/tmp/HandBrake-0.10.5/build$ ldd /opt/gnu/bin/HandBrakeCLI
libass.so.5 => /usr/lib/libass.so.5
libmp3lame.so.0 => /usr/lib/libmp3lame.so.0
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
libfribidi.so.0 => /usr/lib/libfribidi.so.0
libogg.so.0 => /usr/lib/libogg.so.0
libsamplerate.so.0 => /usr/lib/libsamplerate.so.0
libtheoraenc.so.1 => /usr/lib/libtheoraenc.so.1
libtheoradec.so.1 => /usr/lib/libtheoradec.so.1
libvorbis.so.0 => /usr/lib/libvorbis.so.0
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2
libx264.so.144 => /usr/lib/libx264.so.144
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libxml2.so.2 => /usr/lib/libxml2.so.2
libbz2.so.1 => /usr/lib/libbz2.so.1
libz.so.1 => /usr/lib/libz.so.1
libpthread.so.1 => /lib/libpthread.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
libexpat.so.1 => /usr/lib/libexpat.so.1
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpng16.so.16 => /usr/lib/libpng16.so.16
liblzma.so.5 => /usr/lib/liblzma.so.5
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3

Does a rationalisation of shells need to implemented so that /bin/sh points to /bin/bash not ksh?

#1

Updated by Aurélien Larcher over 4 years ago

No, the problem is using bash as /usr/bin/sh: system shell should assumed to be just POSIX compliant.
Any replacement of ksh93 (dash, bosh) will suffer from the same issue.
The problem is the configuration script making incorrect assumptions, not the system shell.

#2

Updated by Aurélien Larcher over 4 years ago

  • Status changed from New to Closed

Also please note that Debian for instance moved away from bash as default shell for poor compatibility and performance reasons.

Also available in: Atom PDF