Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 03 20:21
    MehdiChinoune opened #14411
  • Dec 03 20:11
    MehdiChinoune opened #14410
  • Dec 03 19:52

    lazka on master

    libxml2: remove indirect depend… Merge pull request #3364 from l… (compare)

  • Dec 03 19:52
    lazka closed #3364
  • Dec 03 19:30
    lazka converted_to_draft #3365
  • Dec 03 19:30

    lazka on master

    libtool: fix license file locat… Merge pull request #3366 from l… (compare)

  • Dec 03 19:30
    lazka closed #3366
  • Dec 03 17:54
    mmuetzel ready_for_review #14408
  • Dec 03 17:48

    Biswa96 on master

    helics: Update to 3.3.2 (compare)

  • Dec 03 17:48
    Biswa96 closed #14409
  • Dec 03 17:43
    mmuetzel synchronize #14408
  • Dec 03 17:41
    lazka converted_to_draft #14408
  • Dec 03 17:41
    lazka opened #3366
  • Dec 03 17:39
    mmuetzel commented #14408
  • Dec 03 17:34
    Biswa96 commented #14405
  • Dec 03 17:34

    MehdiChinoune on master

    python-chardet: update to 5.1.0 (compare)

  • Dec 03 17:34
    MehdiChinoune closed #14406
  • Dec 03 17:34

    MehdiChinoune on master

    avr-gdb: update to 12.1 (compare)

  • Dec 03 17:34
    MehdiChinoune closed #14407
  • Dec 03 17:21
    HELICS-bot opened #14409
meson dont calculate python3_prog
instead it just print "python"
when python3_prog.path() was used it return empty string
Christoph Reiter
@lazka
ah, yes, we already had that
Алексей
@Alexpux
is any workaround?
Christoph Reiter
@lazka
revert that patch
would be one
Алексей
@Alexpux
reverting doesnt help
if you look at the header of patch
it describe why it applied
it calculate wrong paths for dependencies files
Christoph Reiter
@lazka
it says to fix rebuilds, but we don't rebuild... but not sure
Алексей
@Alexpux
well rpcgen generate files in build folder
but if i revert patch then it try to find generated files in source folder
Алексей
@Alexpux
like this
src/remote/qemu_protocol.c:7:10: fatal error: ../libvirt-7.0.0/src/remote/qemu_protocol.h: No such file or directory
    7 | #include "../libvirt-7.0.0/src/remote/qemu_protocol.h"
Biswapriyo Nath
@Biswa96
Yes, I get that error from tarball but not from git repo.
Алексей
@Alexpux
@Biswa96 im building 7.0.0-rc1
it released today
Biswapriyo Nath
@Biswa96
Yes, both from v7 and v6.10. After reverting the patch that lazka said. Zero idea about meson though.
Алексей
@Alexpux
yes this is with reverted patch
Алексей
@Alexpux
well i try to build inside source directory then
does meson allow it?
Christoph Reiter
@lazka
Алексей
@Alexpux
?
Christoph Reiter
@lazka
It at tries to build with that
Алексей
@Alexpux
i have this patch locally
Christoph Reiter
@lazka
now it fails with "rpc/rpc.h: No such file or directory"
(I made that patch manually, no revert)
Алексей
@Alexpux
do you have installed rpcsvc-proto and mingw-portablexdr?
Christoph Reiter
@lazka
ah, right, I'll try more
Алексей
@Alexpux
probably problem that src/rpc/genprotocol.pl not fix VPATH correctly
it have
    # Fix VPATH builds
    s,#include ".*/([^/]+)protocol\.h",#include "${1}protocol.h",;
Christoph Reiter
@lazka
now I have undefined reference to 'virNetClientProgramCall'
Алексей
@Alexpux
where it stops?
what build step
Christoph Reiter
@lazka
[1/332] Linking target src/libvirt-admin-0.dll
Алексей
@Alexpux
what version you build?
Christoph Reiter
@lazka
git master
Алексей
@Alexpux
i dont know how you build it but from our PKGBUILD it looks like
Found ninja-1.10.2 at D:\msys64\mingw64\bin/ninja.EXE
[1/775] Generating virt_keycode_atset1 with a custom command (wrapped by meson to capture output)
[2/775] Generating virt_keycode_atset2 with a custom command (wrapped by meson to capture output)
Unai Martinez-Corral
@umarcor
Can someone provide me the link to the discussion about prefixes (mingw-w64-, clang-, etc.)? I can't find it ATM.
Алексей
@Alexpux
@lazka @Biswa96 I pass error with headers now
get other errro
[341/775] Compiling C object tests/libvirgdbusmock.dll.p/virgdbusmock.c.obj
FAILED: tests/libvirgdbusmock.dll.p/virgdbusmock.c.obj
"cc" @tests/libvirgdbusmock.dll.p/virgdbusmock.c.obj.rsp
In file included from ../libvirt-7.0.0/tests/virgdbusmock.c:23:
../libvirt-7.0.0/tests/virgdbusmock.c: In function 'g_dbus_connection_call_sync':
../libvirt-7.0.0/tests/virmock.h:111:29: warning: implicit declaration of function 'dlsym' [-Wimplicit-function-declaration]
  111 |             !(wrap_##name = dlsym(RTLD_DEFAULT, \
      |                             ^~~~~
../libvirt-7.0.0/tests/virgdbusmock.c:57:1: note: in expansion of macro 'VIR_MOCK_LINK_RET_ARGS'
   57 | VIR_MOCK_LINK_RET_ARGS(g_dbus_connection_call_sync,
      | ^~~~~~~~~~~~~~~~~~~~~~
../libvirt-7.0.0/tests/virmock.h:111:29: warning: nested extern declaration of 'dlsym' [-Wnested-externs]
  111 |             !(wrap_##name = dlsym(RTLD_DEFAULT, \
      |                             ^~~~~
../libvirt-7.0.0/tests/virgdbusmock.c:57:1: note: in expansion of macro 'VIR_MOCK_LINK_RET_ARGS'
   57 | VIR_MOCK_LINK_RET_ARGS(g_dbus_connection_call_sync,
      | ^~~~~~~~~~~~~~~~~~~~~~../libvirt-7.0.0/tests/virmock.h:111:35: error: 'RTLD_DEFAULT' undeclared (first use in this function); did you mean 'CW_DEFAULT'?
  111 |             !(wrap_##name = dlsym(RTLD_DEFAULT, \
      |                                   ^~~~~~~~~~~~
Unai Martinez-Corral
@umarcor
Алексей
@Alexpux
probably need dlfcn for building tests
Christoph Reiter
@lazka
meson configure -Dtests=disabled I guess