[RPL/2] Error in half-compilation

[BERTRAND Joël]

DEMAINE Benoit-Pierre a écrit :
> BERTRAND Joël wrote:
>> 	Please don't send to mailing list your log files. I think you can 
>> upload these logs on a web site.
> 
> Bot said I was to be moderated, and moderator validated my email.
> 
>> 	Pre8s _should_ work even on gentoo. You are not able to build a regular 
>> pre8s due to a corrupted file created by libtool. It occurs when libtool 
>> crashes (internal error or TERM signal). If you remove 
>> .deps/librpl_la-algebre_lineaire1.conv.Tpo, you can rebuild a pre8s.
> 
> I am not going to maintain deprecated version.
> 
>> 	For pre8w, I suspect a bug in Gentoo build process. I don't have any 
>> gentoo box, only debian/sparc and Solaris/sparc.
> 
> I wrote the process, and we discussed about it long time ago (end 2006 
> from memory). I am waiting for ebuild to be merged with distro (may 
> never happen in facts ...)
> 
> Are you sure you dont get confused version V and W ? from ML, latest 
> version was V, then you proposed a patch, but on mirors I could find W 
> (which was not mentioned in ML). To me, W *is* latest.

	Hardcoded pathes come with pre8v. On which mirror have you find a pre8w 
release ? This release (you can download it on official web site with 
.../download/rpl-4.00pre8w.tar.bz2) is not the final one and I have some 
code to fix. The patch I have sent is not a patch between 8v and 8w, but 
a patch between offical pre8v and _my_ tree (that shall be pre8w) to fix 
a major bug (in STATIC intrinsic).

>> It was a security issue 
>> (code injection) in RPL/2. If you install RPL/2 in /usr and your PATH is 
>> define as /usr/local/bin:/usr/bin, and a user can write on 
>> /usr/local/bin, this user can write its own rplpp (RPL/2 preprocessor). 
>> He can put it in /usr/local/bin, and if a root cron job (for example) 
>> starts a RPL/2 routine, this user can obtain root privileges.
>>
>> 	Thus, path of rplpp is hard coded and defined by d_exec_path. It should 
>> be /usr/local/bin or /usr/bin, not 
>> /var/tmp/portage/doublehp/rpl2-4.0.0.8.0.23/image//usr.
> 
> That was one of the thing we discussed for hours you and me.
> 
> /var/tmp/portage/doublehp/rpl2-4.0.0.8.0.23 is the temp dir for 
> compilation; /image is the target directory (installation path); your 
> make install is told to install there; problem is that (I had the same 
> problem for other programs) you hard code the install dir and assume it 
> will be the execution dir, what is false ... what is ALWAYS false on Gentoo.

	Yes, and ? At this time, I don't have choice because there is no 
portable system call that returns executable path. I have discovered 
this trouble with a user that has another rplpp program (and that is not 
my preprocessor).

> Let's give a non Gentoo example:
> A is big opwerfull AMD64 box, B is small pentium. You may want to use A 
> to comile RPL2, then install it on B; one of the many ways to do it 
> would be to nfsmount B on A; then, the install path when compiling on A 
> would be /mnt/nfs/A/ when runtime path on A would be /
> 
> This story tells you an other case where install path is not runtime path.
> 
> For other apps where I had the problem, developer had to add a new 
> argument to the build process, so that distros and users can 
> differentiate these.
> 
> On Gentoo, the systematical use of a sandbox make compleetely impossible 
> to install the program directly onto / . Thus, on Gentoo, the install 
> dir is ALWAYS different from the execution dir. App installs in 
> /var/tmp/portage/App-kind/APP/image/ then, the distro moves it to / 
> later on, after some verification (testing, eventually scanning against 
> bad linking, virus detection is also possible ...). App is compiled as 
> root, but root from sandbox can not write to / .
> 
> Reading ./configure --help, I discover big ambiguity:
> 
> Installation directories:
>    --prefix=PREFIX         install architecture-independent files in
>                            PREFIX [/usr/local]
>    --exec-prefix=EPREFIX   install architecture-dependent files in
>                            EPREFIX [PREFIX]
> 
> What looks strange to me; I think that you assume install dir will be 
> execution dir, and hardcode PREFIX in libs.

	I know your trouble, but I don't find any portable solution. There are 
some limitations in autoconf/automake that avoid usage of additional 
variables. The better solution is to write a portable function that 
returns the path of executable.

> Can you confirm ?

	Yes, for me, installation path is execution path. I know that this 
assumption is not the better assumption I have made, but I don't know 
how I can send arguments to configure scripts in tools/gnuplot directory 
(for example). If you have an idea, your problem can be quickly solved.

	JKB