Re: make & LD_LIBRARY_PATH

[Marko Mikulicic]

Adam Fedor wrote:
> Nicola Pero wrote:
>
> > > Hello,
> > >
> > > I noticed a little problem with the propagation of LD_LIBRARY_PATH
> > > in gnustep build system.
> > >
> > > For example, Finger.app:
> > >
> > > # make
> > >
> > > Making all for app Finger...
> > > plmerge: error while loading shared libraries: libgnustep-base.so.1: 
> > > cannot open shared object file: No such file or directory
> > > make[1]: *** [Finger.app/Resources/Info-gnustep.plist] Error 127
> > > make: *** [Finger.all.app.variables] Error 2
> > >
> > > $ echo $LD_LIBRARY_PATH
> > > /root/GNUstep/Libraries/ix86/linux-gnu/gnu-gnu-gnu:/root/GNUstep/Libraries/ix86/linux-gnu:/usr/GNUstep/Local/Libraries/ix86/linux-gnu/gnu-gnu-gnu:/usr/GNUstep/Local/Libraries/ix86/linux-gnu:/usr/GNUstep/Network/Libraries/ix86/linux-gnu/gnu-gnu-gnu:/usr/GNUstep/Network/Libraries/ix86/linux-gnu:/usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu:/usr/GNUstep/System/Libraries/ix86/linux-gnu 
> > >
> > >
> > > but when I do:
> > >
> > > # make LD_LIBRARY_PATH=$LD_LIBRARY_PATH
> > > Making all for app Finger...
> > >  Copying resources into the app wrapper...
> > >
> > > the same problem is running make_services making gnustep-gui 
> > > (example.service, ... in Tools subdir)
> > >
> > > I use gnu make 3.79.1 on gentoo linux. gnustep CVS updated up to time 
> > > of writing.
> >
> >
> >
> > Hmm.
> >
> > Have you checked that the permissions on your make program are correct ?
> >
> > It looks a lot like your 'make' program has the setuid bit set, which
> > would not be good. :-)

yes, you are right. it has setgid bit set on group kmem

> This is/could actually be a bug in make, or rather an autoconf script 
> that make uses. On some systems it mistakenly convinces make that it 
> should be a setgid program. I should have submitted a patch for this, 
> but I've never gotten around to it. Although I did report it on 
> bug-make, so perhaps someone has fixed it.

It seems that make on some systems needs sgid kmem to access /dev/kmem 
to obtain the system load for option -l. On linux it can be obtained 
from /proc/loadavg so I don't see the problem.


Marko