02:18:22 <MeowingCat> im debugging Godot's DLL loading
02:21:41 <MeowingCat> looooks like when i link wallet2 my DLL's GDNative init functions don't exist
02:36:14 <MeowingCat> it is really interesting because if i link wallet2 things statically to my DLL Godot can't find the symbol "godot_gdnative_init"
02:36:36 <MeowingCat> how linking something to my DLL could cause an issue like thiss??
02:53:53 <MeowingCat> p_symbol_handle = (void *)GetProcAddress((HMODULE)p_library_handle, p_name.utf8().get_data());
02:54:00 <MeowingCat> GetProcAddress() is a Windows thing
02:54:28 <MeowingCat> returns function address by name
03:00:49 <MeowingCat> "objdump -p build/libgdmeowletxmr.dll |grep godot_gdnative_init" returning nothing
03:00:55 <MeowingCat> when i link wallet2 to DLL
03:06:08 <MeowingCat>         [11039] _ZN5godot5Godot13gdnative_initEP27godot_gdnative_init_options
03:06:08 <MeowingCat>         [19637] godot_gdnative_init
03:06:22 <MeowingCat> i seee them when i don't link wallet2 to my DLL
03:06:49 <MeowingCat> i really don't have an idea how could linking wallet2 cause this issue
08:34:49 <r4v3r23[m]> https://github.com/monero-project/monero/issues/5810
08:34:51 <r4v3r23[m]> is this still relevant?
12:52:11 <selsta> r4v3r23[m]: relevant in what way? there is still a 10 block lock yes
13:46:32 * willshu[m] uploaded an image: (40KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/ZNDjdbWggSPYVHZHYgbaqdym/middle_img_v2_bfc7db79-e0e0-41dd-beb8-2f6cb913ea7h.jpg >
13:47:18 <willshu[m]> Hello, I request `export_outputs` with `all: true`. Why is the payload a little different each time?
13:47:27 <willshu[m]> To a view-only wallet
18:24:22 <r4v3r23[m]> <selsta> "r4v3r23: relevant in what way..." <- relevant as a way to reduce/remove the lock?
19:22:16 <ofrnxmr[m]1> r4v3r23:  https://github.com/monero-project/research-lab/issues/102
19:43:49 <MeowingCat> i solved damn issueeeeee
19:44:23 <MeowingCat> Godot's GDN_EXPORT macro definition is expanding to __declspec(dllexport) on Windows buttttt somehowwwwww it was not expanding to __declspec(dllexport) when i link wallet2 thingsssssssssssssssssssssss
20:54:18 <MeowingCat> how could damn linked libraries cause changing damn GDN_EXPORT macro??
21:00:01 <ooo123ooo1234567> <MeowingCat> "how could damn linked libraries..." <- order of includes ?
21:00:12 <ooo123ooo1234567> > <@MeowingCat:libera.chat> how could damn linked libraries cause changing damn GDN_EXPORT macro??
21:00:12 <ooo123ooo1234567>  * order of `#include <...>` ?
21:00:25 <ooo123ooo1234567>  * order of `#include <...>` or gcc/g++ compilation flags ?
21:00:39 <MeowingCat> ummmmm i don't think so
21:00:47 <MeowingCat> im always passing all static libraries to GCC
21:00:56 <MeowingCat> when i use something from wallet2 it links
21:01:10 <MeowingCat> it is just touching GDN_EXPORT macro somehow
21:01:31 <MeowingCat> "#include"s are same
21:01:58 <MeowingCat> just when i use something from wallet2 it links and GDN_MACRO is changing or removing or being something strange
21:02:20 <ooo123ooo1234567> macros and linking are separate stages of compilation
21:02:30 <MeowingCat> extern "C" void GDN_EXPORT godot_gdnative_init(godot_gdnative_init_options *o)
21:02:33 <MeowingCat> i just replaced this to
21:02:34 <ooo123ooo1234567> * macros expansion and linking, * of compilation, there is some error in your conclusion
21:02:34 <MeowingCat> extern "C" void __declspec(dllexport) godot_gdnative_init(godot_gdnative_init_options *o)
21:02:38 <MeowingCat> and working nowww
21:02:53 <ooo123ooo1234567> * macros expansion and linking, * of compilation, there is some error in your statements
21:03:32 <MeowingCat> when i use GDN_EXPORT and don't use wallet2 things in my code (my GCC command and passed static libraries are always same)
21:03:51 <MeowingCat> GDN_EXPORT is correct "__declspec(dllexport)"
21:04:21 <MeowingCat> but when i use wallet2 things (wallet2 things are being linked) GDN_EXPORT is just affecting somehow
21:04:41 <MeowingCat> because i replaced it to "__declspec(dllexport)" and it is working
21:04:58 <MeowingCat> i mean now my DLL contains export functions
21:05:18 <MeowingCat> even wallet2 and its dependencies are linked
21:05:52 <MeowingCat> something was breaking/doing something to damn macro
21:06:31 <ooo123ooo1234567> MeowingCat: How to reproduce ?
21:06:38 <MeowingCat> ohhh
21:06:42 <MeowingCat> i think it must be simple
21:06:51 <MeowingCat> just define a GDN_EXPORT macro
21:07:08 <MeowingCat> when you link wallet2 things it will just got broken
21:07:19 <ooo123ooo1234567> MeowingCat: it will just hide some problem which will appear later again
21:07:41 <MeowingCat> how could this be possible?
21:07:46 <MeowingCat> or what could be the reason?
21:07:59 <ooo123ooo1234567> share your code if you need answer
21:08:09 <ooo123ooo1234567> or at least minimum reproduction
21:08:40 <MeowingCat> the app will be open source
21:09:03 <ooo123ooo1234567> MeowingCat: do you need answer now or later ?
21:09:12 <MeowingCat> im really curious
21:09:19 <MeowingCat> what is touching to damn macro
21:09:25 <MeowingCat> and how could that be possible
21:10:22 <MeowingCat> i will try something
21:11:14 <MeowingCat> is there a compile-time logger in GCC?
21:11:19 <MeowingCat> that i could seeeeee macros
21:12:04 <MeowingCat> Godot headers must be checking the platform to define GDN_EXPORT
21:12:23 <MeowingCat> i think wallet2 or one of its dependencies is changing damn platform macro definition
21:12:25 <MeowingCat> or something like that
21:12:55 <MeowingCat> this is really interesting
21:15:36 <MeowingCat> #ifdef __GNUC__
21:15:36 <MeowingCat> #define GDN_EXPORT __attribute__((visibility("default")))
21:15:36 <MeowingCat> #elif defined(_WIN32)
21:15:36 <MeowingCat> #define GDN_EXPORT __declspec(dllexport)
21:15:36 <MeowingCat> #else
21:15:37 <MeowingCat> #define GDN_EXPORT
21:15:39 <MeowingCat> #endif
21:15:43 <MeowingCat> this is the definition of GDN_EXPORT
21:16:06 <MeowingCat> something might be changing _WIN32????
21:16:44 <ooo123ooo1234567> <MeowingCat> "is there a compile-time logger..." <- `g++ -E -dI ...`
21:17:01 <MeowingCat> ohhh it is goooooooood
21:17:04 <MeowingCat> trying
21:17:31 <ooo123ooo1234567> > <@MeowingCat:libera.chat> is there a compile-time logger in GCC?
21:17:31 <ooo123ooo1234567>  * `g++ -E -dM ...`
21:17:39 <ooo123ooo1234567> search for -dM in `man g++`
21:18:31 <ooo123ooo1234567> it's likely a problem in your code / godot code / wallet2 code, not clear which one to blaim
21:25:15 <ooo123ooo1234567> <MeowingCat> "i think wallet2 or one of its..." <- it could be also a problem in msys
21:25:25 <MeowingCat> ummmm yessssss maybeeee
21:25:39 <MeowingCat> this options don't log anything
21:25:42 <MeowingCat> im gonna try something
21:26:04 <ooo123ooo1234567> paste exact cmd you're using (via paste.debian.net)
21:27:14 <ooo123ooo1234567> `g++ -std=c++11 -E -dD /tmp/test.cpp | vim -` it works as expected here
21:29:24 <moneromooo> Can you stop spamming please. This is not your debugging step by step log dump.
21:35:32 <MeowingCat> #define MEOWW() std::cout << "Value: " #GDN_EXPORT << std::endl;
21:35:45 <MeowingCat> interesting because GCC says there is no GDN_EXPORT
21:39:37 <MeowingCat> i think # operator must be working for string macros
21:39:52 <MeowingCat> im using that for macros like #define meow "..."
21:40:13 <ooo123ooo1234567> `#define MEOWW() std::cout << "Value: " << GDN_EXPORT << std::endl;`
21:40:15 <MeowingCat> i should insert damn macro into "" in compile-time
21:40:22 <MeowingCat> ohhh noooo
21:40:25 <MeowingCat> it doesn't work
21:40:36 <MeowingCat> because GDN_EXPORT is not a " ... "
21:40:46 <moneromooo> Well, to the /ignore list then.
21:41:30 <MeowingCat> i should insert GDN_EXPORT into "" i can't just do "GDN_EXPORT" because lexer will understand it as a string
21:45:04 <MeowingCat> GCC lexer got crazy lol
21:45:04 <ooo123ooo1234567> `g++ -std=c++11 -E -dD /tmp/test.cpp | vim -` just start it with the file which is supposed to have that macro and check log
21:51:35 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L707, https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L797; there are only 2 places where something related to _WIN32 is defined in monero repo
21:55:23 <ooo123ooo1234567> it's likely not wallet2 problem
21:59:27 <MeowingCat> ooo123ooo1234567, i found something
22:04:24 <ooo123ooo1234567> is it a solution or a new problem ?
22:36:52 <MeowingCat> i can confirm that it is always #define GDN_EXPORT __attribute__((visibility("default")))
22:37:36 <MeowingCat> this means when i export my functions with "__attribute__((visibility("default")))" DLL includes them if i don't link wallet2, but doesn't include them if i link walet2
22:38:15 <MeowingCat> if i use "__declspec(dllexport)" it works always
22:39:11 <MeowingCat> ooo123ooo1234567, what do you think about this??
22:44:54 <ooo123ooo1234567> rip windows
23:03:23 <ooo123ooo1234567> together with it's users
23:19:43 <ooo123ooo1234567> default visibility depends on library during linking stage (wallet2 triggers it somehow)
23:19:44 <ooo123ooo1234567> * it means default visibility
23:52:59 <AmAguestHello> o/
23:54:31 <AmAguestHello> this is prob a question for Trezor, but does anyone know if there is support for XMR on the Trezor model 1 coming?