1:38 p.m.
Hi,
This is a cross-post from libvirt-users since there didn't seem to be
anyone there familiar with what is going on and this is a dev issue as
well.
I'm using the Ruby/FFI libvirt library and getting this consistently
on Mac OS X:
ruby-1.9.2-p0 > FFI::Libvirt.virInitialize
dyld: lazy symbol binding failed: Symbol not found: _virThreadInitialize
Referenced from: /usr/local/lib/libvirt.dylib
Expected in: flat namespace
dyld: Symbol not found: _virThreadInitialize
Referenced from: /usr/local/lib/libvirt.dylib
Expected in: flat namespace
Trace/BPT trap
I exported DYLD_PRINT_LIBRARIES and it shows that libvirt.dylib is
loaded in the process space, but the above still occurs. When I
statically link into a C program it works fine, however. Anyone have
any idea what could be causing this?
See this archive if you'd like to catch up on what was said in
libvirt-users (its not a long thread):
https://www.redhat.com/archives/libvirt-users/2010-October/msg00050.html
Thanks,
Mitchell
4:56 p.m.
I've been working with Justin, and we've been making some progress.
However, I have another question for this list. As a follow-up to
this, I realized that when I download the snapshots and just
"./configure; make; make install" then I get the lazy binding issue.
However, if I go through the entire autogen process:
./autogen.sh
make
make install
Then this issue goes away. Could this be indicative of a bug in the
autotools input perhaps on generating the packages on machines which
aren't Macs? How do I test the packaging myself (on a Mac) so that I
can verify this theory?
Given this information, does this shed some light and perhaps reveal a
problem someone more experienced than I would see?
Thanks,
Mitchell
On Fri, Oct 8, 2010 at 11:38 AM, Mitchell Hashimoto
<mitchell.hashimoto(a)gmail.com> wrote:
Hi,
This is a cross-post from libvirt-users since there didn't seem to be
anyone there familiar with what is going on and this is a dev issue as
well.
I'm using the Ruby/FFI libvirt library and getting this consistently
on Mac OS X:
ruby-1.9.2-p0 > FFI::Libvirt.virInitialize
dyld: lazy symbol binding failed: Symbol not found: _virThreadInitialize
Referenced from: /usr/local/lib/libvirt.dylib
Expected in: flat namespace
dyld: Symbol not found: _virThreadInitialize
Referenced from: /usr/local/lib/libvirt.dylib
Expected in: flat namespace
Trace/BPT trap
I exported DYLD_PRINT_LIBRARIES and it shows that libvirt.dylib is
loaded in the process space, but the above still occurs. When I
statically link into a C program it works fine, however. Anyone have
any idea what could be causing this?
See this archive if you'd like to catch up on what was said in
libvirt-users (its not a long thread):
https://www.redhat.com/archives/libvirt-users/2010-October/msg00050.html
Thanks,
Mitchell
5:04 p.m.
On 10/12/2010 03:56 PM, Mitchell Hashimoto wrote:
I've been working with Justin, and we've been making some
progress.
However, I have another question for this list. As a follow-up to
this, I realized that when I download the snapshots and just
"./configure; make; make install" then I get the lazy binding issue.
However, if I go through the entire autogen process:
./autogen.sh
make
make install
Then this issue goes away. Could this be indicative of a bug in the
autotools input perhaps on generating the packages on machines which
aren't Macs? How do I test the packaging myself (on a Mac) so that I
can verify this theory?
Not ringing any bells for me.
What if you do:
./autogen.sh
make
make dist
then expand that tarball to another directory, run ./configure and make,
and compare the git tree with the tarball you just created? Also, how
does the snapshot compare to your tarball?
Are you using git to create the snapshots (in which case I have no idea
how the .gnulib submodule is being handled, if at all), or are they made
from some 'make dist' cron job?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
6:34 p.m.
Eric,
I've been getting this error lately from git (happening during `make`):
make[1]: *** No rule to make target `todo.pl', needed by `todo.html.in'. Stop.
make: *** [distdir] Error 1
I haven't taken any time to look at it, but its caused by the
documentation task, obviously. I've been getting around this during
compile time with just doing "make install" which skips the doc task.
This is preventing me from testing my `make dist` tarball.
Mitchell
On Tue, Oct 12, 2010 at 3:04 PM, Eric Blake <eblake(a)redhat.com> wrote:
On 10/12/2010 03:56 PM, Mitchell Hashimoto wrote:
>
> I've been working with Justin, and we've been making some progress.
> However, I have another question for this list. As a follow-up to
> this, I realized that when I download the snapshots and just
> "./configure; make; make install" then I get the lazy binding issue.
> However, if I go through the entire autogen process:
>
> ./autogen.sh
> make
> make install
>
> Then this issue goes away. Could this be indicative of a bug in the
> autotools input perhaps on generating the packages on machines which
> aren't Macs? How do I test the packaging myself (on a Mac) so that I
> can verify this theory?
Not ringing any bells for me.
What if you do:
./autogen.sh
make
make dist
then expand that tarball to another directory, run ./configure and make, and
compare the git tree with the tarball you just created? Also, how does the
snapshot compare to your tarball?
Are you using git to create the snapshots (in which case I have no idea how
the .gnulib submodule is being handled, if at all), or are they made from
some 'make dist' cron job?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4:09 a.m.
On Tue, Oct 12, 2010 at 04:34:08PM -0700, Mitchell Hashimoto wrote:
Eric,
I've been getting this error lately from git (happening during `make`):
make[1]: *** No rule to make target `todo.pl', needed by `todo.html.in'. Stop.
make: *** [distdir] Error 1
You should get it from that git commit:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=1938bc69a78de820d475ff96...
I haven't taken any time to look at it, but its caused by the
documentation task, obviously. I've been getting around this during
compile time with just doing "make install" which skips the doc task.
This is preventing me from testing my `make dist` tarball.
I just tried "make dist" from the git head, and that worked fine
for me,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:20 a.m.
On Wed, Oct 13, 2010 at 11:09:19AM +0200, Daniel Veillard wrote:
On Tue, Oct 12, 2010 at 04:34:08PM -0700, Mitchell Hashimoto wrote:
> Eric,
>
> I've been getting this error lately from git (happening during `make`):
>
> make[1]: *** No rule to make target `todo.pl', needed by `todo.html.in'.
Stop.
> make: *** [distdir] Error 1
This is caused by missing todo.pl in EXTRA_DIST, which I've fixed now.
> I haven't taken any time to look at it, but its caused by
the
> documentation task, obviously. I've been getting around this during
> compile time with just doing "make install" which skips the doc task.
>
> This is preventing me from testing my `make dist` tarball.
I just tried "make dist" from the git head, and that worked fine
for me,
It is only once you try to build from the resulting tar.gz that you
hit the problem due to the missing file
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:44 a.m.
On Tue, Oct 12, 2010 at 02:56:31PM -0700, Mitchell Hashimoto wrote:
I've been working with Justin, and we've been making some
progress.
However, I have another question for this list. As a follow-up to
this, I realized that when I download the snapshots and just
"./configure; make; make install" then I get the lazy binding issue.
However, if I go through the entire autogen process:
./autogen.sh
make
make install
Do you see a difference when ou run
# grep VERSION_SCRIPT_FLAGS Makefile
VERSION_SCRIPT_FLAGS = -Wl,--version-script=
between the plain 'configure' case, and the full autogen.sh case ?
Also, does the src/libvirt.syms look any different in either case ?
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
2:06 p.m.
Daniel,
Thanks for your response, I appreciate it. The `grep` on the two
Makefiles is equivalent. I've uploaded a diff of the two Makefiles
here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you
want me to upload the actual Makefiles as well, since I can do that.
Also the src/libvirt.syms file is the same in both cases.
Hope this helps! Let me know if there is anything else I can do to assist you.
Mitchell
On Thu, Oct 14, 2010 at 6:44 AM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
On Tue, Oct 12, 2010 at 02:56:31PM -0700, Mitchell Hashimoto wrote:
> I've been working with Justin, and we've been making some progress.
> However, I have another question for this list. As a follow-up to
> this, I realized that when I download the snapshots and just
> "./configure; make; make install" then I get the lazy binding issue.
> However, if I go through the entire autogen process:
>
> ./autogen.sh
> make
> make install
Do you see a difference when ou run
# grep VERSION_SCRIPT_FLAGS Makefile
VERSION_SCRIPT_FLAGS = -Wl,--version-script=
between the plain 'configure' case, and the full autogen.sh case ?
Also, does the src/libvirt.syms look any different in either case ?
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
2:44 p.m.
On 10/14/2010 01:06 PM, Mitchell Hashimoto wrote:
Daniel,
Thanks for your response, I appreciate it. The `grep` on the two
Makefiles is equivalent. I've uploaded a diff of the two Makefiles
here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you
want me to upload the actual Makefiles as well, since I can do that.
Can you provide a context diff (diff -u or diff -c) rather than an
ed-script diff? Context can be essential in a review.
At any rate:
< # Makefile.in generated by automake 1.9.6 from Makefile.am.
---
# Makefile.in generated by automake 1.11.1 from Makefile.am.
Is this stock automake 1.9.6, or does it have a distro patch to fix
CVE-2009-4029? Using an older automake may be the root cause of
remaining problems, if we are relying on a feature that only automake
1.10 or 1.11 provides.
What is 'automake --version' for you, and did you generate the tarballs,
or is the automake 1.9.6 on someone else's machine?
< $(top_srcdir)/m4/nls.m4 $(top_srcdir)/m4/po.m4 \
< $(top_srcdir)/m4/progtest.m4 $(top_srcdir)/m4/size_max.m4 \
< $(top_srcdir)/m4/wchar_t.m4 $(top_srcdir)/m4/wint_t.m4 \
< $(top_srcdir)/m4/xsize.m4 $(top_srcdir)/acinclude.m4 \
< $(top_srcdir)/configure.ac
---
$(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \
$(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \
$(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/m4/nls.m4 \
$(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \
$(top_srcdir)/m4/size_max.m4 $(top_srcdir)/m4/wchar_t.m4 \
$(top_srcdir)/m4/wint_t.m4 $(top_srcdir)/m4/xsize.m4 \
$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
Why the difference in which libtool .m4 files are provided?
< configure.lineno configure.status.lineno
---
configure.lineno config.status.lineno
There's no such file as configure.status.lineno; but that's attributable
to a bug in the older automake that has since been fixed.
I've stopped looking at this point.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:28 p.m.
Eric,
First, here is the output from diff -c:
https://gist.github.com/7d8c32849e4d72be5368
I ran `automake --version` and I have "1.11.1" And the "1.9.6"
automake is from the libvirt build servers, not any of my machines. I
was comparing the "./configure" output from the snapshot with when I
run "autogen.sh" myself.
I'm not sure about the other points you brought up. I just ran the
typical commands that README-hacking says to.
Mitchell
On Thu, Oct 14, 2010 at 12:44 PM, Eric Blake <eblake(a)redhat.com> wrote:
On 10/14/2010 01:06 PM, Mitchell Hashimoto wrote:
>
> Daniel,
>
> Thanks for your response, I appreciate it. The `grep` on the two
> Makefiles is equivalent. I've uploaded a diff of the two Makefiles
> here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you
> want me to upload the actual Makefiles as well, since I can do that.
Can you provide a context diff (diff -u or diff -c) rather than an ed-script
diff? Context can be essential in a review.
At any rate:
< # Makefile.in generated by automake 1.9.6 from Makefile.am.
---
> # Makefile.in generated by automake 1.11.1 from Makefile.am.
Is this stock automake 1.9.6, or does it have a distro patch to fix
CVE-2009-4029? Using an older automake may be the root cause of remaining
problems, if we are relying on a feature that only automake 1.10 or 1.11
provides.
What is 'automake --version' for you, and did you generate the tarballs, or
is the automake 1.9.6 on someone else's machine?
< $(top_srcdir)/m4/nls.m4 $(top_srcdir)/m4/po.m4 \
< $(top_srcdir)/m4/progtest.m4 $(top_srcdir)/m4/size_max.m4 \
< $(top_srcdir)/m4/wchar_t.m4 $(top_srcdir)/m4/wint_t.m4 \
< $(top_srcdir)/m4/xsize.m4 $(top_srcdir)/acinclude.m4 \
< $(top_srcdir)/configure.ac
---
> $(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \
> $(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \
> $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/m4/nls.m4 \
> $(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \
> $(top_srcdir)/m4/size_max.m4 $(top_srcdir)/m4/wchar_t.m4 \
> $(top_srcdir)/m4/wint_t.m4 $(top_srcdir)/m4/xsize.m4 \
> $(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
Why the difference in which libtool .m4 files are provided?
< configure.lineno configure.status.lineno
---
> configure.lineno config.status.lineno
There's no such file as configure.status.lineno; but that's attributable to
a bug in the older automake that has since been fixed.
I've stopped looking at this point.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
1:43 a.m.
All,
With a few small patches (to remove documentation generation, thanks
to Justin) to my local git checkout, I was finally able to "make dist"
and test the resulting distribution. The result is that this worked
great on my Mac as well as another Mac I have that was having trouble.
I think this strongly supports the argument that the issue is that the
libvirt build server autotools versions are out of date which is
causing an issue for some reason on Mac. My autotools versions follow,
for reference:
Autoconf: 2.68
Automake: 1.11.1
Libtool: 2.4
For reference, or if anyone has a Mac and wants to try, I've uploaded
my distribution here:
http://mitchellh.github.com/libvirt/libvirt-0.8.4.tar.gz
Is this enough evidence in favor of build tool versions? Would anyone
like me to try anything else?
Thanks,
Mitchell
On Thu, Oct 14, 2010 at 1:28 PM, Mitchell Hashimoto
<mitchell.hashimoto(a)gmail.com> wrote:
Eric,
First, here is the output from diff -c:
https://gist.github.com/7d8c32849e4d72be5368
I ran `automake --version` and I have "1.11.1" And the "1.9.6"
automake is from the libvirt build servers, not any of my machines. I
was comparing the "./configure" output from the snapshot with when I
run "autogen.sh" myself.
I'm not sure about the other points you brought up. I just ran the
typical commands that README-hacking says to.
Mitchell
On Thu, Oct 14, 2010 at 12:44 PM, Eric Blake <eblake(a)redhat.com> wrote:
> On 10/14/2010 01:06 PM, Mitchell Hashimoto wrote:
>>
>> Daniel,
>>
>> Thanks for your response, I appreciate it. The `grep` on the two
>> Makefiles is equivalent. I've uploaded a diff of the two Makefiles
>> here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you
>> want me to upload the actual Makefiles as well, since I can do that.
>
> Can you provide a context diff (diff -u or diff -c) rather than an ed-script
> diff? Context can be essential in a review.
>
> At any rate:
>
> < # Makefile.in generated by automake 1.9.6 from Makefile.am.
> ---
>> # Makefile.in generated by automake 1.11.1 from Makefile.am.
>
> Is this stock automake 1.9.6, or does it have a distro patch to fix
> CVE-2009-4029? Using an older automake may be the root cause of remaining
> problems, if we are relying on a feature that only automake 1.10 or 1.11
> provides.
>
> What is 'automake --version' for you, and did you generate the tarballs, or
> is the automake 1.9.6 on someone else's machine?
>
> < $(top_srcdir)/m4/nls.m4 $(top_srcdir)/m4/po.m4 \
> < $(top_srcdir)/m4/progtest.m4 $(top_srcdir)/m4/size_max.m4 \
> < $(top_srcdir)/m4/wchar_t.m4 $(top_srcdir)/m4/wint_t.m4 \
> < $(top_srcdir)/m4/xsize.m4 $(top_srcdir)/acinclude.m4 \
> < $(top_srcdir)/configure.ac
> ---
>> $(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \
>> $(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \
>> $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/m4/nls.m4 \
>> $(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \
>> $(top_srcdir)/m4/size_max.m4 $(top_srcdir)/m4/wchar_t.m4 \
>> $(top_srcdir)/m4/wint_t.m4 $(top_srcdir)/m4/xsize.m4 \
>> $(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
>
> Why the difference in which libtool .m4 files are provided?
>
> < configure.lineno configure.status.lineno
> ---
>> configure.lineno config.status.lineno
>
> There's no such file as configure.status.lineno; but that's attributable to
> a bug in the older automake that has since been fixed.
>
> I've stopped looking at this point.
>
> --
> Eric Blake eblake(a)redhat.com +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
4:34 a.m.
On 10/18/2010 05:43 PM, Mitchell Hashimoto wrote:
All,
With a few small patches (to remove documentation generation, thanks
to Justin) to my local git checkout, I was finally able to "make dist"
and test the resulting distribution. The result is that this worked
great on my Mac as well as another Mac I have that was having trouble.
I think this strongly supports the argument that the issue is that the
libvirt build server autotools versions are out of date which is
causing an issue for some reason on Mac. My autotools versions follow,
for reference:
Autoconf: 2.68
Automake: 1.11.1
Libtool: 2.4
For reference, or if anyone has a Mac and wants to try, I've uploaded
my distribution here:
http://mitchellh.github.com/libvirt/libvirt-0.8.4.tar.gz
Is this enough evidence in favor of build tool versions? Would anyone
like me to try anything else?
Daniel, do we want to drill into this further, to analyse what the
older version of autotools on the libvirt.org build server is doing...?
Thinking that it might (unsure) "just be easier" to upgrade the
autotools version on the server?
:)
Regards and best wishes,
Justin Clift
5 a.m.
On Mon, Oct 18, 2010 at 08:34:56PM +1100, Justin Clift wrote:
On 10/18/2010 05:43 PM, Mitchell Hashimoto wrote:
>All,
>
>With a few small patches (to remove documentation generation, thanks
>to Justin) to my local git checkout, I was finally able to "make dist"
>and test the resulting distribution. The result is that this worked
>great on my Mac as well as another Mac I have that was having trouble.
>I think this strongly supports the argument that the issue is that the
>libvirt build server autotools versions are out of date which is
>causing an issue for some reason on Mac. My autotools versions follow,
>for reference:
>
>Autoconf: 2.68
>Automake: 1.11.1
>Libtool: 2.4
>
>For reference, or if anyone has a Mac and wants to try, I've uploaded
>my distribution here:
>http://mitchellh.github.com/libvirt/libvirt-0.8.4.tar.gz
>
>Is this enough evidence in favor of build tool versions? Would anyone
>like me to try anything else?
Daniel, do we want to drill into this further, to analyse what the
older version of autotools on the libvirt.org build server is doing...?
Thinking that it might (unsure) "just be easier" to upgrade the
autotools version on the server?
:)
Builds are not done on the server but on my workstation, currently
running Fedora 12:
paphio:~ -> rpm -q autoconf automake libtool
autoconf-2.63-5.fc12.noarch
automake-1.11.1-1.fc12.noarch
libtool-2.2.6-18.fc12.1.x86_64
I should probably update them before the next release ...
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:11 a.m.
On 10/18/2010 09:00 PM, Daniel Veillard wrote:
<snip>
Builds are not done on the server but on my workstation, currently
running Fedora 12:
paphio:~ -> rpm -q autoconf automake libtool
autoconf-2.63-5.fc12.noarch
automake-1.11.1-1.fc12.noarch
libtool-2.2.6-18.fc12.1.x86_64
I should probably update them before the next release ...
Cool. :)
Does your workstation create the hourly snapshots too?
I can whip up a F12 dekstop VM locally here, and test that updated
autotools in it produce tarballs that work on MacOS X.
Thinking it's better to get it tested up front, than get to 0.8.5
release time and find out afterwards it didn't work quite the way
we want. ;)
5151
days inactive
5161
days old
13 comments
5 participants
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Justin Clift -
Mitchell Hashimoto