2024-11-22 04:29 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000292mercuryBugpublic2013-07-12 01:36
Reporterurilabob 
Assigned Tojuliensf 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionno change required 
PlatformlinuxOSfedoraOS Version19 (kernel 3.9.8
Product Version 
Target VersionFixed in Version 
Summary0000292: 'make install' fails on missing dependency (bryant.h) for robdd.m
DescriptionAttempting to install mercury-srcdist-13.05 fails because the make of robdd.m fails to find bryant.h. Doubtless it's a shell variable not set properly environment or something of that sort - but I haven't been able to figure out what. The final part of the transcript is attached.
Steps To Reproducesh configure
make
make install (which fails)
TagsNo tags attached.
Attached Files
  • txt file icon make_install_transcript.txt (848 bytes) 2013-07-07 01:39 -
    /share/SW/MERCURY/mercury-srcdist-13.05/install_grade_dir.hlc.gc/scripts/mgnuc --grade hlc.gc       --       -c robdd.c -o robdd.o
    robdd.m:436:20: fatal error: bryant.h: No such file or directory
     #include ""bryant.h""
                        ^
    compilation terminated.
    gmake[2]: *** [robdd.o] Error 1
    gmake[2]: Leaving directory `/share/SW/MERCURY/mercury-srcdist-13.05/install_grade_dir.hlc.gc/library'
    To clean up from failed install, remove /share/SW/MERCURY/mercury-srcdist-13.05/install_grade_dir.hlc.gc
    gmake[1]: *** [install_grades] Error 1
    gmake[1]: Leaving directory `/share/SW/MERCURY/mercury-srcdist-13.05'
    make: *** [install] Error 2
    [root@localhost mercury-srcdist-13.05]# cat /proc/version
    Linux version 3.9.8-300.fc19.x86_64 (mockbuild@bkernel02) (gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) ) #1 SMP Thu Jun 27 19:24:23 UTC 2013
    
    txt file icon make_install_transcript.txt (848 bytes) 2013-07-07 01:39 +

-Relationships
+Relationships

-Notes

~0000550

juliensf (administrator)

I've tried doing the above with 13.05 on a newly created VM with Fedora 19 and cannot reproduce
the above problem. Are there any non-default settings in your environment or anything like that?

~0000552

urilabob (reporter)

Hi Julien, thanks for looking at it. I can't think of any environment changes that I am making from the standard one that could possibly affect this. The only non-standard installs I have are JavaBayes, Jess (java expert systems environment), the lptp theorem prover (built on top of swi prolog), and the Vue topic map system. Actually, writing this down made me realise that lptp could have an implementation of robdds that could somehow conflict, but grepping robdd and bryant over it didn't turn up anything. Oh, and I'm using lxde window manager rather than gnome, but it would be pretty weird if there were name clashes there. In case you can see something I can't, I'm appending the printenv output at the bottom.

I thought it might be a hangover from the first failed attempt to build mercury, so I rolled the system back to before the initial mercury install, and tried again. I got exactly the same failure.

The only other thought I have is that the mercury sources are on a folder shared from the host. But I'm running the build as root, and root has full permissions on the folder, so I wouldn't have thought that could make a difference. If you think there's any possibility this could be the cause, I could try moving the source to the guest's root disk, just in case. Other than that, I'm stumped.



XDG_VTNR=1
XDG_SESSION_ID=105
HOSTNAME=localhost.localdomain
SAL_USE_VCLPLUGIN=gtk
IMSETTINGS_INTEGRATE_DESKTOP=yes
XDG_MENU_PREFIX=lxde-
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
GNOME_KEYRING_CONTROL=/home/rim/.cache/keyring-2Jnk7U
QT_GRAPHICSSYSTEM_CHECKED=1
IMSETTINGS_MODULE=none
USER=rim
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
DESKTOP_SESSION=LXDE
MAIL=/var/spool/mail/rim
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/rim/.local/bin:/home/rim/bin
QT_IM_MODULE=xim
PWD=/share/SW/LPTP
XMODIFIERS=@im=none
LANG=en_US.UTF-8
GNOME_KEYRING_PID=6118
HISTCONTROL=ignoredups
divider=10
_LXSESSION_PID=6121
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=3
XDG_SEAT=seat0
HOME=/root
BOOT_IMAGE=/vmlinuz-3.9.8-300.fc19.x86_64
XDG_CONFIG_HOME=/home/rim/.config
LOGNAME=rim
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-0TqbEFGzMQ,guid=9cc6be088e2b649c3aaa305851dd7061
PREFERRED=/usr/bin/startlxde
LESSOPEN=||/usr/bin/lesspipe.sh %s
DISPLAY=:0
XDG_RUNTIME_DIR=/run/user/1000
GTK_IM_MODULE=gtk-im-context-simple
XDG_CURRENT_DESKTOP=LXDE
XAUTHORITY=/root/.xauthZ65N3X
_=/bin/printenv
OLDPWD=/share/SW

~0000553

urilabob (reporter)

Hi again, Julien. Well blow me down, use of the shared folder was the culprit. I copied the sources onto the guest's system disk (from the shared folder, so it wasn't due to file corruption), and it built correctly. I can't even begin to imagine what could cause this, but it's a near certainty that it's a deeply-buried virtualbox bug, rather than one in Mercury. Sorry for taking your time,
    Best Wishes
    Bob

~0000554

juliensf (administrator)

That's ok, my time wasn't wasted since it gave me an opportunity to fix a problem with Mercury and GCC 4.8.
+Notes

-Issue History
Date Modified Username Field Change
2013-07-07 01:39 urilabob New Issue
2013-07-07 01:39 urilabob File Added: make_install_transcript.txt
2013-07-10 13:50 juliensf Note Added: 0000550
2013-07-10 13:50 juliensf Assigned To => juliensf
2013-07-10 13:50 juliensf Status new => feedback
2013-07-11 00:43 urilabob Note Added: 0000552
2013-07-11 00:43 urilabob Status feedback => assigned
2013-07-11 20:45 urilabob Note Added: 0000553
2013-07-12 01:35 juliensf Note Added: 0000554
2013-07-12 01:36 juliensf Status assigned => resolved
2013-07-12 01:36 juliensf Resolution open => no change required
+Issue History