Sorry if I am missing something obvious here but I have been away from
this for a while and trying to catch up with recent developments. I
have also searched the archives and cant find a fix. Building ykpers
on Leopard 10.6 I get the following error:
mv -f .deps/ykpersonalize.Tpo .deps/ykpersonalize.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -D_THREAD_SAFE -
no-install -framework IOKit -framework CoreFoundation -o ykpersonalize
ykpersonalize.o ./libykpers-1.la ./ykcore/libykcore.la
libtool: link: warning: `-no-install' is ignored for i386-apple-
darwin10.0.0
libtool: link: warning: assuming `-no-fast-install' instead
libtool: link: gcc -g -O2 -D_THREAD_SAFE -o .libs/ykpersonalize
ykpersonalize.o ./.libs/libykpers-1.dylib -L/Users/patrick/Source/
ykpers/local/lib ./ykcore/.libs/libykcore.a /Users/patrick/Source/
ykpers/local/lib/libyubikey.dylib -framework CoreFoundation -framework
IOKit
Undefined symbols:
"__ykp_errno_location", referenced from:
_report_yk_error in ykpersonalize.o
_report_yk_error in ykpersonalize.o
_main in ykpersonalize.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [ykpersonalize] Error 1
make: *** [all-recursive] Error 1
Am I missing something?
-- Patrick
> Hi,
>
> Sorry if I am missing something obvious here but I have been away from
> this for a while and trying to catch up with recent developments. I
> have also searched the archives and cant find a fix. Building ykpers
> on Leopard 10.6 I get the following error:
Hi! Thanks for the report! Obviously nobody had tested 0.98 on Mac,
since it was a simple problem with the export symbols regexp which
didn't include _yk*errno_location. On Linux systems, the linker version
script is used instead of the regexp, so we never noticed the problem.
> Undefined symbols:
> "__ykp_errno_location", referenced from:
> _report_yk_error in ykpersonalize.o
> _report_yk_error in ykpersonalize.o
> _main in ykpersonalize.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
Please test just released 0.99 and let us know if it works.
/Simon
>
>> Undefined symbols:
>> "__ykp_errno_location", referenced from:
>> _report_yk_error in ykpersonalize.o
>> _report_yk_error in ykpersonalize.o
>> _main in ykpersonalize.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>
> Please test just released 0.99 and let us know if it works.
Thanks for the quick update, that builds ok now apart from the
following warnings:
ykpersonalize.c: In function ‘main’:
ykpersonalize.c:177: warning: format not a string literal and no
format arguments
ykpersonalize.c:378: warning: format not a string literal and no
format arguments
ykpersonalize.c:391: warning: format not a string literal and no
format arguments
ykpersonalize.c:459: warning: format not a string literal and no
format arguments
Haven't had time to run the programme yet but will try later and
report back any problems.
Thanks
-- Patrick
> On 12 Sep 2009, at 08:15, Simon Josefsson wrote:
>
>
>>
>>> Undefined symbols:
>>> "__ykp_errno_location", referenced from:
>>> _report_yk_error in ykpersonalize.o
>>> _report_yk_error in ykpersonalize.o
>>> _main in ykpersonalize.o
>>> ld: symbol(s) not found
>>> collect2: ld returned 1 exit status
>>
>> Please test just released 0.99 and let us know if it works.
>
> Thanks for the quick update, that builds ok now apart from the
> following warnings:
>
> ykpersonalize.c: In function ‘main’:
> ykpersonalize.c:177: warning: format not a string literal and no
> format arguments
> ykpersonalize.c:378: warning: format not a string literal and no
> format arguments
> ykpersonalize.c:391: warning: format not a string literal and no
> format arguments
> ykpersonalize.c:459: warning: format not a string literal and no
> format arguments
Thanks, fixed in svn.
> Haven't had time to run the programme yet but will try later and
> report back any problems.
Please do! We'll wait a few days with releasing 1.0 so you can test it.
You are the first independent Mac OS X user to test the tool, so your
feedback is important.
/Simon
> Please do! We'll wait a few days with releasing 1.0 so you can test
> it.
> You are the first independent Mac OS X user to test the tool, so your
> feedback is important.
I haven't been able to spend a great deal of time on this but I have
got the following observations.
I am using Snow Leopard 10.6.1 with gcc 4.2.1 and using --with-
backend=osx.
libyubikey 1.5
ykpers 0.99
64 bit binaries (the default build) don't run, they just immediately
seg fault. I don't know if this is supported so I didn't go any further.
I then built with the -m32 flag to gcc to build 32 bit binaries for
yubico-c and ykpers.
There seems to be a problem using modhex strings:
patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
ofixed=cccccccccccc -a00000000000000000000000000000000 -ostatic>
Firmware version 2.0.1 Touch level 1792 Program sequence 4
Invalid modhex fixed string: cccccccccccc
USB error: USB error
patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
ofixed=vvvecdcedvjj -a00000000000000000000000000000000 -oaccess>
Firmware version 1.2.0 Touch level 8739 Program sequence 1
Invalid modhex fixed string: vvvecdcedvjj
USB error: USB error
patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
a00000000000000000000000000000000 -oaccess=ccbbccccbbcc
Firmware version 1.2.0 Touch level 8739 Program sequence 1
Invalid modhex access code string: ccbbccccbbcc
USB error: USB error
Without the fixed string I get further, and programming the key works
great:
patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
a00000000000000000000000000000000
Firmware version 1.2.0 Touch level 8739 Program sequence 1
Configuration data to be written to key configuration 1:
fixed: m:
uid: h:000000000000
key: h:00000000000000000000000000000000
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags:
Commit? (y/n) [n]: y
I will continue testing and let you know my findings.
-- Patrick
>> Please do! We'll wait a few days with releasing 1.0 so you can test
>> it.
>> You are the first independent Mac OS X user to test the tool, so your
>> feedback is important.
>
> I haven't been able to spend a great deal of time on this but I have
> got the following observations.
>
> I am using Snow Leopard 10.6.1 with gcc 4.2.1 and using --with-
> backend=osx.
> libyubikey 1.5
> ykpers 0.99
>
> 64 bit binaries (the default build) don't run, they just immediately
> seg fault. I don't know if this is supported so I didn't go any further.
>
> I then built with the -m32 flag to gcc to build 32 bit binaries for
> yubico-c and ykpers.
>
> There seems to be a problem using modhex strings:
>
> patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
> ofixed=cccccccccccc -a00000000000000000000000000000000 -ostatic>
> Firmware version 2.0.1 Touch level 1792 Program sequence 4
> Invalid modhex fixed string: cccccccccccc
> USB error: USB error
Ouch -- looking at the code, I suspect this error was fixed when fixing
compiler warnings. Please try again with 0.999:
http://code.google.com/p/yubikey-personalization/downloads/list
> Without the fixed string I get further, and programming the key works
> great:
>
> patrick@Milhouse:~/Source/ykpers/ykpers-0.99> ykpersonalize -
> a00000000000000000000000000000000
> Firmware version 1.2.0 Touch level 8739 Program sequence 1
> Configuration data to be written to key configuration 1:
>
> fixed: m:
> uid: h:000000000000
> key: h:00000000000000000000000000000000
> acc_code: h:000000000000
> ticket_flags: APPEND_CR
> config_flags:
>
> Commit? (y/n) [n]: y
>
> I will continue testing and let you know my findings.
Did you check that the yubikey was re-programmed successfully?
Thanks,
Simon
But I had problems on the version 2 key when using a lock code:
patrick@Milhouse:~/Source/ykpers/ykpers-0.999> ykpersonalize -
cacbbccccbbee -ofixed=vvvecdcedvjj -a00000000000000000000000000000003 -
oaccess=cccccccccccc
Firmware version 2.0.1 Touch level 1792 Program sequence 3
Configuration data to be written to key configuration 1:
fixed: m:vvvecdcedvjj
uid: h:000000000000
key: h:00000000000000000000000000000003
acc_code: h:cccccccccccc
ticket_flags: APPEND_CR
config_flags:
Commit? (y/n) [n]: y
Yubikey core error: write error
I programmed the key OK, but now when I try to reaccess it I get the
Yubikey core error.
No time to test further this morning the day job calls!, I will try
again this evening.
-- Patrick
> 0.999 looks much better and I managed to program two keys, an older
> firmware version 1.2 and a newer 2.0.1.
Great!
> But I had problems on the version 2 key when using a lock code:
>
> patrick@Milhouse:~/Source/ykpers/ykpers-0.999> ykpersonalize -
> cacbbccccbbee -ofixed=vvvecdcedvjj -a00000000000000000000000000000003 -
> oaccess=cccccccccccc
> Firmware version 2.0.1 Touch level 1792 Program sequence 3
> Configuration data to be written to key configuration 1:
>
> fixed: m:vvvecdcedvjj
> uid: h:000000000000
> key: h:00000000000000000000000000000003
> acc_code: h:cccccccccccc
> ticket_flags: APPEND_CR
> config_flags:
>
> Commit? (y/n) [n]: y
> Yubikey core error: write error
>
>
> I programmed the key OK, but now when I try to reaccess it I get the
> Yubikey core error.
That is the error you get when you try to program a key without
providing the correct unlock key. Maybe you hadn't set the lock code on
that key before trying to reprogram it?
> No time to test further this morning the day job calls!, I will try
> again this evening.
Thank you for testing! I think we'll release the current version as
v1.0 in the next few days -- the error you got is probably not a
software error but a usage error (or, unlikely, a yubikey error).
/Simon
> Thank you for testing! I think we'll release the current version as
> v1.0 in the next few days -- the error you got is probably not a
> software error but a usage error (or, unlikely, a yubikey error).
Yes you were right. I was pasting the commands from the readme file on
the wiki and the access code used in the final command is wrong.
All seems to work great on Snow Leopard when compiled as 32 bit.
Looking forward to the v1 release.
Regards,
-- Patrick
Thanks for testing!
If you or someone else tracks down why forcing 32-bit is needed, let us
know.
/Simon