-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
javacard-devkit: init at 2.2.2 #44148
Conversation
I think it's fixed :) Thank you @cleverca22 ! |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: javacard-devkit Partial log (click to expand)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I turned the suggestions here into a small patch file. However, I didn't test the results.
# the very few information on the net assume a hand-downloaded sdk…? Maybe in the | ||
# manual instead… but noone I know thinks of reading the manual upon installing | ||
# a package? Anyway, just pick a place (including /dev/null) and I'll try to | ||
# move these instructions to there :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe longDescription
in meta
?
|
||
nativeBuildInputs = [ unzip makeWrapper ]; | ||
|
||
unpackPhase = "true"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like this with oraclejdk8
in nativeBuildInputs
should unpack the nested Zip file:
{
# ...
sourceRoot = ".";
zipPrefix = "java_card_kit-${underscoreVersion}";
unpackCmd = ''
unzip -p "$curSrc" "$zipPrefix/$zipPrefix-rr-bin-linux-do.zip" | jar x
'';
# ...
}
Setting sourceRoot
to .
prevents unpackPhase from bailing out due to multiple directories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, didn't know about the sourceRoot = "."
trick!
mkdir "$out" | ||
cp -R bin "$out" | ||
cp -R lib "$out" | ||
cp -R api_export_files "$out" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to put this in $out/share/javacard-devkit
instead of directly in $out
.
|
||
mkdir "$out" | ||
cp -R bin "$out" | ||
cp -R lib "$out" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe $out/lib/java
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SDK appears to expect to find the .jar
in ../lib/*.jar
from the bin/
directory, so, with a choice between either patching all the scripts (and likely mis-patching cref
) I guess it's easier to just put it there? :)
|
||
chmod +x bin/{apdutool,capdump,capgen,converter,cref,exp2text,jcwde,scriptgen,verifycap,verifyexp,verifyrev} | ||
chmod u+w bin/cref | ||
patchelf --set-interpreter "$(cat "$NIX_CC/nix-support/dynamic-linker")" bin/cref |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also libjpcsclite.so
(not sure which component uses it however), which needs libpcsclite.so
. It might be a good idea to use autoPatchelfHook
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know where that's used either…
Good catch for noticing it needs libpcsclite.so
! it also appears to need libnsl.so.1
and libc.so.6
. However, for some reason I can't understand, adding glibc
to the buildInputs
doesn't appear to make autoPatchelfHook
auto-correct it. I've now tried quite a number of variations of it, so if you have any idea about what's going wrong…
(the fact that libnsl-1.1.0
appears to package libnsl.so.2.0.0
and the fact I'm not even sure it is used somewhere are probably just as important reasons for my decision to ragequit this issue after a few hours, though :°)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding glibc
to buildInputs
shouldn't be needed. What's the output from ldd
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no output from ldd
(it's a shared library), but here is the output from readelf -d
:
Dynamic section at offset 0x20a0 contains 23 entries:
Tag Type Name/Value
0x0000001d (RUNPATH) Library runpath: [/nix/store/n962knaz7h3qjdjf01g6r0dwld9qswyc-pcsclite-1.8.23/lib]
0x00000001 (NEEDED) Shared library: [libpcsclite.so]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [libnsl.so.1]
0x0000000c (INIT) 0x50c
0x0000000d (FINI) 0x684
0x00000004 (HASH) 0xb4
0x00000005 (STRTAB) 0x2188
0x00000006 (SYMTAB) 0x18c
0x0000000a (STRSZ) 240 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x17a0
0x00000002 (PLTRELSZ) 16 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x4fc
0x00000011 (REL) 0x4d4
0x00000012 (RELSZ) 40 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x4b4
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x46c
0x6ffffffa (RELCOUNT) 2
0x00000000 (NULL) 0x0
So from what I can tell it's not adding ${glibc}/lib
(for libc.so.6
) in the RUNPATH
. (and it didn't add the libnsl.so.1
either but that's pretty normal) Hence my attempts to add it into buildInputs
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After discussion over IRC, I was just being stupid and assuming that nix-shell --pure -p pkgsi686Linux.glibc
actually was pure, while it actually gave the 64-bits ldd
(due to the internals of -p
).
So with the actual ldd
, that does perform recursive resolution of the runpath, the problem is solved and both libc.so.6
and libnsl.so.1
are already provided by the runpath. So no longer any problem here :)
# TODO (question for the reviewer): The resulting javac can then be used with: | ||
# javac -source 1.2 -target 1.2 myPackage/myApplet.java | ||
# Should I include the -source/-target arguments in this wrapper? | ||
# I'm thinking this may break unaware users just adding javacard-devkit to their env |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's in the same environment as the JDK, it will collide with the javac
from the JDK, but maybe it's a good idea to use a different name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, the issue is all the documentation online mentions only using javac
for compiling (well, when there is any kind of documentation, that is), so I fear if we call it javacardc
people will be lost… but maybe that's the least bad option? Having javacardc
that would have both the right CLASSPATH
and the right -source 1.5 -target 1.5
…
Then, all tutorials online tell you to set the CLASSPATH
and -source 1.5 -target 1.5
by hand, so I wonder how far we should go from upstream for end-user convenience… I think for CLASSPATH
given it's hidden somewhere in the store there's little room for argumentation, but for -source
/-target
I wonder.
Thanks for the review and hints! I've done what I could, things appear to more or less work (at least for the ones for which I know how they are supposed to be used). Though, still remain a few concerns voiced in my answers to your remarks, unfortunately hidden by github as no longer relevant due to underlying code change. |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: javacard-devkit Partial log (click to expand)
|
Thank you for your help, @aszlig! So I think the last remaining question is how to handle the differences of Basically, the differences between the two are that
What I'm thinking is, reasonably we can't leave it up to the user to do 1, because that points into the store and would be a PITA. So this must be done by the For 2… it's more complex: maybe someone wants to compile an older Java Card applet that was designed for use with Now, if the idea is to keep only 1 included in
I can see advantages and disadvantages for both options:
A coin throw told me option 2 was better, but that's only a coin throw's opinion. What do you think about this? :) |
6458fcd
to
1b35a0f
Compare
Given there appeared to be no contradictory opinion, I've now implemented the coin throw's result, and think this is ready to be merged :) |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: javacard-devkit Partial log (click to expand)
|
hey all! i'd love to see this merged. |
@@ -6787,6 +6787,8 @@ with pkgs; | |||
oraclejdk10distro = packageType: _: | |||
(callPackage ../development/compilers/oraclejdk/jdk10-linux.nix { inherit packageType; }); | |||
|
|||
javacard-devkit = pkgsi686Linux.callPackage ../development/compilers/javacard-devkit { }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it pkgsi686Linux
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The devkit is available only for 32-bits linux, and includes a pre-compiled executable (cref
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is pkgsi686Linux
used in stead of meta.platforms
? Does it have something to do with cross compiling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The devkit does work on 64-bit linux, but requires 32-bit libraries, that are defined by pkgsi686Linux
:) That said, you're right, I had mis-set meta.platforms
! This should be fixed with latest push :)
longDescription = '' | ||
This Java Card SDK is the official SDK made available by Oracle for programming for the Java Card platform. | ||
|
||
Instructions for usage: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it common to put documentation in the longDescription? Do you think it is likely that people find it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really know, only followed the advice from #44148 (comment) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't seem ideal to me and I slightly prefer wrapping javac
, but I don't really have a better proposal.
Oracle has already released 3.0.5, but versions after 2.2.2 appear to be Windows-only. Thanks-To: aszlig <aszlig@nix.build>
1b35a0f
to
bcf59b9
Compare
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: javacard-devkit Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: javacard-devkit Partial log (click to expand)
|
Oracle has already released 3.0.5, but versions after 2.2.2 appear to be Windows-only.
This derivation will override
javac
in order to give it the paths required for JavaCard programming.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)