[libvirt] FreeBSD Port, update to 0.9.2 compile error
Hi, I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet. console.c:280: warning: declaration of 'devname' shadows a global declaration [-Wshadow] /usr/include/stdlib.h:264: warning: shadowed declaration is here [-Wshadow] CC virsh-virsh.o CCLD virsh GEN virt-xml-validate GEN virt-pki-validate gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found gmake[2]: *** [libvirt-api.xml] Error 127 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2' gmake: *** [all] Error 2 *** Error code 1 Stop in /home/jhelfman/ports/devel/libvirt. Any thoughts? Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 06/07/2011 09:27 PM, Jason Helfman wrote:
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet.
Is this a VPATH build?
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to find some time to look into it tomorrow (it's late for me tonight). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
On 06/07/2011 09:27 PM, Jason Helfman wrote:
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet.
Is this a VPATH build?
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to find some time to look into it tomorrow (it's late for me tonight).
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD. Here is a patch: - --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python # # This is the API builder, it parses the C sources and build the # API formal description in XML. - -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk3vEcIACgkQXpKtZoyM+6UTDgD+M0FhJEjiE79Q8H2mODWYWwlO IUJYUqK7Wc4RwKki5LAA/AqgFeYD+JzPvQ3fOSEb0h4RmCKENYKEdppO22F9DOF3 =oNes -----END PGP SIGNATURE-----
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
On 06/07/2011 09:27 PM, Jason Helfman wrote:
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet.
Is this a VPATH build?
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to find some time to look into it tomorrow (it's late for me tonight).
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this for example: http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t-wo... another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
On 06/07/2011 09:27 PM, Jason Helfman wrote:
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet.
Is this a VPATH build?
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to find some time to look into it tomorrow (it's late for me tonight).
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
/usr/local/bin
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t-wo...
I would argue that using /usr/bin/env is the correct way to handle this and users that this breaks for haven't properly configured their environment path for their binaries. Non-standard paths should be put in a path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very standard, in my humble opinion.
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
Daniel
-- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
-Jason
On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
/usr/local/bin
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t-wo...
I would argue that using /usr/bin/env is the correct way to handle this and users that this breaks for haven't properly configured their environment path for their binaries. Non-standard paths should be put in a path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very standard, in my humble opinion.
yes, I was doing the same, and people complained, left and right :-\
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes] to take a path Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain
I agree, and we already use that in one place in python/Makefile.am: $(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
No extension needed, it already supports that (although it's not advertised anywhere). One can use the following forms --with-python --with-python=/usr/local --with-python=/usr/local/bin/python PYTHON=/usr/local/bin/python --with-python Jirka
On Thu, Jun 09, 2011 at 03:12:42PM +0200, Jiri Denemark thus spake:
On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain
I agree, and we already use that in one place in python/Makefile.am:
$(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
No extension needed, it already supports that (although it's not advertised anywhere). One can use the following forms
--with-python --with-python=/usr/local --with-python=/usr/local/bin/python PYTHON=/usr/local/bin/python --with-python
Jirka
Sounds good to me. How would the python script in question support this? Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On Thu, Jun 09, 2011 at 10:04:22AM -0700, Jason Helfman wrote:
On Thu, Jun 09, 2011 at 03:12:42PM +0200, Jiri Denemark thus spake:
On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain
I agree, and we already use that in one place in python/Makefile.am:
$(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
No extension needed, it already supports that (although it's not advertised anywhere). One can use the following forms
--with-python --with-python=/usr/local --with-python=/usr/local/bin/python PYTHON=/usr/local/bin/python --with-python
Jirka
Sounds good to me. How would the python script in question support this?
(1) Rename the original script so it is called 'foo.in' (for each original script called 'foo') (2) At the top of 'foo.in' place the following two lines: #!@PYTHON@ # @configure_input@ (3) In configure.ac, you have to make two changes: (a) in AC_CONFIG_FILES, add an entry for 'foo' (b) add a new line AC_SUBST([PYTHON]) after the current line AC_SUBST([PYTHON_INCLUDES]) (4) Run 'autoconf'. ./configure will then generate 'foo' from 'foo.in', replacing all @...@ sequences, so for example the first line above would be replaced with #!/usr/local/bin/python. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On 06/12/2011 02:18 PM, Richard W.M. Jones wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain
I agree, and we already use that in one place in python/Makefile.am:
$(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
Sounds good to me. How would the python script in question support this?
(1) Rename the original script so it is called 'foo.in' (for each original script called 'foo')
(2) At the top of 'foo.in' place the following two lines:
#!@PYTHON@ # @configure_input@
Using $(PYTHON) in appropriate Makefile.am is sufficient if the script will only ever be invoked by a Makefile generated at configure time. But if the script must be installed, then yes, the script.in approach is the way to go. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Hi, On Thu, Jun 09, 2011 at 08:55:01PM +0800, Daniel Veillard thus spake:
On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
/usr/local/bin
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t-wo...
I would argue that using /usr/bin/env is the correct way to handle this and users that this breaks for haven't properly configured their environment path for their binaries. Non-standard paths should be put in a path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very standard, in my humble opinion.
yes, I was doing the same, and people complained, left and right :-\
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
Daniel
I was wondering if this issue was addressed in the upcoming release? Thanks! Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 06/27/2011 10:29 AM, Jason Helfman wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
Daniel
I was wondering if this issue was addressed in the upcoming release?
I'm not sure that I've seen patches go in yet, but they are still fair game to include if RC1 doesn't meet your needs as this is a real bug fix. I'm also hoping to clean up configure to work on systems where python headers are not installed (my earlier attempt stalled at https://www.redhat.com/archives/libvir-list/2011-May/msg01223.html). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, Jun 27, 2011 at 09:29:34AM -0700, Jason Helfman wrote:
Hi, On Thu, Jun 09, 2011 at 08:55:01PM +0800, Daniel Veillard thus spake:
On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
I found the issue in building was an absolute path for apibuild.py for python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
/usr/local/bin
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700 +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700 @@ -1,4 +1,4 @@ - -#!/usr/bin/python -u +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t-wo...
I would argue that using /usr/bin/env is the correct way to handle this and users that this breaks for haven't properly configured their environment path for their binaries. Non-standard paths should be put in a path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very standard, in my humble opinion.
yes, I was doing the same, and people complained, left and right :-\
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would complain we should even be able to detect at configure and take specific paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python --with-python Build python bindings [default=yes]
to take a path
Daniel
I was wondering if this issue was addressed in the upcoming release?
Oops, no but it should be as simple as the following patch, we should be able to get this fixed in time ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
I was wondering if this issue was addressed in the upcoming release?
Oops, no but it should be as simple as the following patch, we should be able to get this fixed in time !
diff --git a/docs/Makefile.am b/docs/Makefile.am index 689fe32..050ebe1 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \ $(srcdir)/../include/libvirt/*.h \ $(srcdir)/../src/libvirt.c \ $(srcdir)/../src/util/virterror.c - $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py + $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
check-local: all
ACK. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Jul 01, 2011 at 08:57:35AM -0600, Eric Blake wrote:
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
I was wondering if this issue was addressed in the upcoming release?
Oops, no but it should be as simple as the following patch, we should be able to get this fixed in time !
diff --git a/docs/Makefile.am b/docs/Makefile.am index 689fe32..050ebe1 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \ $(srcdir)/../include/libvirt/*.h \ $(srcdir)/../src/libvirt.c \ $(srcdir)/../src/util/virterror.c - $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py + $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
check-local: all
ACK.
Thanks ! pushed :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Fri, Jul 01, 2011 at 08:57:35AM -0600, Eric Blake thus spake:
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
another way would be to launch python directly giving the path to the python script, this is likely to solve the issue there.
I was wondering if this issue was addressed in the upcoming release?
Oops, no but it should be as simple as the following patch, we should be able to get this fixed in time !
diff --git a/docs/Makefile.am b/docs/Makefile.am index 689fe32..050ebe1 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \ $(srcdir)/../include/libvirt/*.h \ $(srcdir)/../src/libvirt.c \ $(srcdir)/../src/util/virterror.c - $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py + $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
check-local: all
ACK.
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
I applied this patch (cleanly), and it still breaks: gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' GEN libvirt-api.xml ./apibuild.py: not found gmake[2]: *** [libvirt-api.xml] Error 127 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3' gmake: *** [all] Error 2 *** Error code 1 From the top of the file: #!/usr/bin/python -u From Makefile.am after patch: $(python_generated_files): $(srcdir)/apibuild.py \ $(srcdir)/../include/libvirt/*.h \ $(srcdir)/../src/libvirt.c \ $(srcdir)/../src/util/virterror.c $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py -jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 07/01/2011 02:58 PM, Jason Helfman wrote:
I applied this patch (cleanly), and it still breaks: gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' GEN libvirt-api.xml ./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better picture of what make tried to do here? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
On 07/01/2011 02:58 PM, Jason Helfman wrote:
I applied this patch (cleanly), and it still breaks: gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' GEN libvirt-api.xml ./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better picture of what make tried to do here?
Done. Here is the log of the run: http://jgh.devio.us/files/libvirt.log.gz Thanks! Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 07/01/2011 03:15 PM, Jason Helfman wrote:
On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
On 07/01/2011 02:58 PM, Jason Helfman wrote:
I applied this patch (cleanly), and it still breaks: gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' GEN libvirt-api.xml ./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better picture of what make tried to do here?
Done. Here is the log of the run: http://jgh.devio.us/files/libvirt.log.gz
Thanks (I was only interested in the tail of that, so you were wise to post the file to a website rather than spamming the list with the entire file) gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' srcdir=. ./apibuild.py + srcdir=. ./apibuild.py ./apibuild.py: not found gmake[2]: *** [libvirt-api.xml] Error 127 This looks like your Makefile was not regenerated after your Makefile.am change; there's no evidence that make expanded $(PYTHON) anywhere. Did you just patch the release-candidate tarball, or are you working from libvirt.git? I still think the latest libvirt.git has fixed things, so if you are just working from tarballs, either we will have an RC3 for you to test, or you'll have to figure out how to regenerate things yourself. Do you have automake and autoconf installed? If so, 'autoreconf -v' before your next make should fix things. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Jul 01, 2011 at 04:21:54PM -0600, Eric Blake thus spake:
On 07/01/2011 03:15 PM, Jason Helfman wrote:
On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
On 07/01/2011 02:58 PM, Jason Helfman wrote:
I applied this patch (cleanly), and it still breaks: gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' GEN libvirt-api.xml ./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better picture of what make tried to do here?
Done. Here is the log of the run: http://jgh.devio.us/files/libvirt.log.gz
Thanks (I was only interested in the tail of that, so you were wise to post the file to a website rather than spamming the list with the entire file)
gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs' srcdir=. ./apibuild.py + srcdir=. ./apibuild.py ./apibuild.py: not found gmake[2]: *** [libvirt-api.xml] Error 127
This looks like your Makefile was not regenerated after your Makefile.am change; there's no evidence that make expanded $(PYTHON) anywhere. Did you just patch the release-candidate tarball, or are you working from libvirt.git? I still think the latest libvirt.git has fixed things, so if you are just working from tarballs, either we will have an RC3 for you to test, or you'll have to figure out how to regenerate things yourself.
Do you have automake and autoconf installed? If so, 'autoreconf -v' before your next make should fix things.
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Ok, this worked. I was using the downloaded rc3 tarball, and I added the patches in the build process, as FreeBSD ports patch prior to the build. I added in to use autotools and ran a clean build, and it worked with no issue. USE_AUTOTOOLS= automake autoconf Thanks! Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
participants (5)
-
Daniel Veillard -
Eric Blake -
Jason Helfman -
Jiri Denemark -
Richard W.M. Jones