X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 3E227DC012D for ; Sun, 19 May 2013 22:40:08 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id m16so2549391qcq.19 for ; Sun, 19 May 2013 15:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Ar6g2rXlrQK4SB4vZOuRJMCWS4FzXEwuhJu8+2+cKBk=; b=G5Qe5PFafmsJxWBhb7fbJfLFpXpJ1j29/DGa11PhPfSjKit1hEoEW28nHCcJiXY+rj 3TeBgvUKb2YK/HY1JuEBqWMhjSD1lPG+3rN8uf8cKqQCs+KfZ4u3/0shahpbYfiUgG0h sRp6y4t4A56CXsLVwffcFowbGS/pcrSSBLRjg5m7wqZkIyHYCRtBu7LsdJlaNC0Zgtyd ZW7CHzg4CnhWf+P24bCuHD6DwLJuFHdY0a8c+V6Zdg2d5xGCz4BFFjKAHGP1e2m2eAn+ BC4voWNrXCDLDvXJvjDlCAeD61H/y7aC/YdYeCQXLAFT0pnRUwaE7DA0n9mWwtV3t14f LaOA== X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 X-Received: by 10.229.162.209 with SMTP id w17mr7499375qcx.42.1369003207596; Sun, 19 May 2013 15:40:07 -0700 (PDT) Received: by 10.49.12.45 with HTTP; Sun, 19 May 2013 15:40:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 19 May 2013 18:40:07 -0400 Message-ID: Subject: [alpine-devel] Re: gnu/libc-version.h From: Brian Knox To: alpine-devel@lists.alpinelinux.org Content-Type: multipart/alternative; boundary=f46d0447866de2a4cc04dd19e5b2 --f46d0447866de2a4cc04dd19e5b2 Content-Type: text/plain; charset=ISO-8859-1 Looking at processinfo_linux2.cpp, it doesn't appear to be using gnu_get_libc_version() (which is provided by gnu/libc-version.h) for anything critical - it's informational data that's not, from any code I can see in mongo, used for any actual decision making. So worst case, I could probably write a patch for mongo that would let me skip the header. However, in general I'm curious about the issue of code that uses gnu/libc-version.h on uclibc for my own education on uclibc. Brian On Sun, May 19, 2013 at 6:31 PM, Brian Knox wrote: > I'm working on a mongodb package for alpine linux and have gotten pretty > far. My compilation is now failing on processinfo_linux2.cpp trying to > include gnu/libc-version.h. > > I'm not that experienced with working with uclibc so I'm looking for a > little advice on how to address this (hopefully without having to resort to > moving to glibc). > > Thanks! > > Brian > --f46d0447866de2a4cc04dd19e5b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Looking at processinfo_linux2.cpp, it doesn'= t appear to be using gnu_get_libc_version() (which is provided=A0 by gnu/li= bc-version.h) for anything critical - it's informational data that'= s not, from any code I can see in mongo, used for any actual decision makin= g.

So worst case, I could probably write a patch for mongo tha= t would let me skip the header.=A0 However, in general I'm curious abou= t the issue of code that uses gnu/libc-version.h on uclibc for my own educa= tion on uclibc.

Brian


On Sun, May 19, 2013 at 6:31 PM, Brian Knox <taotetek@gmail.com= > wrote:
I'm working o= n a mongodb package for alpine linux and have gotten pretty far.=A0 My comp= ilation is now failing on processinfo_linux2.cpp trying to include gnu/libc= -version.h.

I'm not that experienced with working with uclibc so I'm = looking for a little advice on how to address this (hopefully without havin= g to resort to moving to glibc).

Thanks!

Bri= an

--f46d0447866de2a4cc04dd19e5b2-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---