From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id AF1206BE0C for ; Mon, 25 Mar 2019 15:47:39 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id x2PFl4kt010777 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2019 08:47:14 -0700 Received: from soho-mhatle-m.local (172.25.36.229) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.439.0; Mon, 25 Mar 2019 08:46:53 -0700 To: =?UTF-8?Q?Andreas_M=c3=bcller?= , Patches and discussions about the oe-core layer , Khem Raj References: From: Mark Hatle Openpgp: preference=signencrypt Autocrypt: addr=mark.hatle@windriver.com; prefer-encrypt=mutual; keydata= mQENBFYKxFgBCACt/pzutBp6p/xVKTFJjHbM3KpQKCblyot/YP+bpTr51Hrc5xDXBQhoG7TC aIRvRIvbhEevEQK9y04gW3JK/5lobq5ORebolcsHlYBUvpNeIPjupLQwGvz/TPtrLRNGLqDC rvsM6OA2XbQ2bwzxWaSQS3ImE2O2iXOZn9HhThMGeDB4Nff3fgUvXOTDIrgWOn9K2DgLL7Yc zkUIlFdj+Nraksd/7BSk8oH6tjeBVhFqSFvKta9QxWgdr58oPaTYaW/xNqUjlLrbJuMw/MSe xzuYfdfDfm6J8kRjMOnwQ0n8svJElzqAk+d83ow38gpGQ+LkjGgnf8ZFJ4rUJFADroX3ABEB AAG0JU1hcmsgSGF0bGUgPG1hcmsuaGF0bGVAd2luZHJpdmVyLmNvbT6JATcEEwEIACEFAlYK xFgCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQfv796/r0vvlvZAf9Gs+eN320yhRW V/fZCsngKhmOK4v3HrTwFrkSmoD9QHQiE/5IPdNacHwIPwZx07tNBohB8xOeNqCPRYRBwGhA AnxKOPyd0nnm6ZhPzbA57v4x3IGRQr4QzvcBTASJq91l3Ew4lpAslyx5w1DPPqRD7G8ycDKg peKyDwmdkvCunVisSAQI3XIMq2y230biTO98tDPEezg+lg+yTsz9ZT33F5KNuWrpf8VL5fG/ mt+kAv7wtsx/KTRbqhH3iFXF6eBSwMjAfTXFlkLfbM9riJGXrWEl9n2S2R3cDHNHug0lb8f4 whK370KEO4OwRKIYW/VUBmzk5XZUE9DTlDSV8ycsrrkBDQRWCsRYAQgAwK3FuHCE+HW3YWdH PUjeSn5p//xJ57u8g2rng8zm9zNjmYgpPv5UxozaD9i2jf4mlQLHGGOezhHae8K4Nj70oVcv 8AmwcrJa9i9WL1oy/9R3fHMWf/Ctt9VXTO0qlCuq6PDzaUfvsXR61aJIjTKNQTOjCLjY1vXm VSewUgARysmA8WrjTfwGBihMBxAX0+kIjx8nOlam0WvekMBXZ0AbS56oTLRxYao6DI3GeB/N oWPy/5DfuTKaSdM0Pf8al20x9RuNN5/HLMlyDH/k8bIa1xd9aAqW+Feiw5gC107V2E6ULyIy q6em2UrsmIRxrvpHqbNgQKqvTehJ+V/i4g/uOwARAQABiQEfBBgBCAAJBQJWCsRYAhsMAAoJ EH7+/ev69L755XAH/3ZcNhooqd9OBhFkvXm1iWZ8EoC7motWqVn2oEyxoonsg8AD9kFXiN+T dYp7dH99EZu9q4ptj56AXm4uHzOgywL/5/V2TY6twCGAjUGzDjAB5gzoi+JLIBlDiyOip0eL QswIhRk473xy3j8DA4oVamnSPWgyNJ+qsdt37YWDzoDFFvtDoRU7Eb+znfIMDKzlny0XU/8L cW1bNHJlpv/78GPdfP4tjysEd8MuA5jf5o5w4XqcwTqalffEJtQ/s3pbkstEi7qm5uPui5Kt gq6YYLSqcSNe0GWAF9/T+qwyo7burSTxUWCWtMmlXdAQLW9SynLhB3Jbch0nFAh0fCKi6yY= Organization: Wind River Systems Message-ID: Date: Mon, 25 Mar 2019 10:46:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Subject: Re: musl thoughts X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:47:39 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit On 3/21/19 8:11 PM, Andreas Müller wrote: > Just prepared meta-networking/networkmanager update and spent hours to > get musl patches applied. Have no idea if musl will build and > currently all my machines are building. > > For me - not using musl and looking forward to have a beer with Khem > explaining me why I should want musl [1] - it is just useless effort > and patches are rejected often due to failures on musl build. > > So on my way home I though about the options I see to handle musl specifics: > > 1. Continue as we do - patch recipe-wise: This is lots of efforts and > requires resources we don't have. Most patches are created by Khem and > it would be better for all of us to save his time for other tasks. > 2. Sending musl related patches upstream: Surely the cleanest approach > but even more effort because upstream maintainers all have different > thoughts. Some of them might hear of musl for the first time and are > possibly not keen on patches they do not see a need for. > 3. Change our musl slightly: Many patches we currently have are > trivial. Missing headers or #defines for missing functions... So if we > add few headers > * Empty chunks for e.g > * Add defines as #define strndupa(x,s) strncpy(alloca(strlen(x)+1),x,s) > * ... > > As you might guess I'd prefer 3 because: > + Many patches can go and don't need maintenance on upstream refactoring anymore > + Burden for people sending patches would be reduced > + Recipes not building with musl currently might work without further > modification > + Just in case musl stops (we have seen this before with others e.g > ulibc) the cleanup would be reduced > > Of course there are disadvantages: > - We turn musl into glibc direction. Posix-purists do not like that. > - Configuration scripts already aware of musl and deciding upon the > existence of headers missing in musl might do the wrong thing > - ? > > Some other ideas? I'm late jumping into this.. but for things that may not build due to inherent expectations from glibc... you could just block the package if "not-glibc" is enabled. You could do this something like: BLACKLISTMSG = "This package only works with glibc." BLACKLISTMSG_libc-glibc = "" PNBLACKLIST[${PN}] = "${BLACKLISTMSG}" (I'm sure there is a cleaner way -- but the point is, if the package says sorry -- I don't work with musl -- that is much more preferable to bitbake parses, unpacks, patches, starts to build and explodes with no explanation...) --Mark > Andreas > > [1] http://lists.openembedded.org/pipermail/openembedded-devel/2018-March/193521.html >