04:00:56 FYI, I created a room for non-core related dev discussions. Newbs welcome: #monero-community-dev:monero.social 06:49:34 i have a very important question 06:50:03 how do you build Monero? 06:50:29 i built it with MSYS2/Mingw64 06:50:30 Refer the steps in the README. 06:50:37 nooooo i mean 06:50:53 how do you build it for different targets 06:51:00 do you do cross-compiling 06:51:17 or do you build it on target platforms individually 06:51:27 Refer the steps in contrib/gitian/README.md 06:52:09 loooooking 06:52:16 i wanna ask: 06:52:32 is it possible to cross-compile Monero? 06:52:38 and did you ever do that? 06:52:52 Refer the steps in contrib/gitian/README.md first. 06:52:57 to the steps 06:53:47 you mean it is pretty possible? 06:54:33 This is what the file above is about. That's what I said refer to it. 06:54:38 niceeeeeee 06:59:12 which static object can/should i use from Monero build? 07:00:12 "Refer the steps in contrib/..." <- ^ 07:01:01 i already built for Windows 07:01:20 i need to use Monero functions 07:01:36 "Refer the steps in contrib/..." <- ^ 07:01:56 MeowingCat: Such as 07:02:06 i should statically link the required objects to my GDNative library 07:02:38 or if it is possible to get some dynamic libraries 07:02:47 i can use that too 07:03:19 ofrnxmr[m]: Did you ^ 07:03:39 "Refer the steps in contrib/..." <- Did you ^ ** 07:04:12 :((((((((( i willlll look but i already have Windows build 07:05:02 i have libwallet.a, libwallet_merged.a, libmonero-wallet-rpc.dll.a 07:05:15 what are libwallt.a and libwallet_merged.a?? 07:05:17 "Refer the steps in contrib/..." <- So thats a no? Come back after you ^ please 07:05:32 are you joking???????????? 07:06:05 i tried to link libwalet.a before 07:06:18 butttt headers and non-relative include paths are crazy 07:06:53 and must be tons of compiler parameters that are requried to compile Monero successfully 07:07:50 normally i had to be able to statically link libwallet.a and include Monero headers 07:07:52 and use it easily 07:07:57 Of course not. 07:07:57 What is your goal? What are you trying to do? Cross compile ? Thats all? 07:07:57 If you havent read the documentation youve been pointed to.. no, im nit joking 07:08:20 i will cross-compile tooo because i need Windows, Android, iOS builds 07:08:51 but first i will use Monero functions i already built Monero for Windows 07:09:25 Monerod builds/works for ios? 07:09:33 the only thing that i need libwallet.a and headers i have libwallet.a and i have headers tooo 07:09:37 but headers are crazy 07:09:53 "monerod" sounds like a daemon 07:10:01 i don't need a daemon 07:10:11 i just need to build and sign transactions 07:10:20 you all said it is impossibly difficult 07:10:35 and the only way is using Monero's itself 07:10:51 i don't even need address derivation functions from Monero 07:10:55 i made it in C# 07:11:32 do you have dynamic libraries that contain transaction building/signing functionalities for Windows, Android, iOS 07:11:41 moneromooo: looks like I fixed their keyboard 07:11:49 i mean built dynamic libraries 07:12:18 if someone has that please send me :(( 07:12:57 Ive never attempted to build for ios. I use gitian for androin, Linux, mac etc 07:13:28 okii but now i need to link libwallet.a to my thing 07:17:31 what is the difference between libwallet.a and libwallet_merged.a??? 07:17:55 does "merged" mean something like portable version???? 07:19:17 and includes everything required? 07:58:34 "merged" means all the libs at once, the wallet and it dependencies. 07:58:49 wallet2 is what has the tx building/signing code. 07:59:06 If you can call that from C#. 08:18:06 moneromooo, do i need libwallet.a or libwallet_merged.a for only transaction building and signing? 08:21:09 alo 08:21:30 anyone to help me with monero OTC? :) 08:30:13 "anyone to help me with monero..." <- #monero:monero.social 08:35:17 Either would do. 08:39:28 Mooooooooooooneroooo 08:40:49 #monero:monero.social is quiet af too 08:40:51 lmaooo 08:57:06 "#monero:monero.social is quiet..." <- People too busy reverse engineering wallet2.cpp spaghetti code no time for chatting. 08:57:22 based 09:01:39 Stnby[m], wallet2.cppppp 09:01:43 the besttttttttt 09:02:11 we need a wallet3.cpp 09:32:39 "the besttttttttt" <- Just beautiful 09:33:20 damnnnn i should ask this 09:33:27 Stnby[m], are you using Discord??? 09:33:39 Hell no 09:33:48 No Pedochat 09:33:54 is this place bridged to Discord? 09:34:14 I have no idea, if it was why would you use Monero 09:34:25 If thats how much you value your privacy 09:34:33 i don't use Moneroooooo 09:34:42 just adding Monero support to our wallet apppp 09:34:43 Also this is dev we should talk this elsewhere 09:35:15 why i can't write here on Discord? 09:35:16 * this elsewhere #monero 09:40:44 Just a quick test, can you guys read this ? 09:40:53 Yes. 09:41:17 thanks, moo. 15:05:13 im trying to use Monero::WalletManager 15:05:35 im including wallet2_api.h and linking libwallet_merged.a 15:05:57 buttt linker is saying undefined reference to `Monero::WalletManagerFactory::getWalletManager()' 15:06:22 isn't this thing placed in libwallet_merged.a??? 15:07:34 g++ -o monero_api.exe libwallet_merged.a monero_api.cpp 15:07:37 im doing thiss 15:17:11 Place libwallet_merged.a after monero_api.cpp. 15:21:51 ohh tried already 15:22:49 damnnnn it works i tried it with Linux build and i figured out that im trying to link wrong build 15:23:04 it is linking 15:23:16 moneromooo, tyyyyyy 15:33:52 linking is taking huuuuuuuuuuuge time 15:33:59 is there a solution for that??? 15:42:10 A faster CPU. 15:44:00 BTW, what you are using here (Monero::WalletManagerFactory::getWalletManager) is part of an API layer above wallet2. Using it is fine, but it's a bit of a useless layer. 15:44:39 It's here for historical reasons, and likely won't go since other people use it now, but just so you know. You have a choice between this and wallet2 itself. 15:45:39 you mean there is another interface for same purpose? 15:45:55 Actually, maybe not useless, I think it might have some async stuff, which could be useful... 15:46:32 my CPU is i7 10750h 15:46:44 i can't do anything to make linking faster? 15:47:15 Well, check top to see what's the bottleneck, but I doubt it'll be I/O here. 15:48:04 ummmm my SSD is very fast :( 15:48:11 maybe about MSYS2? 16:03:31 still linking 16:10:11 You mean... the same linking process ? For 40 minutes ? 16:10:17 yesssss 16:10:29 WTF. OK, something *is* wrong. 16:10:31 just libwallet_merged.a 16:10:33 :(((((((( 16:10:52 Check top, is ld taking 100% CPU ? 16:11:08 C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libwallet_merged.a(wallet2.cpp.obj):wallet2.cpp:(.text$_ZN5boost13serialization9singletonINS_7archive6detail11iserializerINS2_24portable_binary_iarchiveESt13unordered_mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESC_St4hashISC_ESt8equal_toISC_ESaISt4pairIKSC_SC_EEEEEE18get_const_instanceEv[_ZN5boost13serialization9singletonINS_7archive6 16:11:08 detail11iserializerINS2_24portable_binary_iarchiveESt13unordered_mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESC_St4hashISC_ESt8equal_toISC_ESaISt4pairIKSC_SC_EEEEEE18get_const_instanceEv]+0xc0): undefined reference to `boost::serialization::typeid_system::extended_type_info_typeid_0::extended_type_info_typeid_0(char const*)' 16:11:21 i used --verbose and i see these 16:11:49 Ah, use g++, not gcc, to compile/link. 16:11:52 ld.exe using %16 CPU 16:12:17 Does top have a large value in the wa% column, near the top of the screen ? 16:12:24 i used g++ already :(( 16:12:44 Ah you did, sorry. Misremembered. 16:13:04 You need to link agianst all the boost libs then. I guess they're not merged in libwallet_merged.a... 16:13:15 See the list in one of the CMakeLists.txt files. 16:13:27 i built monero repo 16:13:28 program_optoins, thread, chrono, etc. All the lot of them. In the same order. 16:13:36 and got libwallet_merged.a 16:14:50 what should i look for in CMakeLists.txt?? 16:17:29 you mean ld is linking boost things because they are not in libwallet_merged.a? 16:17:30 program_optoins, thread, chrono, etc. All the lot of them. In the same order. 16:17:40 okii loooking 16:18:36 You could do a lot worse than running the monero-wallet-rpc link with VERBOSE=1, then copying as much as possible which libs are in. 16:20:37 i feel like it may be because of tooo much different files 16:21:16 SSDs are working slow for too much files 16:24:31 find_package(Boost 1.58 QUIET REQUIRED COMPONENTS system filesystem thread date_time chrono regex serialization program_options locale) 16:24:50 this line in CMakeLists.txt 16:26:21 ohhh linker is saying "undefined reference to ..."s 16:30:04 where are damn boost static libraries 16:30:16 i should find them 16:31:09 https://packages.msys2.org/package/mingw-w64-x86_64-boost 16:32:35 there is something wrong 16:41:14 x86_64-w64-mingw32/bin/ld.exe: ../../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a(wallet_manager.cpp.obj):wallet_manager:(.text+0x12691): undefined reference to `el::base::Storage::getELPP()', 16:41:20 errors like this 16:44:45 is libwallet_merged.a supposed to contain everything?? 16:45:52 MeowingCat: no 16:46:03 libwallet_api.a does contain everything 16:46:28 i built Monero 16:46:28 that's why we switched to _api for the gui as it makes things easier 16:46:47 and im passing libwallet_merged.a to link to GCC 16:47:14 what should i pass else? 16:47:23 to link 16:47:35 ld can't find tons of things 16:48:04 https://github.com/monero-project/monero-gui/pull/3448/files 16:48:47 i just found there is a wallet2_api.h and it is independent 16:48:56 selsta, tyyy loooking 16:49:35 what is "wallet_api"?? 16:49:45 what does that mean in CMakeLists.txt? 16:52:07 https://github.com/monero-project/monero/blob/9a124f681119855949f6406ecd69c2ad91da9770/src/wallet/api/CMakeLists.txt#L66 16:52:20 :(((((( 16:52:45 oh these static libraries i should link? 16:53:36 where are these static objects? 16:54:08 does a libwallet_api file exist? 16:55:55 loooking at find . -regex ".+\.a" 16:56:44 noooo there is no anything like "libwallet_api" 16:57:41 https://github.com/monero-project/monero/blob/9a124f681119855949f6406ecd69c2ad91da9770/src/wallet/api/CMakeLists.txt 16:57:55 remove line 85 and 86 16:58:30 but i'm just guessing here, if you use CMake you could just copy the CMake code from the GUI 17:00:52 i made g++ -o monero_api.exe monero_api.cpp ../../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a $(find ../../monero -regex ".+\.a" -printf "%p ") --verbose 17:01:10 but still saying "undefined reference to"s 17:02:07 loookingg 17:02:22 set_property(TARGET wallet_api PROPERTY EXCLUDE_FROM_ALL TRUE) 17:02:35 oh this thing is removing that thing???? 17:02:37 whyyyyyyy 17:02:57 encapsulation concept should not exist in universe 17:02:58 :(((( 17:03:32 Because it's rebuilt every time wallet2.h changes, very slowly, and it's unused by monero itself, just by the GUI and so you have no idea if any changes there work or not anyway. 17:03:38 It really doesn't belong in this repo. 17:03:56 So I took if out by default, it was wasting my time so much. 17:04:00 im crying 17:04:09 gonna rebuild now 17:04:13 without that lines 17:04:28 I think libwallet_merged.a does include it fwiw. 17:04:58 oh noooooooooooo 17:05:07 then it doesn't mean anything 17:05:32 buttt why there are undefined reference errors :((((( 17:08:07 this thing made me crazy really 17:14:46 hi 17:15:15 it seems google have merged libgtest-dev into google test? 17:16:42 ok found it 17:17:52 i have libwallet_api.a nowwwww 17:18:20 MeowingCat: did removing 85 86 work? 17:18:30 yesss 17:18:51 buttt still undefined reference errors when i link libwallet_api.a 17:19:05 what undefined references? 17:19:23 ld.exe: ../../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_api.a(wallet_manager.cpp.obj):wallet_manager:(.text+0x12769): undefined reference to `el::base::Writer::construct(char const*)' 17:19:27 like this 17:19:59 That's easylogging++. Use git grep. 17:20:09 you have to link against easylogging 17:20:09 yes 17:23:27 there are too many errors for different things 17:23:27 ld.exe: ../../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_api.a(wallet_manager.cpp.obj):wallet_manager:(.text+0x17fcc): undefined reference to `__stack_chk_fail 17:23:51 im linking all *.a in monero/ 17:23:53 g++ -o monero_api.exe monero_api.cpp ../../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_api.a $(find ../../monero -regex ".+\.a" -printf "%p ") --verbose 17:24:50 i think i need a GCC command that is created by CMake for Monero 17:24:55 to link everything 17:25:20 That's why it would be easier to use CMake. You can do the same as monero-gui repo and everything should work. 17:25:35 ld is a single pass linker, you want the order right. 17:26:10 then im gonna use CMake 17:26:37 __stack_chk_fail suggests you compiled some of the source with different code gen options than others. Not 100% sure. 17:27:24 I'm sure you've been looking up those symbols in a search engine anyway. 17:29:28 there is a mistake in official monero cli tutorial 17:29:47 sudo should never be used when compling libraries Xd 17:30:20 [1] On Debian/Ubuntu libgtest-dev only includes sources and headers. You must build the library binary manually. This can be done with the following command sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make then: 17:30:24 wrong 17:31:23 Violent. Please PR a patch. 17:33:06 I found it. I can do it if you like, or you can have a patch in monero :) 18:10:31 moneromooo, just did "make release-static-win64" for Monero source 18:18:24 dudes who here complied google test lib from scratch? 18:18:44 I did it got libs, however do I need stuff in /include? 18:26:12 jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others introduced ? 18:26:32 * no others were introduced ? 18:29:19 this is sufficient requirement to merge patch ^ 18:33:30 add_subdirectory(../monero) 18:33:33 is this enough? 18:33:44 for my CMakeLists.txt?? 18:37:03 MeowingCat: easier to test than to ask 18:41:19 jeffro256 for once I agree with ooo123, deprecated methods are not relevant for this PR review. As selsta commented there somewhere, boost 1.59 is still supported in Monero code, so we can use these methods. 18:41:20 "https://github.com/monero-project/monero/pull/7760#discussion_r889421565", "potentially infinite while loop" potentially shallow comment 18:41:53 sech1, hello 18:42:45 jeffro256: also my next approximation was supposed to touch connection + boost server + node_server + cryptonote_protocol, but I stopped since no one even able to check small connection patch 18:44:51 ooo123ooo1234567 I will do a proper review (correctness of code logic) soon, right now I'm fighting with adding curl to p2pool, so I don't have time for review 18:54:56 "ooo123ooo1234567 I will do a..." <- why do you need curl in p2pool ? 18:55:16 https://github.com/SChernykh/p2pool/issues/41#issuecomment-1145600405 18:59:29 It's basically working on Windows and Ubuntu already, I just need to figure out how to link libcurl statically for all the various p2pool builds (not an easy task) 19:08:58 Ugh. This stuff in the README is building stuff in /usr/src :S 19:09:20 That's why it needs sudo. It'd need to create a build dir somewhere in /tmp or so, and build there. 19:10:13 I'm not even sure why that'd work, unless building also installs stuff, or something includes from /usr/src. This is very icky/ 19:10:24 * moneromooo not touching that now 20:22:44 "It's basically working on..." <- "https://everything.curl.dev/build/autotools#static-linking", "... you need to prepare yourself for an uphill battle." indeed, not an easy task 20:24:11 that's why it doesn't make sense to support pseudo static build in cmake since it doesn't make sense without knowledge of particular environment which will be used for compilation 20:27:21 I don't need ssl and many other features of curl, so I can just turn them off when compiling libcurl.a 20:27:34 Already built fully static binary on Alpine Linux 20:27:39 * that's why it doesn't make sense to support pseudo static build in cmake since fully static build requires knowledge of particular environment which will be used for compilation; and without such knowledge it isn't complete 20:27:42 and "static" binary on Windows (dependent only on system DLLs) 20:28:33 and "kind of static" on Ubuntu (libcurl, libuv, libzmq linked statically, only system .so dependencies) 20:28:50 mingw64 is pita though 20:28:56 can't build there at all so far 20:30:28 sech1: In theory, someone could wrap such fully static builds in docker to make life easier for others 20:31:15 sech1: you have to learn all dependencies of this lib in each environment in order to include all of them statically; pure pain without any benefits except env knowledge 20:31:38 libcurl has ./configure script which can turn off everything 20:31:55 only basic http requests will be left which is what I actually need 20:32:11 so I can build libcurl.a which doesn't need other dependencies 20:32:53 I hope http digest authetication will not require some obscure dependency :D 20:36:08 sech1: so you're training in finding all dependencies before proper PR review, kind of warm up 20:39:39 "I hope http digest authetication..." <- the same task in cryptography would be: checking that all security dependencies are covered with some known hard problems 20:39:57 in all cases you're learning graph of dependencies and then checking something, but cryptography is at least useful work 20:41:02 though some auditors are doing shallow checks even in cryptography, while others are doing deep check in build dependencies; facepalm 20:44:09 hmm, auditors are limiting scope of work since it directly affects amount work, isn't it a proof that shallow comments have 0 value ? 21:31:05 sech1: should the rng patch be closed? 21:31:27 jeffro256: "https://github.com/monero-project/monero/pull/7760/files#r889445157", deep pain introduced by boost developers with the best readability and code style 21:31:56 selsta I'm more in favor of removing the rng completely from there, so yeah it's better to close it 21:35:18 sech1, did you see this https://github.com/ithewei/libhv, another async i/o lib ? 21:38:49 No 21:39:47 Switching away from libuv means rewriting everything, not an option. Plus libuv is much more widely used and battle tested 21:39:55 that's solo project 21:40:20 sech1: yes, async i/o is everywhere the same, no matter what lib you're using 21:41:35 details are different, apis have different names, parameters etc. Every libuv call needs to be translated 21:43:21 sech1: pain with curl dependencies vs pain of deep reintegration, 1st one less hurts probably 21:44:57 sech1: In theory, It could be possible just to borrow http protocol part, but probably not this case, due to big difference 21:45:11 s/,// 21:45:54 libhv even doesn't have what I need (http authentication) 22:04:14 "details are different, apis have..." <- Did you try to write the same network app with different frameworks ?