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
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 compiled, bu
>> $ 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
> 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
> 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
>> 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/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 looked at the .spec
> 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
> 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 ".
> 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
>> >> 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
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
./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
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
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
20 matches
Mail list logo
