Temurin-build: DLLs المفقودة يعني أن المستخدمين مجبرون على تنزيل Microsoft Visual C ++ Redistributable

johanvos - هل هذا شيء تتوقع أن يكون في

إنه جزء من توزيع OpenJDK ، لذا لأسباب تتعلق بالاتساق ، أعتقد أنه يجب أن يكون جزءًا من توزيع تبنّي OpenJDK أيضًا؟

عظيم شكرا لك! @ ali- ince /

سيؤدي تضمين dlls في الحزمة إلى زيادة حجم توزيع OpenJDK الذي يجب أن يؤخذ في الاعتبار. لا توصي Microsoft بالارتباط الثابت أو تضمين DLL في دليلك الخاص لأن تحديث نظام التشغيل / الأمان قد لا ينطبق على وقت التشغيل هذا

انظر إلى: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

يبدو أن هذه مكتبات على مستوى نظام التشغيل ولكن بطريقة ما قاموا بتغيير الاسم. الاقتراح المقدم من مجتمع MS هو أننا يجب أن نستخدم mincore.lib وهو رقاقة لكل أسطح api ، لكن الثنائي سيعمل فقط مع Windows 8+.

بدلاً من ذلك ، يمكننا توزيع برنامج التثبيت Visual C ++ الكامل القابل لإعادة التوزيع في حزمة المثبت الخاصة بنا.

ماذا سيكون خيارا جيدا؟

تضمين التغريدة

بدلاً من ذلك ، يمكننا توزيع برنامج التثبيت Visual C ++ الكامل القابل لإعادة التوزيع في حزمة المثبت الخاصة بنا.

ياك !!!

يجب أن يكون تبنّي OpenJDK بديلاً عن إصدار jdk.java.net.

إذا جعلت المستخدمين النهائيين يقفزون عبر الأطواق ، فسيكون ذلك ضارًا جدًا لعرض القيمة لتطبيقات jlink التي لا تعتمد على التبعية.

IMHO ، على الرغم من أنني أستطيع أن أرى السبب الذي يجعلك تفكر في تضمين redist VC ++ في تبنّي OpenJDK ، يجب عليك فقط تضمينه إذا كان ملف dll. يتطلب ذلك ولأن الشيء الوحيد الذي يتطلب ذلك هو JavaFX الخاص بـ dll. ، ثم يبدو سبب تضمينه غريبًا .

من المنطقي أن تقوم حزمة JavaFX بتضمينها.

أو قم بتضمينها في حزمة إضافية من برنامج تبنّي OpenJavaFX :-)

من المنطقي أن تقوم حزمة JavaFX بتضمينها.

أستطيع أن أرى أنك قد تكون محقًا تمامًا في أن ملفات .dlls في عالم مثالي يجب أن تكون في حزمة JavaFX.

في هذه الأثناء ، حتى تتمكن من البدء في تقديم حزمة تبنّي OpenJavaFX الخاصة بك أو إقناع Gluon بتضمين .dlls في الحزمة الخاصة بهم ، لا يمكن استخدام تبنّي OpenJDK لتطبيقات JavaFX.

أنا متأكد من أن هناك جميع أنواع المناهج طويلة المدى الأفضل ، ولكن في الوقت نفسه ، هذه حالة غير مقبولة من النسيان لـ تبنّي OpenJDK.

أعتقد أن المشكلة الرئيسية هنا قد تكون أن تبنّي أبن JDK يبني JDK بإصدار مختلف من الاستوديو المرئي (سأتحقق من أنه من المحتمل أن يكون VS2013) عن ما تم بناء JavaFX به (بالنظر إلى أسماء DLL المفقودة ، فمن المحتمل أن يكون VS2017).

سأحاول التحقق من إصدار VS أولاً والتحديث هنا.

لقد لاحظت أن تبنّي OpenJDK 12 (نقطة ساخنة) يحتوي الآن على مكتبات DLL الضرورية ، لذلك كل شيء يعمل بشكل مثالي مع تطبيقات JavaFX.

شكرا لك!!!

لقد لاحظت أن تبنّي OpenJDK 12 (نقطة ساخنة) يحتوي الآن على مكتبات DLL الضرورية ، لذلك كل شيء يعمل بشكل مثالي مع تطبيقات JavaFX.

شكرا لك!!!

من الجيد سماع ذلك - بالنسبة إلى Java 11 و 8 ، أظن أنه سيتم حل هذه المشكلة في المساء الآن. @ ali-ince هل نبني مع VS 2017 لجميع الإصدارات الآن؟

ليس بعد karianna ، هذا لا يزال قيد التقدم. سوف أقوم بتحديث هذا الموضوع عندما ننتقل إلى vs2017.

تحديث سريع لهذا ؛

1. تم الآن تحويل إصدارات JDK11u 64 بت إلى VS2017.
2. إصدارات JDK11u 32 بت موجودة في VS2013. سيتم إطلاق الإصلاح الذي سيمكن JDK11u 32 بت من التجميع مع VS2017 مع تحديث 11.0.4 وسننتقل إلى VS2017 بالتوازي مع ذلك.
3. تم الآن تحويل تصميمات JDK8u 32 بت و 64 بت إلى VS2013 (كانت سابقًا في VS2010 / VS2013 مختلطة). نحن نعمل على جعل هؤلاء يبنون على VS2017 أيضًا ، ولكن يبدو أن هذا يستغرق بعض الوقت للحصول على إصلاح للإرسال إلى المنبع.

أهلا!
لدينا مشاكل في بيئة عملائنا مع مكتبات وقت تشغيل C المفقودة.
كيف هو الوضع في هذه القضية؟

يتمثل الحل البديل في تثبيت وقت تشغيل C وآلاف أنظمة العملاء التي لم يتم تثبيتها مع نظام التشغيل.
لا يمكننا إجبار عملائنا على القيام بذلك أو الانتقال من Windows Server 2012 R2 على سبيل المثال إلى الإصدارات الأحدث طالما أن Microsoft نفسها تدعم هذه الإصدارات.

//تعديل:
هل هناك أي حلول أخرى في هذه الأثناء؟