Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200416161746.GW11469@brightrain.aerifal.cx>
Date: Thu, 16 Apr 2020 12:17:46 -0400
From: 'Rich Felker' <dalias@...c.org>
To: sidneym@...eaurora.org
Cc: musl@...ts.openwall.com
Subject: Re: [hexagon] testing updates

On Thu, Apr 16, 2020 at 11:05:36AM -0500, sidneym@...eaurora.org wrote:
> 
> 
> > -----Original Message-----
> > From: Rich Felker <dalias@...c.org>
> > Sent: Wednesday, April 15, 2020 10:16 PM
> > To: sidneym@...eaurora.org
> > Cc: musl@...ts.openwall.com
> > Subject: Re: [musl][hexagon] testing updates
> > 
> > On Wed, Apr 15, 2020 at 10:10:20PM -0500, sidneym@...eaurora.org wrote:
> > > Updated alltypes.h.in and added sem.h.  This change cleared the
> > > following
> > > errors:
> > >
> > >       src/functional/pthread_mutex-static.exe
> > >
> > >       src/functional/pthread_mutex.exe
> > >
> > >       src/functional/pthread_mutex_pi-static.exe
> > >
> > >       src/functional/pthread_mutex_pi.exe
> > >       src/functional/sem_init-static.exe
> > >
> > >       src/functional/sem_init.exe
> > 
> > I'm confused how these changed at all from the changes you made.
> > sem_init is for POSIX semaphores not sysv ipc ones. The bits/sem.h things
> > don't have anything to do with it.
> 
> The sem.h change shouldn't have been included in the patch.
> The change of time_t from a 64 to 32 bit value changed the size of timespec
> used in the pthread_cond and sem_timedwait
> 
> I pruned our original port, possibly too much in some cases, but in this
> case I'd like some guidance since no other arch needed time_t as a 32-bit
> type.

Remove the time_t and suseconds_t TYPEDEFs from alltypes.h.in. They
are no longer allowed to vary per-arch. Then make sure you rebuild
*everything* (libc, the test suite, any other code you're linking
against musl and trying to use). I'm pretty sure you have a mix of
files that have been build with different things you've tried and that
is the source of your problems.

> There is a large chunk of code compat/time32 which I have not tried
> to use yet but I have a feeling I might need to.

These files are only used on archs that had an old ABI with 32-bit
time_t, which I asked about before and you seemed to say you don't
have. If you *do* actually have an existing ecosystem of stuff that
possibly needs to keep working, we need to figure out what that is and
whether it's even possible to support (it might not be if it's a
mess/mix of different things you've tried). If not then these files
will not even be built and are not needed.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.