Hey,
2016-08-26 22:04 GMT+02:00 Bryan Drewery :
> On 8/26/2016 12:57 PM, John Baldwin wrote:
>> Alternatively, couldn't you just leave basename out of the libgen patch
>> for now and only add it once you do the real symver bump for the
>> different version? (That is, just use __generic() for dirn
On 8/26/2016 12:57 PM, John Baldwin wrote:
> On Friday, August 26, 2016 09:37:10 AM Ed Schouten wrote:
>> Hi,
>>
>> 2016-08-26 1:52 GMT+02:00 Bryan Drewery :
>>> Libc wouldn't build, it complained quite loudly with a lot of these:
>>
>> Got it. Thinking ahead, if it's just basename() giving the pro
On Friday, August 26, 2016 09:37:10 AM Ed Schouten wrote:
> Hi,
>
> 2016-08-26 1:52 GMT+02:00 Bryan Drewery :
> > Libc wouldn't build, it complained quite loudly with a lot of these:
>
> Got it. Thinking ahead, if it's just basename() giving the problems,
> maybe it's easier to just go ahead and
On 08/26/16 18:31, Bryan Drewery wrote:
> On 8/26/2016 12:37 AM, Ed Schouten wrote:
>> Hi,
>>
>> 2016-08-26 1:52 GMT+02:00 Bryan Drewery :
>>> Libc wouldn't build, it complained quite loudly with a lot of these:
>> Got it. Thinking ahead, if it's just basename() giving the problems,
>> maybe it's e
On 8/26/2016 12:37 AM, Ed Schouten wrote:
> Hi,
>
> 2016-08-26 1:52 GMT+02:00 Bryan Drewery :
>> Libc wouldn't build, it complained quite loudly with a lot of these:
> Got it. Thinking ahead, if it's just basename() giving the problems,
> maybe it's easier to just go ahead and bump the symver of b
Hi,
2016-08-26 1:52 GMT+02:00 Bryan Drewery :
> Libc wouldn't build, it complained quite loudly with a lot of these:
Got it. Thinking ahead, if it's just basename() giving the problems,
maybe it's easier to just go ahead and bump the symver of basename()
as well? I'm planning on replacing it anyw
On 8/25/2016 1:55 PM, Ed Schouten wrote:
> Hi Bryan,
>
> 2016-08-25 19:43 GMT+02:00 Bryan Drewery :
readelf -a /lib/libc.so.7|grep basename
>>> 2149: 00076200 231 FUNCGLOBAL DEFAULT 11
>>> basename@@FBSD_1.0 (2)
>>> 2514: 00076140 184 FUNCGLOBAL DEFAULT 11
Hi Bryan,
2016-08-25 19:43 GMT+02:00 Bryan Drewery :
>>> readelf -a /lib/libc.so.7|grep basename
>> 2149: 00076200 231 FUNCGLOBAL DEFAULT 11
>> basename@@FBSD_1.0 (2)
>> 2514: 00076140 184 FUNCGLOBAL DEFAULT 11
>> basename_r@@FBSD_1.2 (4)
I think the reason for
On 8/25/16 9:29 AM, Guido Falsi wrote:
> On 08/25/16 18:24, Bryan Drewery wrote:
> --- _bootstrap-tools-usr.bin/xinstall ---
> xinstall.o: In function `install':
> /usr/local/nanobsd/rr-trunk/src/usr.bin/xinstall/xinstall.c:(.text+0xf55):
> undefined reference to `basename@FBSD_1.0'
On 08/25/16 18:24, Bryan Drewery wrote:
--- _bootstrap-tools-usr.bin/xinstall ---
xinstall.o: In function `install':
/usr/local/nanobsd/rr-trunk/src/usr.bin/xinstall/xinstall.c:(.text+0xf55):
undefined reference to `basename@FBSD_1.0'
>
> readelf -a /lib/libc.so.7|grep basename
On 8/25/16 9:17 AM, Guido Falsi wrote:
> On 08/25/16 18:05, Bryan Drewery wrote:
>> On 8/25/16 1:27 AM, Guido Falsi wrote:
>>> On 08/24/16 21:49, Ed Schouten wrote:
2016-08-24 20:30 GMT+02:00 Bryan Drewery :
> That would only fix stable/11, stable/10, stable/9, releng/11.0.
>
> It
On 08/25/16 18:05, Bryan Drewery wrote:
> On 8/25/16 1:27 AM, Guido Falsi wrote:
>> On 08/24/16 21:49, Ed Schouten wrote:
>>> 2016-08-24 20:30 GMT+02:00 Bryan Drewery :
That would only fix stable/11, stable/10, stable/9, releng/11.0.
It won't fix releng/10.3, releng/10.2, releng/10.1
On 8/25/16 1:27 AM, Guido Falsi wrote:
> On 08/24/16 21:49, Ed Schouten wrote:
>> 2016-08-24 20:30 GMT+02:00 Bryan Drewery :
>>> That would only fix stable/11, stable/10, stable/9, releng/11.0.
>>>
>>> It won't fix releng/10.3, releng/10.2, releng/10.1, releng/9.3, etc...
>>> without an EN.
>>>
>>>
On 08/24/16 21:49, Ed Schouten wrote:
> 2016-08-24 20:30 GMT+02:00 Bryan Drewery :
>> That would only fix stable/11, stable/10, stable/9, releng/11.0.
>>
>> It won't fix releng/10.3, releng/10.2, releng/10.1, releng/9.3, etc...
>> without an EN.
>>
>> It won't fix stable/11 - 1, stable/10 - 1, etc.
On 8/24/16 1:30 PM, Bryan Drewery wrote:
> On 8/24/16 1:26 PM, Eric van Gyzen wrote:
>> On 08/24/2016 15:16, Bryan Drewery wrote:
>>> On 8/24/16 1:12 PM, Eric van Gyzen wrote:
On 08/24/2016 15:01, Ed Schouten wrote:
> 2016-08-24 21:53 GMT+02:00 Bryan Drewery :
>> Is it possible to caus
On 8/24/16 1:26 PM, Eric van Gyzen wrote:
> On 08/24/2016 15:16, Bryan Drewery wrote:
>> On 8/24/16 1:12 PM, Eric van Gyzen wrote:
>>> On 08/24/2016 15:01, Ed Schouten wrote:
2016-08-24 21:53 GMT+02:00 Bryan Drewery :
> Is it possible to cause the use of these old prototypes to print a
>>>
On 08/24/2016 15:16, Bryan Drewery wrote:
> On 8/24/16 1:12 PM, Eric van Gyzen wrote:
>> On 08/24/2016 15:01, Ed Schouten wrote:
>>> 2016-08-24 21:53 GMT+02:00 Bryan Drewery :
Is it possible to cause the use of these old prototypes to print a
warning and note that they are deprecated/unsa
On 8/24/16 1:12 PM, Eric van Gyzen wrote:
> On 08/24/2016 15:01, Ed Schouten wrote:
>> 2016-08-24 21:53 GMT+02:00 Bryan Drewery :
>>> Is it possible to cause the use of these old prototypes to print a
>>> warning and note that they are deprecated/unsafe?
>>
>> That's a good question. In theory, we
On 08/24/2016 15:01, Ed Schouten wrote:
> 2016-08-24 21:53 GMT+02:00 Bryan Drewery :
>> Is it possible to cause the use of these old prototypes to print a
>> warning and note that they are deprecated/unsafe?
>
> That's a good question. In theory, we could annotate these functions
> with __attribut
2016-08-24 21:53 GMT+02:00 Bryan Drewery :
> Is it possible to cause the use of these old prototypes to print a
> warning and note that they are deprecated/unsafe?
That's a good question. In theory, we could annotate these functions
with __attribute__((__deprecated__)):
https://gcc.gnu.org/online
On 8/24/16 12:49 PM, Ed Schouten wrote:
> 2016-08-24 20:30 GMT+02:00 Bryan Drewery :
>> > That would only fix stable/11, stable/10, stable/9, releng/11.0.
>> >
>> > It won't fix releng/10.3, releng/10.2, releng/10.1, releng/9.3, etc...
>> > without an EN.
>> >
>> > It won't fix stable/11 - 1, stabl
2016-08-24 20:30 GMT+02:00 Bryan Drewery :
> That would only fix stable/11, stable/10, stable/9, releng/11.0.
>
> It won't fix releng/10.3, releng/10.2, releng/10.1, releng/9.3, etc...
> without an EN.
>
> It won't fix stable/11 - 1, stable/10 - 1, etc.
>
> It will never fix releng/8.4 (unsupported
That would only fix stable/11, stable/10, stable/9, releng/11.0.
It won't fix releng/10.3, releng/10.2, releng/10.1, releng/9.3, etc...
without an EN.
It won't fix stable/11 - 1, stable/10 - 1, etc.
It will never fix releng/8.4 (unsupported releases) since so@ won't EN
to those. People do somet
Hi Bryan,
We could solve this by simple mfcing the change I made for xinstall, right?
Ed
On 24 Aug 2016 20:15, "Bryan Drewery" wrote:
> On 8/24/16 11:06 AM, Bryan Drewery wrote:
> > On 8/12/16 12:03 AM, Ed Schouten wrote:
> >> Author: ed
> >> Date: Fri Aug 12 07:03:58 2016
> >> New Revision: 3
On 8/24/16 11:06 AM, Bryan Drewery wrote:
> On 8/12/16 12:03 AM, Ed Schouten wrote:
>> Author: ed
>> Date: Fri Aug 12 07:03:58 2016
>> New Revision: 303988
>> URL: https://svnweb.freebsd.org/changeset/base/303988
>>
>> Log:
>> Reimplement dirname(3) to be thread-safe.
>>
>> Now that we've up
On 8/12/16 12:03 AM, Ed Schouten wrote:
> Author: ed
> Date: Fri Aug 12 07:03:58 2016
> New Revision: 303988
> URL: https://svnweb.freebsd.org/changeset/base/303988
>
> Log:
> Reimplement dirname(3) to be thread-safe.
>
> Now that we've updated the prototypes of the basename(3) and dirname(
26 matches
Mail list logo
