Prev: anacron and user crontabs
Next: HPSBUX02523 SSRT100036 rev.1 - HP-UX Running ONCPlus, Remote Denial of Service (DoS), Increase in Privilege
From: Sam on 26 May 2010 18:11
Kenny McCormack writes:

> I re-did the build after "installing" ncurses (scare quotes added - see
> below), and this time it all went smoothly.
>
> However, the experience has revealed two flaws in the automake/configure
> process:
> 1) configure should fail if it can't find something it needs.
> I.e., if configure succeeds (as it does here), then it should be
> pretty darn close to certain that the compile/link/build will
> succeed (absent something catastrophic like a hard disk crash).

This is not a flaw in "the automake/configure process". It's up to the
developer to specify what action to take place if a given library is not
found by the configure script. The configure script can continue to run,
perhaps adopting some default alternate configuration, or it can bomb out.

> 2) I did not do the usual "make install" with ncurses. Rather, I
> simply copied the libncurses.a file to /usr/lib. That was the
> only way I could get it to work. The point is that I am doing
> this compile as a non-root user. I should not have to go root
> (or sudo, which is the same thing) to get a library into a
> position where configure can find it.

1) --prefix and/or --exec-prefix options to configure

2) make install DESTDIR=/somewhere

The two are not equivalent, and carry certain important differences, and
their semantics are largely dependent on how the developer coded the
configure script and the makefile. When in doubt, RTFM configure.(in|ac) and
Makefile.am, and see what it does.

> One of the fundamental
> assumptions of Unix/GNU free software is that you can, if you
> want to, compile and use stuff w/o being root on the machine (as
> long as the admin hasn't de-permitted the C compiler...)

Every one of the thousands of packages that comprise the Fedora distribution
was built in a chroot jail by a non-root userid, without exception.

>
> Note on 2) above:
> I tried the --libdir=DIR option on the configure command, to get
> it to look there for the library - that didn't work. I also
> tried doing: LDFLAGS=-LDIR ./configure; that didn't work either.
> Looking at the configure script, I think that I could hack the
> place where they set LDFLAGS, but I didn't try that.

You, perhaps, should've hacked the makefile, instead.

From: Dave Gibson on 26 May 2010 18:24
Kenny McCormack <gazelle(a)shell.xmission.com> wrote:

[ compiling vim, system has few libraries installed ]

> I re-did the build after "installing" ncurses (scare quotes added - see
> below), and this time it all went smoothly.

> 2) I did not do the usual "make install" with ncurses. Rather, I
> simply copied the libncurses.a file to /usr/lib. That was the
> only way I could get it to work. The point is that I am doing
> this compile as a non-root user.

It should be possible to install ncurses as a user by configuring it
with --prefix naming a writable directory.

> I also tried doing: LDFLAGS=-LDIR ./configure; that didn't work either.

Was that something like "LDFLAGS=-L/full/path/to/ncurses-5.7/lib" or
"LDFLAGS=-L../ncurses-5.7/lib"? Vim's configure changes directory
then execs another script so relative paths are unlikely to work.
First  |  Prev  | 
Pages: 1 2
Prev: anacron and user crontabs
Next: HPSBUX02523 SSRT100036 rev.1 - HP-UX Running ONCPlus, Remote Denial of Service (DoS), Increase in Privilege