On 24 November 2011 12:26, Alon Levy wrote:
> On Wed, Nov 23, 2011 at 07:33:48PM +, Peter Maydell wrote:
>> On 23 November 2011 19:22, Mr Dash Four wrote:
>> >
>> >> OK. We don't explicitly try to link with ssl3 ourselves, so this only
>> >> ever ends up in LDFLAGS because of some other libra
Likely Debian is not packaging systemtap scripts.
True, though I have no idea what the purpose of these files is.
Open a Fedora bug and link it to the upstream bug. Say in the Fedora
bug that the upstream bug is fixed but you couldn't find a commit that
relates to it.
Done - https://bugzil
On Wed, Nov 23, 2011 at 07:33:48PM +, Peter Maydell wrote:
> On 23 November 2011 19:22, Mr Dash Four wrote:
> >
> >> OK. We don't explicitly try to link with ssl3 ourselves, so this only
> >> ever ends up in LDFLAGS because of some other library that has claimed
> >> it needs it as a dependenc
On 11/24/2011 01:15 PM, Mr Dash Four wrote:
The bug report Max linked to previously suggests that bug is "CLOSED
FIXED". How's that fixed then?
Debian glib2 package version 2.24.2-1 works for me too. Looks like
Fedora packaging issue.
So, what do I do? Is there any way I could find what is c
The bug report Max linked to previously suggests that bug is "CLOSED FIXED".
How's that fixed then?
Debian glib2 package version 2.24.2-1 works for me too. Looks like
Fedora packaging issue.
So, what do I do? Is there any way I could find what is causing this?
Is there any solution to this?
>>> Traditional: it may be fixed in the mainline already, F15 has version
>>> 2.28.8, whereas mainline tip is 2.31.2.
>>> However nothing in the git log suggests that.
>>
>> FWIW Ubuntu Oneiric has glib2 2.30.0 and doesn't seem to have this problem.
> Just compi
>>> Is there any solution to this?
>> Traditional: it may be fixed in the mainline already, F15 has version
>> 2.28.8, whereas mainline tip is 2.31.2.
>> However nothing in the git log suggests that.
>
> FWIW Ubuntu Oneiric has glib2 2.30.0 and doesn't seem to have this problem.
Just compiled, bu
On 23 November 2011 23:15, Max Filippov wrote:
>> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24):
>> >> undefined reference to `glib_mem__alloc_semaphore'
>> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(
> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24):
> >> undefined reference to `glib_mem__alloc_semaphore'
> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c):
> >> undefined reference to `
>> $ make V=1
>> gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
>> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
>> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
>> -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body
On 23 November 2011 20:27, Mr Dash Four wrote:
> Peter, I hope you would be able to advice me on the following, if you can
> please: I have some ugly stuff in my qemu.spec file as follows:
[delete huge spec file]
> What parts do you think I should keep and should I delete, do you
> have an idea?
On 23 November 2011 21:40, Max Filippov wrote:
> --- a/configure
> +++ b/configure
> @@ -759,8 +759,6 @@ for opt do
> ;;
> --enable-opengl) opengl="yes"
> ;;
> - --*dir)
> - ;;
> --disable-rbd) rbd="no"
> ;;
> --enable-rbd) rbd="yes"
Haha, nice catch. Incidentally I think that the p
> > Did configure reported 'usb net redir' as 'no'?
> > Could you try configure and build in a clean directory?
> [mr-4@test1 qemu-1.0-rc3]$ ./configure --target-list="arm-linux-user
> armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice
> --disable-werror --disable-sdl -
> Did configure reported 'usb net redir' as 'no'?
> Could you try configure and build in a clean directory?
[mr-4@test1 qemu-1.0-rc3]$ ./configure --target-list="arm-linux-user
armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice
--disable-werror --disable-sdl --disable-v
> Even though I executed "./configure --target-list="arm-linux-user
> armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice
> --disable-werror --disable-sdl --disable-vnc --disable-bluez
> --disable-check-utests --disable-smartcard --disable-usb-redir --static" the
> -lu
> I don't get that - I get *SUCCESS*!!! I am going to run this through the
> rpmbuild, so that I get a proper package done.
I am an *idiot*. I just realised that I've ran ./configure the last time
without the --static option. My build now fails with:
gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D
> In the latest F15 it's not fixed. Mr-4, probably you will not escape
> re-compiling, if not even patching glib2.
Nope, I've just built it successfully (see my previous post)!
> It fails some other way ):
>
> $ make V=1
> gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
> -fstack-protector-all -Wendif-labels -Wmissi
> It fails some other way ):
>
> $ make V=1
> gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
> -fstack-protector-all -Wendif-labels -Wmissing
>> That is what I just wrote in my previous post, didn't I? The "die die die"
>> comments were related to the glib package, not the glib2! Just open
>> glib.spec and see it for yourself.
>
> However it looks from Max's list of libraries like the glib2-static package
> contains all the static lib
> >>> So, somebody at Fedora doesn't like static (.a) files very much, it
> >>> seems. I could easily correct this, enable static building and have these
> >>> installed, I think.
> >>
> >> There's glib2-static in Fedora:
> >>
> >> $ rpm -ql glib2-static
> >> /usr/lib64/libgio-2.0.a
> >> /usr/lib
On 23 November 2011 19:57, Mr Dash Four wrote:
>>> So, somebody at Fedora doesn't like static (.a) files very much, it seems.
>>> I could easily correct this, enable static building and have these
>>> installed, I think.
>>
>> There's glib2-static in Fedora:
>>
>> $ rpm -ql glib2-static
>> /usr/
>> So, somebody at Fedora doesn't like static (.a) files very much, it seems. I
>> could easily correct this, enable static building and have these installed,
>> I think.
>
> There's glib2-static in Fedora:
>
> $ rpm -ql glib2-static
> /usr/lib64/libgio-2.0.a
> /usr/lib64/libglib-2.0.a
> /usr/l
> > Do you have a static libgthread-2.0? (ie /usr/lib/libgthread-2.0.a or
> > equivalent).
> Nope, this is what I have:
>
> /usr/lib64/libgthread.so
> /usr/lib64/libgthread-2.0.so
> /usr/lib64/libgthread-1.2.so.0
> /usr/lib64/libgthread-1.2.so.0.0.10
>
> *but*, just downloaded the source rpm and
> Do you have a static libgthread-2.0? (ie /usr/lib/libgthread-2.0.a or
> equivalent).
Nope, this is what I have:
/usr/lib64/libgthread.so
/usr/lib64/libgthread-2.0.so
/usr/lib64/libgthread-1.2.so.0
/usr/lib64/libgthread-1.2.so.0.0.10
*but*, just downloaded the source rpm and looked at the .spec
On 23 November 2011 19:22, Mr Dash Four wrote:
>
>> OK. We don't explicitly try to link with ssl3 ourselves, so this only
>> ever ends up in LDFLAGS because of some other library that has claimed
>> it needs it as a dependency via pkg-config. Try adding
>> --disable-sdl --disable-vnc --disable-bl
> Which binary are we trying to link when we fail?
This is where it all fails:
gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
-fstack-protector-a
On 23 November 2011 19:02, Mr Dash Four wrote:
>
>> Sonuds like a good plan.
> Nope, same error as before:
> /usr/bin/ld: cannot find -lssl3
> collect2: ld returned 1 exit status
Which binary are we trying to link when we fail?
> I get exactly the same result if I just unpack the source and run
> Sonuds like a good plan.
Nope, same error as before:
/usr/bin/ld: cannot find -lssl3
collect2: ld returned 1 exit status
The source was unpacked, I disabled all the patches in that .spec file, ran
"rpmbuild -bp qemu.spec", then manually went to that directory
(BUILD/qemu-1.0-rc3) and typed ".
On 23 November 2011 18:42, Mr Dash Four wrote:
>> Can you retry this with one of the 1.0 release candidates
>> or current head-of-git, please?
> OK, I'll try with 1.0-rc3, but before that just a quick query - I use the
> Fedora source rpm as a basis and do "rpmbuild -bp qemu.spec" to prepare
> th
> Can you retry this with one of the 1.0 release candidates
> or current head-of-git, please?
OK, I'll try with 1.0-rc3, but before that just a quick query - I use the
Fedora source rpm as a basis and do "rpmbuild -bp qemu.spec" to prepare the
source. This, according to the said .spec file, appli
On 23 November 2011 18:33, Mr Dash Four wrote:
> FYI Peter, I just tried to build qemu with only the -user targets -
> unsuccessfully - exactly the same error as before -lssl3 cannot be found.
Can you retry this with one of the 1.0 release candidates
or current head-of-git, please?
(when I do a
>> >> So, where do I get this?
> >
> > You don't. Fedora does not package static libraries. Just don't use
> > the option on Linux, it makes (a little) sense only on Windows to get a
> > monolithic, redistributable qemu.exe.
So, what you are suggesting above is that qemu-[arch]-static cannot be
>> You don't. Fedora does not package static libraries. Just don't use the
>> option on Linux, it makes (a little) sense only on Windows to get a
>> monolithic, redistributable qemu.exe.
>
> It's also important for building linux-user targets so you can
> put them in chroots. Luckily linux-user
On 23 November 2011 18:00, Paolo Bonzini wrote:
> You don't. Fedora does not package static libraries. Just don't use the
> option on Linux, it makes (a little) sense only on Windows to get a
> monolithic, redistributable qemu.exe.
It's also important for building linux-user targets so you can
On 11/23/2011 04:41 PM, Mr Dash Four wrote:
Hmm, this opens a huge Pandora's box for me - in my own distribution
(Fedora) the "nss" package (which I have installed) provides
/usr/lib64/libssl3.so, but not libssl3.a. "nss-devel" (which I also have
installed) provides all the relevant /include fi
Perhaps you lack a static version of the library.
What do you mean by that? The *.la files? I wasn't aware that there are
any...
I mean lib*.a files. They are needed if you specify static, by
definition.
Hmm, this opens a huge Pandora's box for me - in my own distribution
(Fedora) the "nss
On 11/23/2011 03:15 PM, Mr Dash Four wrote:
It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the "--static" option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?
P
./configure --target-list="x86_64-softmmu arm-softmmu x86_64-linux-user
arm-linux-user armeb-linux-user" --disable-kvm --disable-strip --disable-xen
--disable-spice --disable-werror --static
then "make V=1". It fails with the following error:
You're trying to build the -softmmu targets w
On 23 November 2011 12:58, Mr Dash Four wrote:
> I am trying to build a static version of the qemu-[arch] executables to be
> used in chrooted environment for the target arch (which is different from
> the host). My configure is:
>
> ./configure --target-list="x86_64-softmmu arm-softmmu x86_64-lin
It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the "--static" option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?
Perhaps you lack a static version of the lib
On 11/23/2011 01:58 PM, Mr Dash Four wrote:
It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the "--static" option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?
P
I am trying to build a static version of the qemu-[arch] executables to
be used in chrooted environment for the target arch (which is different
from the host). My configure is:
./configure --target-list="x86_64-softmmu arm-softmmu x86_64-linux-user
arm-linux-user armeb-linux-user" --disable-kv
43 matches
Mail list logo
