Dear list,
Is anybody else having problems with
tools::package_native_routine_registration_skeleton?
> tools::package_native_routine_registration_skeleton("~/Repos/imager")
Error in native_routine_registration_db_from_ff_call_db(calls, dir,
character_only) :
no native symbols were extracted
This used to work fine up until a few weeks ago, and I can't tell which
update broke the function. Anybody else getting this?
Many thanks, best
Simon Barthelme
[R-pkg-devel] problem with package_native_routine_registration_skeleton
5 messages · Simon Barthelmé, Mark van der Loo, Martin Maechler
1 day later
I have had no problems recently (having updated a pkg or two with this over the last couple of weeks). Your question is not reproducible so its hard to help... best, Mark Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelm? < simon.barthelme at gipsa-lab.fr>:
Dear list, Is anybody else having problems with tools::package_native_routine_registration_skeleton?
> tools::package_native_routine_registration_skeleton("~/Repos/imager")
Error in native_routine_registration_db_from_ff_call_db(calls, dir, character_only) : no native symbols were extracted This used to work fine up until a few weeks ago, and I can't tell which update broke the function. Anybody else getting this? Many thanks, best Simon Barthelme
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Mark van der Loo <mark.vanderloo at gmail.com>
on Thu, 22 Jun 2017 07:33:49 +0000 writes:
> I have had no problems recently (having updated a pkg or two with this over
> the last couple of weeks). Your question is not reproducible so its hard to
> help...
> best,
> Mark
> Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelm? <
> simon.barthelme at gipsa-lab.fr>:
>> Dear list,
>>
>> Is anybody else having problems with
>> tools::package_native_routine_registration_skeleton?
>>
>> > tools::package_native_routine_registration_skeleton("~/Repos/imager")
>>
>> Error in native_routine_registration_db_from_ff_call_db(calls, dir,
>> character_only) :
>> no native symbols were extracted
please carefully re-read the error message!
Hint : What is the name of the first argument of that function,
and what is the name of the 2nd one ?
>> This used to work fine up until a few weeks ago, and I can't tell which
>> update broke the function. Anybody else getting this?
>>
>> Many thanks, best
>>
>> Simon Barthelme
Martin Maechler <maechler at stat.math.ethz.ch>
on Thu, 22 Jun 2017 09:57:41 +0200 writes:
Mark van der Loo <mark.vanderloo at gmail.com>
on Thu, 22 Jun 2017 07:33:49 +0000 writes:
>> I have had no problems recently (having updated a pkg or two with this over
>> the last couple of weeks). Your question is not reproducible so its hard to
>> help...
>> best,
>> Mark
>> Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelm? <
>> simon.barthelme at gipsa-lab.fr>:
>>> Dear list,
>>>
>>> Is anybody else having problems with
>>> tools::package_native_routine_registration_skeleton?
>>>
>>> > tools::package_native_routine_registration_skeleton("~/Repos/imager")
>>>
>>> Error in native_routine_registration_db_from_ff_call_db(calls, dir,
>>> character_only) :
>>> no native symbols were extracted
> please carefully re-read the error message!
> Hint : What is the name of the first argument of that function,
> and what is the name of the 2nd one ?
I'm sorry and do apologize: The above was not at all helpful.
'dir' _is_ the first argument of
package_native_routine_registration_skeleton() and the error
message showed another function (with a similarly much much much
too long name, so nobody reads the name to an end).
Indeed, I get the same message as you when I use this on a
source package directory... though one that does already contain
everything perfect in the init.c file.
So maybe the function should not give an error but just
acknowledge that no *unregisterted* native symbols were found ?
Martin Maechler
>>> This used to work fine up until a few weeks ago, and I can't tell which
>>> update broke the function. Anybody else getting this?
>>>
>>> Many thanks, best
>>>
>>> Simon Barthelme
Dear Martin OK, thanks, I see now. Yes, a warning saying that all symbols have been properly registered already would be easier to understand, I think. You might want to generate the output anyway, it can't hurt! Best Simon
On 22/06/2017 10:41, Martin Maechler wrote:
Martin Maechler <maechler at stat.math.ethz.ch>
on Thu, 22 Jun 2017 09:57:41 +0200 writes:
Mark van der Loo <mark.vanderloo at gmail.com>
on Thu, 22 Jun 2017 07:33:49 +0000 writes:
>> I have had no problems recently (having updated a pkg or two with this over
>> the last couple of weeks). Your question is not reproducible so its hard to
>> help...
>> best,
>> Mark
>> Op wo 21 jun. 2017 om 23:46 schreef Simon Barthelm? <
>> simon.barthelme at gipsa-lab.fr>:
>>> Dear list,
>>>
>>> Is anybody else having problems with
>>> tools::package_native_routine_registration_skeleton?
>>>
>>> > tools::package_native_routine_registration_skeleton("~/Repos/imager")
>>>
>>> Error in native_routine_registration_db_from_ff_call_db(calls, dir,
>>> character_only) :
>>> no native symbols were extracted
> please carefully re-read the error message!
> Hint : What is the name of the first argument of that function,
> and what is the name of the 2nd one ?
I'm sorry and do apologize: The above was not at all helpful. 'dir' _is_ the first argument of package_native_routine_registration_skeleton() and the error message showed another function (with a similarly much much much too long name, so nobody reads the name to an end). Indeed, I get the same message as you when I use this on a source package directory... though one that does already contain everything perfect in the init.c file. So maybe the function should not give an error but just acknowledge that no *unregisterted* native symbols were found ? Martin Maechler
>>> This used to work fine up until a few weeks ago, and I can't tell which
>>> update broke the function. Anybody else getting this?
>>>
>>> Many thanks, best
>>>
>>> Simon Barthelme
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel