Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: 
Sent: Monday, August 29, 2016 3:58 PM
Subject: Re: GUB problem



Thank you for your answers.
Is there
/home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
?
Would you show me config.log in gmp-6.0.0.a ?


As far as I can see, that file does not exist on my system.

Would you show me result of the following commands?
$ cat /proc/cpuinfo
$ cd /home/gub/NewGub/gub/target/tools
$ find . -name "config.log"


gub@gub-VirtualBox:~$ cd NewGub/gub/target/tools/
gub@gub-VirtualBox:~/NewGub/gub/target/tools$ find . -name
"config.log"
./build/gmp-6.0.0.a/config.log



I have attached config.log and the output of cpuinfo.


Thank you for your files.

If I understand correctly,
my environment and your environment difference is found.
I'm making a patch for GUB.

In my 32 bit VM,

/proc/cpuinfo flags has `lm' (long mode).
So GUB sets build_hardware_bits=64.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L230

And, GUB sets build_bits=32 because the OS is 32 bit.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L65

Thus, build_bits != build_hardware_bits.
So GUB sets environment variable ABI=32.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L243

GMP's configure script detects the 64 bit capable CPU but ABI=32 is set.
So the GMP building succeed.


On the other hands,
in your 32 bit VM,

/proc/cpuinfo flags does not have `lm' (long mode).
Ofcource, your CPU is 64 bit capable.
It originally would have the flag.
Perhaps virtualization software drops the flag.
So GUB sets build_hardware_bits=32.

Thus, build_bits == build_hardware_bits.
So GUB does not set environment variable ABI.

GMP's configure script detects the 64 bit capable CPU
because it uses CPUID instead of `/proc/cpuinfo'.
Then, it try to use 64 bit but it cannot use 64 bit because the OS is 32 
bit.


I've created pull request.
https://github.com/gperciva/gub/pull/28



I've accepted the request, merged it, and Gub is compiling.  GMP appears to 
have compiled OK, so it looks like your patch fixed this problem.


Please accept my continued thanks for your help supporting LilyPond's build.

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

> Thank you for your answers.
> Is there
> /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
> ?
> Would you show me config.log in gmp-6.0.0.a ?
>
 As far as I can see, that file does not exist on my system.
>>> Would you show me result of the following commands?
>>> $ cat /proc/cpuinfo
>>> $ cd /home/gub/NewGub/gub/target/tools
>>> $ find . -name "config.log"
>> 
>> gub@gub-VirtualBox:~$ cd NewGub/gub/target/tools/
>> gub@gub-VirtualBox:~/NewGub/gub/target/tools$ find . -name
>> "config.log"
>> ./build/gmp-6.0.0.a/config.log
>> 
>> 
>> 
>> I have attached config.log and the output of cpuinfo.
> 
> Thank you for your files.
> 
> If I understand correctly,
> my environment and your environment difference is found.
> I'm making a patch for GUB.
> 
> In my 32 bit VM,
> 
> /proc/cpuinfo flags has `lm' (long mode).
> So GUB sets build_hardware_bits=64.
> https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L230
> 
> And, GUB sets build_bits=32 because the OS is 32 bit.
> https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L65
> 
> Thus, build_bits != build_hardware_bits.
> So GUB sets environment variable ABI=32.
> https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L243
> 
> GMP's configure script detects the 64 bit capable CPU but ABI=32 is set.
> So the GMP building succeed.
> 
> 
> On the other hands,
> in your 32 bit VM,
> 
> /proc/cpuinfo flags does not have `lm' (long mode).
> Ofcource, your CPU is 64 bit capable.
> It originally would have the flag.
> Perhaps virtualization software drops the flag.
> So GUB sets build_hardware_bits=32.
> 
> Thus, build_bits == build_hardware_bits.
> So GUB does not set environment variable ABI.
> 
> GMP's configure script detects the 64 bit capable CPU
> because it uses CPUID instead of `/proc/cpuinfo'.
> Then, it try to use 64 bit but it cannot use 64 bit because the OS is 32 bit.

I've created pull request.
https://github.com/gperciva/gub/pull/28

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

 Thank you for your answers.
 Is there
 /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
 ?
 Would you show me config.log in gmp-6.0.0.a ?

>>> As far as I can see, that file does not exist on my system.
>> Would you show me result of the following commands?
>> $ cat /proc/cpuinfo
>> $ cd /home/gub/NewGub/gub/target/tools
>> $ find . -name "config.log"
> 
> gub@gub-VirtualBox:~$ cd NewGub/gub/target/tools/
> gub@gub-VirtualBox:~/NewGub/gub/target/tools$ find . -name
> "config.log"
> ./build/gmp-6.0.0.a/config.log
> 
> 
> 
> I have attached config.log and the output of cpuinfo.

Thank you for your files.

If I understand correctly,
my environment and your environment difference is found.
I'm making a patch for GUB.

In my 32 bit VM,

/proc/cpuinfo flags has `lm' (long mode).
So GUB sets build_hardware_bits=64.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L230

And, GUB sets build_bits=32 because the OS is 32 bit.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L65

Thus, build_bits != build_hardware_bits.
So GUB sets environment variable ABI=32.
https://github.com/gperciva/gub/blob/7e12e0ab779b11db32b471875ab31d93aabb7f7d/gub/settings.py#L243

GMP's configure script detects the 64 bit capable CPU but ABI=32 is set.
So the GMP building succeed.


On the other hands,
in your 32 bit VM,

/proc/cpuinfo flags does not have `lm' (long mode).
Ofcource, your CPU is 64 bit capable.
It originally would have the flag.
Perhaps virtualization software drops the flag.
So GUB sets build_hardware_bits=32.

Thus, build_bits == build_hardware_bits.
So GUB does not set environment variable ABI.

GMP's configure script detects the 64 bit capable CPU
because it uses CPUID instead of `/proc/cpuinfo'.
Then, it try to use 64 bit but it cannot use 64 bit because the OS is 32 bit.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

>>> Would you show me the following log files?
>>>
>>> /home/gub/NewGub/gub/target/tools/log/gmp.log
>>> /home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/config.log
> 
> 
> Sorry - forgot to say.  gmp-6.0.0.a/config.log is not present on my
> system. The directory is there but no file of that name.

Thank you for your answers.

Is there
/home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
?

Would you show me config.log in gmp-6.0.0.a ?

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: "Masamichi Hosoda" 
Cc: ; 
Sent: Sunday, August 28, 2016 3:26 PM
Subject: Re: GUB problem


- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Sunday, August 28, 2016 2:48 PM
Subject: Re: GUB problem



Would you show me the following log files?

/home/gub/NewGub/gub/target/tools/log/gmp.log
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/config.log



Sorry - forgot to say.  gmp-6.0.0.a/config.log is not present on my system. 
The directory is there but no file of that name.


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Sunday, August 28, 2016 2:48 PM
Subject: Re: GUB problem



I get the following:

checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
Command barfed: cd /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a
&& chmod +x
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure && sh
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure
--prefix=/home/gub/NewGub/gub/target/tools/root/usr --enable-shared
--enable-static --disable-silent-rules
CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include
LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath
-Wl,\$$ORIGIN/../lib -Wl,-rpath
-Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib '
CPPFLAGS=-D_GNU_SOURCE


Did you delete target/ ?


Yes.


Would you show me the following log files?

/home/gub/NewGub/gub/target/tools/log/gmp.log
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/config.log

Would you show me the result of the follwing commands?

$ cd /home/gub/NewGub/gub
$ git status
$ git diff
$ git log -5
$ env


All attached as text files.

--
Phil Holmes
XDG_VTNR=7
XDG_SESSION_ID=c2
CLUTTER_IM_MODULE=xim
SELINUX_INIT=YES
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/gub
SESSION=ubuntu
GPG_AGENT_INFO=/run/user/1000/keyring-EIO1Sz/gpg:0:1
TERM=xterm
SHELL=/bin/bash
XDG_MENU_PREFIX=gnome-
VTE_VERSION=3409
WINDOWID=39845899
UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/1626
GNOME_KEYRING_CONTROL=/run/user/1000/keyring-EIO1Sz
GTK_MODULES=overlay-scrollbar:unity-gtk-module
USER=gub
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: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:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=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:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=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:*.webm=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=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
SSH_AUTH_SOCK=/run/user/1000/keyring-EIO1Sz/ssh
SESSION_MANAGER=local/gub-VirtualBox:@/tmp/.ICE-unix/1843,unix/gub-VirtualBox:/tmp/.ICE-unix/1843
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
DESKTOP_SESSION=ubuntu
QT_IM_MODULE=ibus
QT_QPA_PLATFORMTHEME=appmenu-qt5
JOB=dbus
PWD=/home/gub/NewGub/gub
XMODIFIERS=@im=ibus
GNOME_KEYRING_PID=1624
LANG=en_GB.UTF-8
GDM_LANG=en_GB
MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
IM_CONFIG_PHASE=1
COMPIZ_CONFIG_PROFILE=ubuntu
GDMSESSION=ubuntu
SESSIONTYPE=gnome-session
XDG_SEAT=seat0
HOME=/home/gub
SHLVL=1
LANGUAGE=en_GB:en
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LOGNAME=gub
COMPIZ_BIN_PATH=/usr/bin/
XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
QT4_IM_MODULE=xim
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-wCVQhtGagj
LESSOPEN=| /usr/bin/lesspipe %s
INSTANCE=
TEXTDOMAIN=im-config
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=:0
XDG_CURRENT_DESKTOP=Unity
GTK_IM_MODULE=ibus
LESSCLOSE=/usr/bin/lesspipe %s %s
TEXTDOMAINDIR=/usr/share/locale/
COLORTERM=gnome-terminal
XAUTHORITY=/home/gub/.Xauthority
OLDPWD=/home/gub/NewGub
_=/usr/bin/env

commit 7e12e0ab779b11db32b471875ab31d93aabb7f7d
Merge: 4a078de 283a7e8
Author: PhilHolmes 
Date:   Sat Aug 13 13:42:09 2016 +0100

   Merge pull request #27 from trueroad/fix-librestrict-c99
   
   Fix librestrict C99 and update some libraries


commit 283a7e88e0330478063230ae7f7544c8ffe11480
Author: Masamichi Hosoda 
Date:   Tue Aug 9 19:46:04 2016 +0900

   Fix libffi include directory
   
   Reported:

   http://lists.gnu.org/archive/htm

Re: GUB problem

[Masamichi Hosoda]

> I get the following:
> 
> checking size of mp_limb_t... 4
> configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
> in this configuration expects 64 bits.
> You appear to have set $CFLAGS, perhaps you also need to tell GMP the
> intended ABI, see "ABI and ISA" in the manual.
> Command barfed: cd /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a
> && chmod +x
> /home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure && sh
> /home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure
> --prefix=/home/gub/NewGub/gub/target/tools/root/usr --enable-shared
> --enable-static --disable-silent-rules
> CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include
> LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath
> -Wl,\$$ORIGIN/../lib -Wl,-rpath
> -Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib '
> CPPFLAGS=-D_GNU_SOURCE

Did you delete target/ ?

Would you show me the following log files?

/home/gub/NewGub/gub/target/tools/log/gmp.log
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/config.log

Would you show me the result of the follwing commands?

$ cd /home/gub/NewGub/gub
$ git status
$ git diff
$ git log -5
$ env

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Friday, August 26, 2016 4:43 PM
Subject: Re: GUB problem



I'd like to suggest deleting `target/` such as in the GUB's basic
document.
But, after you delete it, GUB's full build takes a long long time.



Yes, I know :-(

Should I revert my ABI change before trying the rebuild?


Yes, please.



I get the following:

checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
Command barfed: cd /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a && 
chmod +x /home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure && sh 
/home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/configure --prefix=/home/gub/NewGub/gub/target/tools/root/usr 
--enable-shared --enable-static --disable-silent-rules 
CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include 
LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath -Wl,\$$ORIGIN/../lib 
-Wl,-rpath -Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib ' 
CPPFLAGS=-D_GNU_SOURCE





--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

>> I'd like to suggest deleting `target/` such as in the GUB's basic
>> document.
>> But, after you delete it, GUB's full build takes a long long time.
>>
> 
> Yes, I know :-(
> 
> Should I revert my ABI change before trying the rebuild?

Yes, please.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Friday, August 26, 2016 4:02 PM
Subject: Re: GUB problem



GUB's basic document
https://github.com/gperciva/gub/blob/master/web/basics.html
says

```
   SHARING DIRECTORIES

   GUB uses an ABI environment variable to work around some build
   bugs in some packages.  This variable is not checked by the
   environment-changed function, so problems will probably occur if
   you share your GUB build directory between a 32-bit and 64-bit OS.
   If you change your operating system, delete the target/ directory
   of GUB before trying to build it again.



I think this is quite a difficult one to answer.

My main machine was (IIRC) 64 bit originally - that's partly why I
used a VM for GUB, since GUB used not to work in a 64 bit environment.
When I upgraded from Ubuntu 10.04, via 12 to 14.04, the machine became
32 bit, since I selected that option because it seemed that the 64 bit
was not deigned for Intel CPUs.  I think I may have misunderstood
that, but whatever the reason, I now run a 32 bit main machine.  As
part of the move to Ubuntu 14, I needed to upgrade the Oracle VM
software, but did not change the VM spec at all.  So I think the
answer is that the actual VM disk has never seen a 64 bit environment,
but has run within a 64 bit environment.


Thank you for your answer.

I'd like to suggest deleting `target/` such as in the GUB's basic 
document.

But, after you delete it, GUB's full build takes a long long time.



Yes, I know :-(

Should I revert my ABI change before trying the rebuild?

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

>> GUB's basic document
>> https://github.com/gperciva/gub/blob/master/web/basics.html
>> says
>>
>> ```
>>SHARING DIRECTORIES
>>
>>GUB uses an ABI environment variable to work around some build
>>bugs in some packages.  This variable is not checked by the
>>environment-changed function, so problems will probably occur if
>>you share your GUB build directory between a 32-bit and 64-bit OS.
>>If you change your operating system, delete the target/ directory
>>of GUB before trying to build it again.
> 
> 
> I think this is quite a difficult one to answer.
> 
> My main machine was (IIRC) 64 bit originally - that's partly why I
> used a VM for GUB, since GUB used not to work in a 64 bit environment.
> When I upgraded from Ubuntu 10.04, via 12 to 14.04, the machine became
> 32 bit, since I selected that option because it seemed that the 64 bit
> was not deigned for Intel CPUs.  I think I may have misunderstood
> that, but whatever the reason, I now run a 32 bit main machine.  As
> part of the move to Ubuntu 14, I needed to upgrade the Oracle VM
> software, but did not change the VM spec at all.  So I think the
> answer is that the actual VM disk has never seen a 64 bit environment,
> but has run within a 64 bit environment.

Thank you for your answer.

I'd like to suggest deleting `target/` such as in the GUB's basic document.
But, after you delete it, GUB's full build takes a long long time.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Wednesday, August 24, 2016 2:37 PM
Subject: Re: GUB problem



Apologies for the delay in replying.  I knew it would take me a little
time to gather the information you needed, so had to wait for some
free time. Responses are below.


Thank you very much.

I suspect that environment variable ABI problem.

Have you ever mounted the disk to 64 bit OS?
Have you changed virtualization software?

GUB's basic document
https://github.com/gperciva/gub/blob/master/web/basics.html
says

```
   SHARING DIRECTORIES

   GUB uses an ABI environment variable to work around some build
   bugs in some packages.  This variable is not checked by the
   environment-changed function, so problems will probably occur if
   you share your GUB build directory between a 32-bit and 64-bit OS.
   If you change your operating system, delete the target/ directory
   of GUB before trying to build it again.



I think this is quite a difficult one to answer.

My main machine was (IIRC) 64 bit originally - that's partly why I used a VM 
for GUB, since GUB used not to work in a 64 bit environment.  When I 
upgraded from Ubuntu 10.04, via 12 to 14.04, the machine became 32 bit, 
since I selected that option because it seemed that the 64 bit was not 
deigned for Intel CPUs.  I think I may have misunderstood that, but whatever 
the reason, I now run a 32 bit main machine.  As part of the move to Ubuntu 
14, I needed to upgrade the Oracle VM software, but did not change the VM 
spec at all.  So I think the answer is that the actual VM disk has never 
seen a 64 bit environment, but has run within a 64 bit environment.


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

> Apologies for the delay in replying.  I knew it would take me a little
> time to gather the information you needed, so had to wait for some
> free time. Responses are below.

Thank you very much.

I suspect that environment variable ABI problem.

Have you ever mounted the disk to 64 bit OS?
Have you changed virtualization software?

GUB's basic document
https://github.com/gperciva/gub/blob/master/web/basics.html
says

```
SHARING DIRECTORIES

GUB uses an ABI environment variable to work around some build
bugs in some packages.  This variable is not checked by the
environment-changed function, so problems will probably occur if
you share your GUB build directory between a 32-bit and 64-bit OS.
If you change your operating system, delete the target/ directory
of GUB before trying to build it again.
```

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

>>> FYI I had to make a small change to the GMP spec to accommodate 32 bit
>>> - my patch shows what I had to do.
>>
>> If you don't use the patch, do any errors occur?
> 
> Yes:  the terminal output has this:
> 
> Tail of target/tools/log/gmp.log 
> in this configuration expects 64 bits.
> You appear to have set $CFLAGS, perhaps you also need to tell GMP the
> intended ABI, see "ABI and ISA" in the manual.

I've prepared Ubuntu 14.04 LTS 32 bit VM.
In the environment, I've succeed GMP compiling without your patch.

Would you show me the whole log file target/tools/log/gmp.log?

>> $ LIBRESTRICT_ALLOW=/ bin/gub --fresh freebsd-64::fontconfig
> 
> Do I issue that command and then restart the GUB compile?

No.
If I understand correctly, that command will fail.
I'd like to see config.log error message.

In addition, I've succeed freebsd-64::fontconfig compiling
in my Ubuntu 32 bit VM.
I'd like to investigate what is different between
my environment and your environment.

Would you show me the result of the following command?

$ uname -a
$ uname -m
$ uname -p
$ uname -i
$ dpkg -l

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: ; 
Sent: Monday, August 15, 2016 4:51 PM
Subject: Re: GUB problem



In my environment (Ubuntu 14.04 LTS 64 bit), the error does not occur.
Would you tell me the environment which the error occurs?


Ubuntu 14.04 LTS 32 bit.

FYI I had to make a small change to the GMP spec to accommodate 32 bit
- my patch shows what I had to do.


If you don't use the patch, do any errors occur?


Yes:  the terminal output has this:

Tail of target/tools/log/gmp.log >>>>>>>>
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.





Anyway, this error means that
cross-compiler gcc (for freebsd-64) tries to open "librestrict.so".

"librestrict.so" is for host OS (perhaps Linux)
instead of for target OS (freebsd-64).

If I understand correctly,
cross-compiler gcc does not need to open "librestrict.so".
I don't know why cross-compiler gcc tries to open "librestrict.so".

Moreover, at least a few weeks ago, the error did not occur.
My recent pull request does not change gcc.
I wonder why cross-compiler gcc began to open "librestrict.so".


Perhaps your fix to librestrict made something work that was not
previously, and so an error is now detected?


I've noticed that this librestrict-error is secondary-effect.

If I understand correctly,
the first error is

x86_64-freebsd6-gcc: internal compiler error: Illegal instruction 
(program cc1)


Then, gcc tried to open "librestrict.so" for showing debugging 
information.

So secondary-effect librestrict-error was occured.

To confirm this hypothesis,
would you try the following command and show me the result (config.log 
etc.)?


$ LIBRESTRICT_ALLOW=/ bin/gub --fresh freebsd-64::fontconfig


Do I issue that command and then restart the GUB compile?

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

>> In my environment (Ubuntu 14.04 LTS 64 bit), the error does not occur.
>> Would you tell me the environment which the error occurs?
> 
> Ubuntu 14.04 LTS 32 bit.
>
> FYI I had to make a small change to the GMP spec to accommodate 32 bit
> - my patch shows what I had to do.

If you don't use the patch, do any errors occur?

>> Anyway, this error means that
>> cross-compiler gcc (for freebsd-64) tries to open "librestrict.so".
>>
>> "librestrict.so" is for host OS (perhaps Linux)
>> instead of for target OS (freebsd-64).
>>
>> If I understand correctly,
>> cross-compiler gcc does not need to open "librestrict.so".
>> I don't know why cross-compiler gcc tries to open "librestrict.so".
>>
>> Moreover, at least a few weeks ago, the error did not occur.
>> My recent pull request does not change gcc.
>> I wonder why cross-compiler gcc began to open "librestrict.so".
> 
> Perhaps your fix to librestrict made something work that was not
> previously, and so an error is now detected?

I've noticed that this librestrict-error is secondary-effect.

If I understand correctly,
the first error is

> x86_64-freebsd6-gcc: internal compiler error: Illegal instruction (program 
> cc1)

Then, gcc tried to open "librestrict.so" for showing debugging information.
So secondary-effect librestrict-error was occured.

To confirm this hypothesis,
would you try the following command and show me the result (config.log etc.)?

$ LIBRESTRICT_ALLOW=/ bin/gub --fresh freebsd-64::fontconfig

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" 

To: ; 
Cc: 
Sent: Monday, August 15, 2016 1:57 PM
Subject: Re: GUB problem



configure:3706: checking whether the C compiler works
configure:3728: x86_64-freebsd6-gcc conftest.c  >&5
x86_64-freebsd6-gcc: internal compiler error: Illegal instruction 
(program cc1)
librestrict:error:/home/gub/NewGub/gub/target/freebsd-64/root/usr/cross/bin/x86_64-freebsd6-gcc: 
tried to open () file 
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so

librestrict:allowed:
  /home/gub/NewGub/gub/target/freebsd-64
  /tmp
  /dev/null
  /dev/urandom
  /proc/self


In my environment (Ubuntu 14.04 LTS 64 bit), the error does not occur.
Would you tell me the environment which the error occurs?


Ubuntu 14.04 LTS 32 bit.

FYI I had to make a small change to the GMP spec to accommodate 32 bit - my 
patch shows what I had to do.



Anyway, this error means that
cross-compiler gcc (for freebsd-64) tries to open "librestrict.so".

"librestrict.so" is for host OS (perhaps Linux)
instead of for target OS (freebsd-64).

If I understand correctly,
cross-compiler gcc does not need to open "librestrict.so".
I don't know why cross-compiler gcc tries to open "librestrict.so".

Moreover, at least a few weeks ago, the error did not occur.
My recent pull request does not change gcc.
I wonder why cross-compiler gcc began to open "librestrict.so".


Perhaps your fix to librestrict made something work that was not previously, 
and so an error is now detected?


--
Phil Holmes 


0001-Fix-GMP-for-32-bit.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Masamichi Hosoda]

> configure:3706: checking whether the C compiler works
> configure:3728: x86_64-freebsd6-gcc conftest.c  >&5
> x86_64-freebsd6-gcc: internal compiler error: Illegal instruction (program 
> cc1)
> librestrict:error:/home/gub/NewGub/gub/target/freebsd-64/root/usr/cross/bin/x86_64-freebsd6-gcc:
>  tried to open () file 
> /home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
> librestrict:allowed:
>   /home/gub/NewGub/gub/target/freebsd-64
>   /tmp
>   /dev/null
>   /dev/urandom
>   /proc/self

In my environment (Ubuntu 14.04 LTS 64 bit), the error does not occur.
Would you tell me the environment which the error occurs?

Anyway, this error means that
cross-compiler gcc (for freebsd-64) tries to open "librestrict.so".

"librestrict.so" is for host OS (perhaps Linux)
instead of for target OS (freebsd-64).

If I understand correctly,
cross-compiler gcc does not need to open "librestrict.so".
I don't know why cross-compiler gcc tries to open "librestrict.so".

Moreover, at least a few weeks ago, the error did not occur.
My recent pull request does not change gcc.
I wonder why cross-compiler gcc began to open "librestrict.so".

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: "Masamichi HOSODA" ; "Devel"
> 
> Sent: Sunday, August 14, 2016 12:04 PM
> Subject: Re: GUB problem
>
>
>> "Phil Holmes"  writes:
>>
>>> My GUB build failed again yesterday.  The log output is:
>>>
>>> checking for a BSD-compatible install... /usr/bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for x86_64-freebsd6-strip... x86_64-freebsd6-strip
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking whether make supports nested variables... yes
>>> checking whether make supports nested variables... (cached) yes
>>> checking for x86_64-freebsd6-gcc... x86_64-freebsd6-gcc
>>> checking whether the C compiler works... no
>>> configure: error: in
>>> `/home/gub/NewGub/gub/target/freebsd-64/build/fontconfig-2.12.1':
>>> configure: error: C compiler cannot create executables
>>>
>>> Can anyone suggest what the error might be?
>>
>> config.log should be more informative here.
>
>
> It didn't seem to be to me, but it's attached.

configure:3706: checking whether the C compiler works
configure:3728: x86_64-freebsd6-gcc conftest.c  >&5
x86_64-freebsd6-gcc: internal compiler error: Illegal instruction (program cc1)
librestrict:error:/home/gub/NewGub/gub/target/freebsd-64/root/usr/cross/bin/x86_64-freebsd6-gcc:
 tried to open () file 
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
  /home/gub/NewGub/gub/target/freebsd-64
  /tmp
  /dev/null
  /dev/urandom
  /proc/self

I suspect that Hosoda-san knows better than I how to address this: as
far as I understand the librestrict library tries making sure that the
cross-building environment does not access anything it shouldn't (which
is particularly important when the architecture of host and target
differ).

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Masamichi HOSODA" ; "Devel" 


Sent: Sunday, August 14, 2016 12:04 PM
Subject: Re: GUB problem



"Phil Holmes"  writes:


My GUB build failed again yesterday.  The log output is:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-freebsd6-strip... x86_64-freebsd6-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for x86_64-freebsd6-gcc... x86_64-freebsd6-gcc
checking whether the C compiler works... no
configure: error: in
`/home/gub/NewGub/gub/target/freebsd-64/build/fontconfig-2.12.1':
configure: error: C compiler cannot create executables

Can anyone suggest what the error might be?


config.log should be more informative here.



It didn't seem to be to me, but it's attached.

--
Phil Holmes 


config.log
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB problem

[David Kastrup]

"Phil Holmes"  writes:

> My GUB build failed again yesterday.  The log output is:
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for x86_64-freebsd6-strip... x86_64-freebsd6-strip
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> checking for x86_64-freebsd6-gcc... x86_64-freebsd6-gcc
> checking whether the C compiler works... no
> configure: error: in
> `/home/gub/NewGub/gub/target/freebsd-64/build/fontconfig-2.12.1':
> configure: error: C compiler cannot create executables
>
> Can anyone suggest what the error might be?

config.log should be more informative here.

> (I'm sending this directly to David K and Masamichi as well as the
> mailing list, since I have problems mailing direct to the maillist and
> Gmane seems to be down).

Gmane (the web interface) is not "down" as much as over.



-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel