From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] trousers: fix build issue with musl
Date: Sat, 20 Aug 2016 14:41:39 +0200 [thread overview]
Message-ID: <20160820144139.77d3e36a@free-electrons.com> (raw)
In-Reply-To: <1471694164-2094-1-git-send-email-rahul.bedarkar@imgtec.com>
Hello,
On Sat, 20 Aug 2016 17:26:04 +0530, Rahul Bedarkar wrote:
> With musl C library, we get following build error when building trousers:
>
> tsp_tcsi_param.c:14:28: fatal error: bits/local_lim.h: No such file or directory
> #include <bits/local_lim.h>
> ^
> compilation terminated.
>
> Header <bits/local_lim.h> is not available in musl. tsp_tcsi_param.c
> uses this for macro HOST_NAME_MAX.
>
> This patch add support for checking presence of header <bits/local_lim.h>.
> And based on that we include it or define macro HOST_NAME_MAX to 64 if
> it is not already defined.
>
> Value 64 is chosen because <bits/local_lim.h> also uses same value.
This seems like the wrong approach to fix the problem. Indeed, musl
does have a definition of HOST_NAME_MAX, except it's in <limits.h>.
uClibc and glibc also have HOST_NAME_MAX defined when <limits.h> is
included, so the right fix is to drop completely the <bits/local_lim.h>
inclusion, and include <limits.h> instead.
I've tested the following program:
==
#include <limits.h>
#include <stdio.h>
int main(void)
{
printf("%d\n", HOST_NAME_MAX);
return 0;
}
==
and it builds fine with glibc, uClibc and musl.
Could you rework your patch accordingly, and also submit the patch
upstream to the trousers project?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-08-20 12:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-20 11:56 [Buildroot] [PATCH 1/1] trousers: fix build issue with musl Rahul Bedarkar
2016-08-20 12:41 ` Thomas Petazzoni [this message]
2016-08-22 13:52 ` Rahul Bedarkar
2016-08-22 13:59 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160820144139.77d3e36a@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.