{"action":"created","issue":{"url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/42","repository_url":"https://api.github.com/repos/pure-data/pd-lib-builder","labels_url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/42/labels{/name}","comments_url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/42/comments","events_url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/42/events","html_url":"https://github.com/pure-data/pd-lib-builder/issues/42","id":293852926,"number":42,"title":"interrelated questions around static linking of 'standard libs' with Mingw","user":{"login":"katjav","id":1105733,"avatar_url":"https://avatars1.githubusercontent.com/u/1105733?v=4","gravatar_id":"","url":"https://api.github.com/users/katjav","html_url":"https://github.com/katjav","followers_url":"https://api.github.com/users/katjav/followers","following_url":"https://api.github.com/users/katjav/following{/other_user}","gists_url":"https://api.github.com/users/katjav/gists{/gist_id}","starred_url":"https://api.github.com/users/katjav/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/katjav/subscriptions","organizations_url":"https://api.github.com/users/katjav/orgs","repos_url":"https://api.github.com/users/katjav/repos","events_url":"https://api.github.com/users/katjav/events{/privacy}","received_events_url":"https://api.github.com/users/katjav/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":42,"created_at":"2018-02-02T11:09:26Z","updated_at":"2018-02-08T20:48:52Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Externals built with Mingw need linking with GNU standard libs. If these aren't provided as dlls by Pd (which is the case with vanilla Pd), an external lib must provide its own solution. Pdlibbuilder implements static linking of standard libs by default, with the effect that externals are in this respect equally 'self-supporting' for all platforms. This arrangement leaves a couple of issues though:\r\n\r\n1. `libpthread` is not included in Mingw standard libs\r\n2. static linking of standard libs makes externals super bloated\r\n3. this bloat is not optional\r\n\r\nIssue 1 means that externals using pthread are not out of the box equally self-supporting on Windows. This could be solved by treating `libpthread` as a standard lib in pdlibbuilder.\r\n\r\nThe importance of issue 2 scales with the number of externals loaded in memory and number of externals distributed in a package. It seems that externals for Windows are roughly 10 times 'too large'. This may be reduced a bit by stripping.\r\n\r\nIssue 3 is particularly annoying for monolithic Pd distributions; even when standard libs are provided as dlls, pdlibbuilder will still build those bloated externals. Therefore pdlibbuilder should support an opt-out.\r\n\r\nI'm thinking how to solve issue 1 and 3 together, by introducing variables defining statically linked 'standard' libs including `libpthread`. Something like:\r\n```\r\n\r\nc.standard.static := -static-libgcc -static -lpthread\r\ncxx.standard.static := -static-libgcc -staticlibc++ -static -lpthread\r\n```\r\n\r\nThese variables should be evaluated last in the command line for the linker, such that `-static` will not affect other libs eventually specified. Not sure if this order of options will work. If it works, a central makefile could easily opt out of static standard libs by defining the variables empty in the call to make.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/comments/364243708","html_url":"https://github.com/pure-data/pd-lib-builder/issues/42#issuecomment-364243708","issue_url":"https://api.github.com/repos/pure-data/pd-lib-builder/issues/42","id":364243708,"user":{"login":"Lucarda","id":25239522,"avatar_url":"https://avatars2.githubusercontent.com/u/25239522?v=4","gravatar_id":"","url":"https://api.github.com/users/Lucarda","html_url":"https://github.com/Lucarda","followers_url":"https://api.github.com/users/Lucarda/followers","following_url":"https://api.github.com/users/Lucarda/following{/other_user}","gists_url":"https://api.github.com/users/Lucarda/gists{/gist_id}","starred_url":"https://api.github.com/users/Lucarda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Lucarda/subscriptions","organizations_url":"https://api.github.com/users/Lucarda/orgs","repos_url":"https://api.github.com/users/Lucarda/repos","events_url":"https://api.github.com/users/Lucarda/events{/privacy}","received_events_url":"https://api.github.com/users/Lucarda/received_events","type":"User","site_admin":false},"created_at":"2018-02-08T20:48:52Z","updated_at":"2018-02-08T20:48:52Z","author_association":"NONE","body":"@katjav  was suggesting to not statically link \"libstdc++\" and friends in Pd, and instead shipping those along Pd.\r\n@danomatika  didn't like it and me either at first, then I thought that future \"libstdc++\" should be backwards compatible so it might work. \r\n\r\nOn #41 we get some clues. Also we had the \"inverse\" situation, a compiled thing on 2018 not working with some old \"libstdc++\".\r\nAlso in this test there was no \"libstdc++\" on pd/bin."}}
{"actor":{"display_login":"Lucarda"}}