* utmp symbol conflict
@ 2016-08-04 20:28 Thomas Petazzoni
2016-08-04 22:20 ` Rich Felker
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Petazzoni @ 2016-08-04 20:28 UTC (permalink / raw)
To: musl
Hello,
The shellinabox project
(https://github.com/shellinabox/shellinabox) fails to build with musl
due to the following define in musl's utmp.h:
#define utmp utmpx
Indeed shellinabox/launcher.c has the following piece of code
(https://github.com/shellinabox/shellinabox/blob/master/shellinabox/launcher.c#L1572) :
struct utmpx utmpx = utmp->utmpx;
if (service->useLogin || service->authUser) {
utmpx.ut_type = LOGIN_PROCESS;
memset(utmpx.ut_host, 0, sizeof(utmpx.ut_host));
}
Where "utmp" is of type "struct Utmp *", which is an internal structure
type defined as:
struct Utmp {
const char pid[32];
int pty;
int useLogin;
#ifdef HAVE_UTMPX_H
struct utmpx utmpx;
#endif
};
Unfortunately, with musl's definition #define utmp utmpx, the line:
struct utmpx utmpx = utmp->utmpx;
gets turned after pre-processing to:
struct utmpx utmpx = utmpx->utmpx;
which obviously causes a build failure:
shellinabox/launcher.c: In function ‘childProcess’:
shellinabox/launcher.c:1576:41: error: invalid type argument of ‘->’ (have ‘struct utmpx’)
struct utmpx utmpx = utmp->utmpx;
^
I don't think the symbol "utmp" as a variable name is reserved, so is
the #define utmp utmpx done by musl really a legal thing to do?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: utmp symbol conflict
2016-08-04 20:28 utmp symbol conflict Thomas Petazzoni
@ 2016-08-04 22:20 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2016-08-04 22:20 UTC (permalink / raw)
To: musl
On Thu, Aug 04, 2016 at 10:28:52PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> The shellinabox project
> (https://github.com/shellinabox/shellinabox) fails to build with musl
> due to the following define in musl's utmp.h:
>
> #define utmp utmpx
>
> Indeed shellinabox/launcher.c has the following piece of code
> (https://github.com/shellinabox/shellinabox/blob/master/shellinabox/launcher.c#L1572) :
>
> struct utmpx utmpx = utmp->utmpx;
> if (service->useLogin || service->authUser) {
> utmpx.ut_type = LOGIN_PROCESS;
> memset(utmpx.ut_host, 0, sizeof(utmpx.ut_host));
> }
>
> Where "utmp" is of type "struct Utmp *", which is an internal structure
> type defined as:
>
> struct Utmp {
> const char pid[32];
> int pty;
> int useLogin;
> #ifdef HAVE_UTMPX_H
> struct utmpx utmpx;
> #endif
> };
>
> Unfortunately, with musl's definition #define utmp utmpx, the line:
>
> struct utmpx utmpx = utmp->utmpx;
>
> gets turned after pre-processing to:
>
> struct utmpx utmpx = utmpx->utmpx;
>
> which obviously causes a build failure:
>
> shellinabox/launcher.c: In function ‘childProcess’:
> shellinabox/launcher.c:1576:41: error: invalid type argument of ‘->’ (have ‘struct utmpx’)
> struct utmpx utmpx = utmp->utmpx;
> ^
> I don't think the symbol "utmp" as a variable name is reserved, so is
> the #define utmp utmpx done by musl really a legal thing to do?
The header <utmp.h> is not a standard header so there are no namespace
constraints on it. An application using utmpx (the standard api)
should be including just <utmpx.h> not <utmp.h>.
Aside from that, utmp is not supported at all on musl (it's all stubs)
so it would probably make the most sense to compile with an option to
disable utmp support if possible. This might help avoid runtime
warnings about not being able to set/find utmp entries.
Rich
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-08-04 22:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-04 20:28 utmp symbol conflict Thomas Petazzoni
2016-08-04 22:20 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).