Compiler PDFium sous Windows

Version imprimable

Bonjour,

J'ai développé un PDF Viewer sous Delphi qui exploite une PDFium.DLL
https://github.com/tothpaul/PDFiumReader

cela fonctionne bien mais l'API de PDFium est trop limitée pour ce que je voudrais faire...du coup je voudrais créer une nouvelle DLL mais pas moyen de compiler ce foutu code sous Visual Studio

j'ai tenté de suivre les tuto qui parlent de ninja et autres outils exotiques, et j'obtiens une compilation du code, mais pas de DLL

j'ai bien tenté de partir de zéro, c'est à dire créer un projet DLL sous VS (ça je sais faire) puis de lier le code de PDFium pour créer ma propre API mais là encore j'ai des tas d'erreurs qui sont très logiquement dues aux problèmes de configuration des dépendances (un truc très pénible en C++ pour un développeur Delphi où tout est explicitement déclaré).

Est-ce que par hasard il y a un développeur C++ par ici qui aurait déjà joué avec cela et qui voudrait bien partager une Solution VS qui fonctionne ?

pour info je suis parti des depot_tools
https://chromium.googlesource.com/ch...epot_tools.git

et en suivant ceci https://pdfium.googlesource.com/pdfium/
Code:

1 2 3 4 5 6 7 8 9 10 set path=%path%;C:\PDFium\depot_tools set DEPOT_TOOLS_WIN_TOOLCHAIN=0 mkdir repo cd repo call gclient config --unmanaged https://pdfium.googlesource.com/pdfium.git call gclient sync cd pdfium call build\install-build-deps.sh gn args out\Debug
avec la configuration suivante
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 use_goma = false # Googlers only. Make sure goma is installed and running first. is_debug = true # Enable debugging features. # Set true to enable experimental Skia backend. pdf_use_skia = false # Set true to enable experimental Skia backend (paths only). pdf_use_skia_paths = false pdf_enable_xfa = false # Set false to remove XFA support (implies JS support). pdf_enable_v8 = false # Set false to remove Javascript support. pdf_is_standalone = true # Set for a non-embedded build. is_component_build = false # Disable component build (must be false) clang_use_chrome_plugins = false # Currently must be false.
et je lance ninja -C out\Debug pdfiumça mouline un certain temps (932 objets à compiler)

avec ça j'obtiens, entre autre un fichier PDFium.lib mais VS ne semble pas l'aimer, peut-être car il contient l'entête !<thin> qui est encore un format à la con si j'ai bien compris, avec des .obj externes
https://stackoverflow.com/questions/...a-thin-archive

donc je me retrouve sans DLL, avec un .lib que je ne sais pas exploiter et sans savoir comment produit une DLL avec ninja :calim2:

Quelqu'un peut m'éclairer ?

Merci

16/11/2018, 14h27
bacelar

Si j'ai bien compris le machin en lisant rapidement en diagonale vos références, c'est un peu fermé comme architecture.

(remarque :

Code:

set path=%path%;C:\PDFium\depot_tools

à en croire la doc, il vaut mieux le faire dans l'autre sens.

Code:

set path=C:\PDFium\depot_tools;%path%

)

Si vous n'êtes pas un développeur C++, il y a peut-être des trucs qui vous semble étranges et qui vous conduise à faire des trucs "impossibles".

Alors, on va commencer par des trucs "évident" pour un développeur C++, mais c'est toujours important de revoir les bases.

Visual Studio n'est pas une chaine de compilation C++, mais un IDE gérant un grand nombre de langage via des modules.
Jusqu'à récemment, le seul "module" de compilation C++ s'intégrant complètement à VS était MSVC.
Depuis peu, les outils de la chaine de compilation Clang sont supportés "partiellement".
Mais rien n'empêche d'utiliser une chaine de compilation autre depuis VS mais l'intégration dans l'IHM est beaucoup moins poussée. Il faut faire des trucs à la main.
Comme par exemple quand vous utiliser NMAKE, très proche du MAKE d'Unix, les modifications dans les "sources" du système de build sont à votre charge.
En gros, avec NMAKE, on peut juste demander une compilation(génération de l'exécutable), un nettoyage des fichiers générés, démarrer une session de debugging, et utiliser l'éditeur de texte de VS, point barre.
Vous ajoutez un cpp au projet => vous devez éditer vous-même les fichiers utilisés par NMAKE.
Ninja, c'est un peu comme l'utilisation de NMAKE.
Sauf que pas mal de personnes ont créez des outils pour pallier aux limitations de ce type de "non intégration" à VS.
Mais il reste que la chaine de compilation n'est pas vraiment gérée par VS mais par les fichiers de paramétrage du système de build Ninja.
VS, comme dans le cas NMAKE ne peut demander que très peu de chose différente à la chaine de compilation que Ninja à configuré.
La chaine de compilation utilisée par ninja n'est pas explicitement donnée dans la documentation (ou j'ai lu trop vite), mais si c'était MSVC, on aurait pas tous ces outils ad hoc à installer dans VS pour gérer les fichiers "Ninja".
En C++, la chaine de compilation a une grande importance car tous les fichiers intermédiaires entre le code sources que vous tapez dans un éditeur et le module exécutable générés (code assembleur, fichier objet, fichier librairie/archive, ...) ne sont pas standardisés.
Comme ils ne sont pas standardisés, il est très compliqué (voir impossible) de prendre l'un généré par une chaine de compilation et l'utiliser ensuite dans une autre, et les fichiers .lib/.a sont des fichiers intermédiaire.
Le code source C++ devrait suivre le standard C++ (qui évolue tous les 3 ans actuellement) mais il est assez répandu d'avoir des codes sources C++ dit "non portable" qui ne sont compilable par n'importe quel compilateur C++ "standard".
Il n'est pas exclure que les sources que vous cherchiez à compiler ait des parties "non portable". Ce qui expliquerait l'usage d'outils "exotiques" et pas des trucs plus standard comme CMake.
Le format du fichier .dll est imposé par l'OS et est le même quelque soit le langage du code source, donc quelque soit la chaine de compilation.
Ce qui fait que pour de l’interfaçage entre modules, on part plutôt d'un extracteur d'informations depuis le .dll que depuis un .lib.

Si vous ne faites pas de réglage particulier dans VS et que vous partez bille en tête, vous vous retrouvez avec un projet C++ qui prend comme chaine de compilation MSVC, qui sera donc incapable d'utiliser des .lib/.a issue d'autres chaines de compilation.
Il y a une petite particularité pour les lib issues de MSCV, c'est que les .lib fournis par M$ pour pouvoir attaquer les API de l'OS sont construites avec MSVC, toutes les autres chaines de compilation qui doivent pouvoir générer des exécutable qui attaquent, directement ou indirectement, les API de l'OS doivent pouvoir lire ou convertir ces .lib MSVC vers leur format de .lib.

Sachant les détails que je viens d'exposer, je ne suis pas sûr que vouloir faire une Dll à partir de MSVC, en utilisant des .lib générées par une chaine de compilation inconnue pilotée par des fichiers de configuration de Ninja, soit la solution la plus simple et la plus directe.

Généralement, pour ne pas se compliquer la vie, soit on modifie les sources du projet initial, sans changer de chaine de compilation, soit on joue, si la conception de l'API de la Dll le permet, la stratégie des poupées russes : la nouvelle Dll appelle les fonctions de la Dll "de base". Pour la stratégie à la poupée russe, il suffit d'avoir un outil qui génère un .lib au format de la chaine de compilation à partir de la Dll.

Il existe aussi la méthode de tout recompiler avec la nouvelle chaine de compilation mais cela vous expose aux problèmes de "non portabilité" possibles. Et que je pense très probable vu la nature un peu exotique des outils.
16/11/2018, 15h06
Paul TOTH

Bonjour,

Merci pour cette réponse qui me conforte dans mon sentiment.

je vais préciser ma démarche, comme je ne suis pas à l'aise avec le C++, il est pour moi plus simple d'avoir un IDE comme VS pour gérer un projet C++...mais en effet PDFium ne propose pas de "Solution" toute faite pour VS, j'ai bien trouvé le projet PdfiumBuild, sauf que les modifications qu'il recommande ici ne fonctionnent plus avec les derniers sources, notamment "Change static_library("pdfium") to shared_library("pdfium")" ne fonctionne pas car on a maintenant jumbo_static_library("pdfium") qui n'a pas d'équivalent static :( j'ai bien compris que c'est pour cela que j'ai un .LIB et non une DLL mais ça ne m'avance pas beaucoup.

du coup je suis tout à fait près à porter le costume de ninja pour faire une DLL sous Notepad++ à compiler en ligne de commande...sauf que là je suis comme une poule devant un couteau, je n'ai pas la moindre idée de comment déclarer un projet ninja compatible avec la toolchain de PDFium qui me produise une DLL :/ le seul exemple proposé pdfium_test.cc que je pourrait modifier, produit un .exe...je suppose que ça se passe dans BUILD.gn mais ça ne me parle pas beaucoup :/
16/11/2018, 16h27
bacelar

Ok, quelques détails lors de ma lecture rapide m'avait échappés.

Avant de sortir l'artillerie lourde, il faudrait évaluer les modifications/ajouts que vous comptez effectuer.
En fonction de cette évaluation, des approches plus ou moins simples peuvent être plus adaptées que d'autres.

En résumé, le dépôt officiel de Google n'offre qu'une version LIB du projet Ninja de "pdfium".
Le projet Ninja de ce projet utilise les outils de Chromium, compilable depuis la chaine de compilation Clang.
Il existe un ensemble d'outils plus ou moins bricolés pour faire en sorte de piloter la compilation et le débogage de Chromium depuis VS mais toujours en le compilant avec Clang.
Le projet PdfiumBuild modifie le projet Ninja pour générer une Dll "pdfium" et met à disposition cette dll via un server de build "https://assendelft.webathome.org/Pdfium/" toutes les semaines mais qui échoue son build depuis début Avril 2018.
Ce même projet PdfiumBuild mais aussi à disposition des packages Nuget (voir lien dans "https://github.com/pvginkel/PdfiumBuild") contenant différentes version de la Dll mais la dernière version date d'il y a 7 mois.
Avez-vous vraiment besoin d'une version plus récente de cette librairie ???
Sinon, en utilisant la stratégie des poupées russe, je vous conseille d'utiliser le Package Nuget qui configurera plus ou moins automatiquement votre Projet VS-MSVC pour pouvoir utiliser facilement la Dll (s'ils ont bien fait le boulot) et étendre ces fonctionnalités.

Aux vues des modifications à faire signalés par le projet "PdfiumViewer", les sources de "pdfium" sont conçues pour être facilement "Dll-isable", ce qui rend étrange la limitation du projet Ninja de "pdfium".
Y-a-t-il eu une évolution majeure il y a 7 mois dans ce projet "pdfium" qui aurait brisées la "Dll-isation" faites pas PdfiumBuild ?
Si c'est le cas, avez-vous besoin des ajouts de ces évolutions ?

Si votre objectif principale est d'avoir une Dll "pdfium" à jour des nouvelles fonctionnalités, je pense qu'il serait plus judicieux de contacter les mainteneurs des projets "PdfiumBuild" et "PdfiumViewer" pour qu'ils réparent rapidement leurs bébés ou pour vous donner des indications précises sur comment le faire ou pourquoi c'est plus possible.

Après, il y a toujours des acrobaties possibles mais il faidrait avoir une vue plus précises des évolutions que vous comptez apporter à cette "Dll".
16/11/2018, 18h19
Paul TOTH

alors, manifestement les développeurs de PDFium ne se préoccupent absolument pas de ceux qui veulent l'utiliser comme une DLL, et comme indiqué dans le projet PDFViewer "Google changed their build system (again?), so new instructions.".

Dès lors l'API de PDFium.dll est un choix indépendant de PDFium si je ne m'abuse. Ce que je cherche à faire c'est de rendre les "annotations" éditables, ça fonctionne presque avec la DLL standard mais il me manquerait la possibilité de faire un rendu d'une annotation (celle qui est active) par dessus les autres, et de comprendre pourquoi quand je change la position de certaines d'entres elles via FPDFAnnot_SetRect(), je n'ai pas le résultat escompté.

et tant qu'à faire je me suis dit que si j'étais capable de produire une DLL à partir des sources de PDFium, je pourrais changer librement l'API en tapant aussi bas que je le désire dans le code d'origine..d'où aussi l'idée de pouvoir tracer tout cela sous VS.

En fait j'ai été sans doute mal éduqué par Delphi; dans ce langage, il suffit d'ajouter tous les "uses" (équivalent d'import en Java) de tous les modules nécessaires et hop ça compiler...ou pas, mais le compilateur vous met le nez sur l'erreur car l'édition de liens et la compilation se font en une seule passe en Pascal :) les liens sont explicites contrairement à l'extern du C qui laisse libre interprétation au linker.
16/11/2018, 20h26
bacelar

Citation:

alors, manifestement les développeurs de PDFium ne se préoccupent absolument pas de ceux qui veulent l'utiliser comme une DLL

Sauf que la présence d'une constante de compilation comme "FPDFSDK_EXPORTS", ça sent quand même un usage, peut-être qu'interne à Google, d'une version Dll, peut-être pour des tests.
Parce que, sinon, ça serait bien plus compliqué de générer une Dll à partir d'un code qui n'a pas été conçu pour.

Comme le projet PdfiumBuild est parti en sucette il y a 7 mois, je crains une rupture de compatibilité des sources. Mais cela impliquerait des modifications majeures dans le projet initial PDFium.

Citation:

et comme indiqué dans le projet PDFViewer "Google changed their build system (again?), so new instructions."

Attention à la date du post : "Sep 28, 2016"
PdfiumBuild fonctionnait après ce post.
Google a changer un truc, mais PdfiumBuild a réussi à maintenir le système opérationnel.
Est-ce qu'une modification d'encore plus grande ampleur est cassé le système et ça fait 7 mois que les mainteneurs rament ? Moi, je suis plutôt sur l'optique que les mainteneurs ont laissé le projet vivre tout seul via des updates automatiques des sources bien avant les 7 mois. Et que personne n'a cherché à corriger le "problème" même s'il est minime.
C'est en cela que je vous proposais de contacter les différents mainteneurs.

Parce que, si des personnes qui ont réussi à faire PdfiumBuild galèrent à rendre le projet Ninja "Dll-isable", je ne pense pas qu'un non spécialiste du C++ (voir du C, parce que le code dans "pdfium_test.cc", c'est pas super super objet) puisse le faire rapidement, et même un spécialiste qui ne connait pas les projets PDFium et Chromium.

Citation:

Dès lors l'API de PDFium.dll est un choix indépendant de PDFium si je ne m'abuse.

Je ne comprends pas où vous voulez en venir.
Pour l'instant, la dernière version de PDFium.dll ne correspond pas aux dernières sources de la librairie PDFium fourni par Google, mais à une version plus ancienne.

Citation:

Ce que je cherche à faire c'est de rendre les "annotations" éditables, ça fonctionne presque avec la DLL standard mais il me manquerait la possibilité de faire un rendu d'une annotation (celle qui est active) par dessus les autres, et de comprendre pourquoi quand je change la position de certaines d'entres elles via FPDFAnnot_SetRect(), je n'ai pas le résultat escompté.

Ce que je comprends de ces choses (je ne connais absolument rien sur ces librairies, désolé), c'est que ce n'est pas un simple ajout mais une modification du comportement.
Il est peut-être possible que vous cherchez avec faire soit implémentable juste pas ajouts mais c'est pas gagné.
Vous pouvez toujours valider ou invalider cette hypothèse en essayant de l'implémenter dans les sources du projet initial, dans la lib donc.
Vous implémentez un client rudimentaire pour tester vos modifications, en utilisant les outils de Google, pas VS-MSVC malheureusement.

Si vous y arrivez juste par ajouts de fonctionnalités et que la version qui a servi de base à la dernière Dll est compatible avec vos modifications, l'approche "poupée russe" peut fonctionner.
Vous créez dans VS-MSVC un projet Dll, où vous mettez le code que vous avez mis au point lors du développement de vos ajouts de fonctionnalité dans l'environnement Google.

Avec un peu d'attention, la compatibilité au niveau code source entre VS-MSVC et Google-Clang ne devrait pas poser trop de problème.
On pourrait faire le même raisonnement sur tout le projet PDFium et pas juste vos modifications, mais comme il n'y a pas de fourniture d'une version du projet directement pour VS ou un outils de génération de projet compatible VS, il y a des chance qu'ils n'ont pas trop fait attention à la portabilité du code entre les compilateurs.
On peut faire attention à la portabilité du code dans vos modifications, mais, à la vue de la taille de PDFium en entier, c'est une tâche bien plus longue, et les mainteneurs de PDFium peuvent ne pas vouloir de vos modifications.

Ensuite, vous intégrez à votre projet VS-MSVC Dll le package Nuget de PdfiumBuild pour pouvoir utiliser la lib compatible MSCV de PDFium.dll et donc utilisez les fonctionnalités de la Dll PDFium.dll pour l'implémentation de votre code.
Moyennant quelques modifications potentielles dans VOTRE code source, votre nouvelle Dll étendant PDFium.dll pourra être utilisée à la place de PDFium.dll (impliquant du code "passe-plat" pour que votre Dll appelle les primitives de PDFium.dll pour les fonctions que vous n'avez pas modifiées mais que vous voulez offrir aux utilisateur de votre nouvelle Dll) ; soit en plus de PDFium.dll , si vos modifications permettent d'utiliser les 2 Dll (la vôtre et PDFium.dll) en même temps.

Si vos modifications ne se contentent pas de juste des ajouts mais des modifications directement dans le projet PDFium, le plus "simple" serait de "réparer" PdfiumBuild pour qu'il génère de nouveau PDFium.dll.
Une fois réparé, vous en servirez pour générer votre version de la Dll PDFium.

Une autre solution, c'est de créer un projet Google-Clang Dll et vous essayez de remettre tout le code de PDFium dedans. La dll généré par cet outil est compatible avec "tout", contrairement à la lib.
Mais, à la vue de la complexité de génération de la lib, remettre tout PDFium dans ce projet, c'est peut-être pas gagné.

P.S: Pourquoi avez-vous besoin absolument d'une version Dll de PDFium et pas juste utiliser les outils Google-CLang pour vous servir de la version LIB, et aussi l'étendre ?

Citation:

et tant qu'à faire je me suis dit que si j'étais capable de produire une DLL à partir des sources de PDFium, je pourrais changer librement l'API en tapant aussi bas que je le désire dans le code d'origine

Sauf qu'il n'est pas évidant que ces sources aient les qualités de portabilité entre compilateur qui permettent de faire cela facilement.

Citation:

En fait j'ai été sans doute mal éduqué par Delphi; dans ce langage, il suffit d'ajouter tous les "uses" (équivalent d'import en Java) de tous les modules nécessaires et hop ça compiler...ou pas, mais le compilateur vous met le nez sur l'erreur car l'édition de liens et la compilation se font en une seule passe en Pascal les liens sont explicites contrairement à l'extern du C qui laisse libre interprétation au linker.

C'est la même chose en C++, quand on reste dans la même chaine de compilation.

Comme C++ est bien plus "ouvert" que Delphi, il y a beaucoup d'intervenant dans cet égo-système, qui ne se mettent pas forcement d'accord.
Avec les avancées régulières de normalisation depuis quelques années, on a espoir que cela se simplifie.
16/11/2018, 22h25
Paul TOTH

Citation:

Envoyé par bacelar

P.S: Pourquoi avez-vous besoin absolument d'une version Dll de PDFium et pas juste utiliser les outils Google-CLang pour vous servir de la version LIB, et aussi l'étendre ?

parce que je travaille sur une grosse application sous Delphi dans laquelle j'affiche des PDF (avec PDFium.dll) sur lesquels je veux pouvoir gérer les annotations (pas possible avec PDFium.dll en l'état).

il est possible de lier des .obj dans un projet Delphi, mais cela ne fonctionne bien qu'avec des .obj sans dépendances externes (jpeglib, zlib...) car Delphi possède son propre runtime différent du C++, et s'il n'est pas simple de gérer les dépendances en C++, le faire sous Delphi (avec des .obj) est encore pire.
19/11/2018, 11h20
bacelar

Merci pour cette justification tout à fait recevable.

Si j'en crois l'article suivant, il y a pas mal de choses qui bougent dans le domaine de "l'interconnexion", Delphi vers C.
http://rvelthuis.de/articles/articles-cobjs.html

Je pense que vous devriez vous concentrez sur la modification des sources de PDFium pour vos fonctionnalités dans la lib Clang, et la création d'un client écrit en C ou C++ utilisant la librairie statique avec CLang.
VS peut utilisez CLang maintenant.
https://blogs.msdn.microsoft.com/vcb...2016-released/

Si vous n'avez pas besoin des fonctionnalités et corrections entre la dernière version des sources compilé par PdfiumBuild et la dernière version de PDFium, vous pouvez rapatrier les sources correspondant à cette version et faire vos modifications/extensions depuis ces sources.
Comme elles sont compilables en Dll, si vos modifications restent compatibles avec PdfiumBuild, vous pourrez générer une version "étendue" de la Dll via les manipulations implémenté dans PdfiumBuild.

Mais il sera toujours possible de sortir/wrapper dans une Dll, généré avec Clang, juste une partie de l'API que vous avez besoin depuis la dernière version des sources.

Bonjour,

Alors j'ai avancé sur la question, en fait en lisant la doc de GN, j'ai pu créer une DLL qui expose ce que je veux, j'ai même réussi à créer une solution qui s'ouvre sous VS

voici la marche à suivre

1) créer une DLL dans un sous répertoire "dll" par exemple avec un source madll.cc
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 #include <windows.h> #include "public/fpdfview.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } int WINAPI test(void) { FPDF_InitLibrary(); ///.... }
dans le même répertoire, créer un fichier BUILD.gn
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 shared_library("madll") { cflags = [] ldflags = [] sources = [ "madll.cc", ] defines = [ "PNG_PREFIX", "PNG_USE_READ_MACROS", ] deps = [ "../:pdfium", "//build/win:default_exe_manifest", ] }
à la racine du depo, dans la fichier BUILD.gn il faut ajouter ce source dans le group pdfium_all
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 group("pdfium_all") { testonly = true deps = [ ":pdfium_diff", ":pdfium_embeddertests", ":pdfium_unittests", "//dll:madll, ] if (pdf_is_standalone) { deps += [ ":fuzzers", ":samples", ] } }
il ne reste plus qu'à générer ce qu'il faut pour ninja et VS
Code:

1 2 gn gen out/MaDLL --ide=vs
cela produit un fichier out/MaDLL/all.sln pour Visual Studio

et on peut compiler le projet avec ninja en ligne de commande
Code:

1 2 ninja -C out/MaDLL madll
j'oubliais, pour défnir les paramètres de compilation il faut ajouter un fichier out/MaDLL/args.gn

par exemple
Code:

1 2 3 4 5 is_component_build = false is_debug = false symbol_level = 0 target_cpu = "x86"
il reste quelques zones d'ombre mais j'obtiens une DLL qui fonctionne c'est le but tout de même :)

20/11/2018, 11h20
bacelar

Merci pour ce retour très détaillé sur la marche à suivre.

Je suis très surpris de la "facilité" de la chose par rapport aux manipulations que faisait PdfiumBuild.

Les personnes de Google ont peut-être un peu "rationalisé" leur projet.

Pouvez-vous vérifier que votre fonction "test" est bien exporté, et explorté avec le "mangling" C et pas C++ ?
Utilisez des outils comme dependency walker ( http://www.dependencywalker.com/ ) pour bien vérifier qu'est-ce qui est exporté par la dll en comment.

"FPDF_InitLibrary" devrait déjà être exporté correctement, donc pas besoin de la fonction test "dans l'absolu".

Si tout est bien exporté ( à absolument vérifier avec dependency walker ou autre, comme DUMPBIN ), vous êtes dans la situation optimale, en gardant Ninja comme mécanisme de construction.

Attention à ne pas mettre d'appel de fonction "complexe" dans DllMain ("FPDF_InitLibrary" semble être le bon exemple de chose à ne pas mettre dans DllMain).

Maintenant que vous avez surmonté tout seul les spécificités de PDFium, on pourra plus facilement vous aidez sur les aspects purement C++. :aie:
20/11/2018, 17h06
Paul TOTH

Alors oui j'ai un peu galéré sur le mangling en effet, j'étais passé par extern "C" pour supprimer le mangling C++ et un .def pour supprimer le manglling C, mais je me retrouvais avec deux exports, "test" et "_test@8", j'ai pu supprimer le second avec WINAPI (je n'ai pas cherché à comprendre ce que ça déclarait) et je n'ai pas vérifié si le .def était toujours nécessaire.

au niveau C++ je suis aussi un peu perdu, j'ai besoin de décomposer la fonction FDPF_RenderPage

plus exactement, je veux pouvoir afficher une annotation par dessus les autres (celle que je veux déplacer), par défaut elles sont dans l'ordre naturel ici

comme je suis dans un contexte de rendu à l'écran, je dois pouvoir simplifier le code mais rien que cette ligne est assez obscure pour moi :)

si j'en crois la logique du code, ça doit correspondre à la création d'une instance de CPDF_PageRenderContext qui est supposément libérée ici

mais alors pourquoi ici c'est fait différemment, et quand ce contexte est-il supprimé ?
20/11/2018, 20h22
bacelar

Flute, il semble qu'il faut un compte Google pour cloner un dépôt Git sur googlesource ? (à moins que c'est le firewall de la boite qui fait du zèle :aie:)

Si vous avez une version opérationnelle de PDFium.dll que vous avez récupéré de PdfiumBuild, utilisez dependency walker pour bien vérifier que votre manière de générer la Dll exporte les fonctions de la même manière que PdfiumBuild.

Cela permettra de savoir ce que Delphi a besoin pour fonctionné, c'est, ou des noms "manglés" pour en déduire des informations précieuses comme les conventions d'appel (stdcall (à la PASCAL) ou cdecl (à la C)) ; ou des noms "nettoyés" pour ne pas faire peur à l'usagé, mais qui oblige à une convention d'appel "en dûr" etc...

Si vous supprimez tout "manglling C", via .def, vous pourrez appeler des fonctions avec les mauvaises conventions d'appel, ce qui est catastrophique.

Le C++ est assez souple pour permettre plusieurs conventions d'appel et de passage de paramètres différents. Il faut faire attention, surtout quand on est sur des modules avec des langages de programmation différents, que le code appelant et le code appelé utilise les mêmes conventions, d'où le "mangling C". Je suis donc assez réticent à l'usage .def car il peut cacher de gros problèmes de convention d'appel.

Citation:

"test" et "_test@8"

"test" est, normalement, une fonction demandant d'utiliser les conventions d'appel et de passage de paramètre du C (le cdecl)
"_test@8" est, normalement, une fonction demandant d'utiliser les conventions d'appel et de passage de paramètre du PASCAL/API WINDOWS (le stdcall)

Donc, utiliser un .def pour cacher l'un par l'autre, c'est très dangereux.

Il serait plus sûr de bien vérifier que Delphi n'appelle que des fonctions utilisant des conventions d'appel C et faire les actions nécessaires pour que la Dll n'exporte que ce type de fonction.
Je suis à peu près sûr que c'est la fonction de la constante de compilation "FPDF_CALLCONV" vue dans les extraits que vous nous avez donnés.
Vérifiez que sa valeur est en correspondance avec les attentes de Delphi, sinon, je pense que quelques "define" dans les fichiers de build pourrait facilement corriger le problème.

Citation:

j'ai pu supprimer le second avec WINAPI (je n'ai pas cherché à comprendre ce que ça déclarait) et je n'ai pas vérifié si le .def était toujours nécessaire.

Je ne suis pas sûr de comprendre. "WINAPI", c'est un peu la même chose que "stdcall". En ajoutant WINAPI on devrait passer de "test" à "_test@8" et pas l'inverse.

Citation:

au niveau C++ je suis aussi un peu perdu, j'ai besoin de décomposer la fonction FDPF_RenderPage

Le code n'est pas vraiment un exemple de code "propre". Une fonction de plus de 50 lignes, c'est jamais très bon.
Le code est assez caractéristique d'une conception assez datée du code C++, plus proche du C que du C++ moderne.
Mais il y a l'usage de pas mal de concepts modernes du langage C++.
C'est un peu un code hybride : archaïque mais qui est sur le chemin de l'évolution.
Je signale cela car ça intervient dans les lignes que vous signalez.

"FPDF_EXPORT" dans la signature des fonctions montre bien qu'il y a tout ce qu'il faut pour facilement générer une Dll, je comprend pas pourquoi Google ne la "diffuse" pas.

Citation:

plus exactement, je veux pouvoir afficher une annotation par dessus les autres (celle que je veux déplacer), par défaut elles sont dans l'ordre naturel ici

Il y a peut-être déjà tout ce qu'il faut dans la fonction "DisplayAnnots".
Comme je peux pas cloner ce repot, et qu'il y a beaucoup beaucoup moins de fonctionnalités dans "googlesource" que dans GitHub, c'est compliqué de naviguer dans les sources.

Citation:

comme je suis dans un contexte de rendu à l'écran, je dois pouvoir simplifier le code mais rien que cette ligne est assez obscure pour moi

C'est l'un des exemples qu caractère "hybride" de ce code, qui ne simplifie pas du tout sa lecture.
"pdfium::MakeUnique" doit être un pis-allé de "std::make_unique" (https://en.cppreference.com/w/cpp/me...tr/make_unique) ajouté à la norme C++ en 2014 (C++14).
Dans la présentation du projet Chromium, c'est indiqué que les sources doivent être C++11 (la norme C++ publiée en 2011) mais que les ajouts de C++14 sont en cours "d'évaluation/migration".
En gros, le développeur a voulu utiliser les mêmes "concepts" que le C++14 mais sans utiliser les options de compilations qui vont avec (peur de se faire taper sur les doigts par les mainteneurs du projet, Google ?).

Code:

pdfium::MakeUnique<CPDF_PageRenderContext>()

Si c'est bien le cas, cette ligne, c'est la version "bricolé" de la manière standard (C++14) de créer un objet "dynamique" en mémoire.

Code:

std::make_unique<CPDF_PageRenderContext>()

En version archaïque, super-compliqué à maintenir correctement sans suite mémoire, du C++, ça donnerai simplement :

Code:

new CPDF_PageRenderContext

Citation:

si j'en crois la logique du code, ça doit correspondre à la création d'une instance de CPDF_PageRenderContext qui est supposément libérée ici

Oui. :)

C'est assez bizarre comme manière de faire. On utilise des concepts super évolués (C++14) mais comme si on était encore dans du vieux code.
Ça donne un code peu élégant, comme du vieux code, aussi dangereux (fuite mémoire) que du vieux code, mais avec de nouveaux outils.

Citation:

mais alors pourquoi ici c'est fait différemment, et quand ce contexte est-il supprimé ?

Bin, ici, il s'est même pas pris la tête a utilisé pleinement les nouveaux concepts et fait un autre bricolage pour arriver au même.
Normalement, c'est libéré de la même manière, "pdfium::WrapUnique" doit "vampiriser" la variable "pContext".
Après vampirisation, utiliser "pContext" donne des comportements indéterminés.
C'est pour cela que la version "std::make_unique/pdfium::MakeUnique" est plus "safe".

Merci pour ces retours

alors dans Delphi c'est très simple d'utiliser une DLL en lien statique (sinon c'est comme en C, LoadLibrary/GetProcAdress)
Code:

1 2 function test: integer; external 'madll.dll'; stdcall;
tout est indiqué dans le source, pas besoin d'un .lib, .def ou autre (comme en Visual Basic finalement), le mot clé external précise le nom de la DLL; si elle est omise c'est qu'on a lié un .OBJ avec la directive {$L fichier.obj}, là aussi directement dans le source, pas besoin d'ajouter un paramètre de compilation pour préciser qu'on fait référence à autre chose.
Code:

1 2 3 {$L moncode.obj} function test: Integer; external; stdcall;
mais on retombe sur d'éventuels problèmes de linker car il n'y a pas de lien explicite entre le .obj lié et la fonction externe :)

la convention d'appel Pascal (qui utilise des registres) est différente du stdcall, d'où le mot clé stdcall en fin de ligne; globalement la logique Pascal est l'inverse du C, le "int ()" retourné est donné par ": Integer" en Pascal

si je conserve le mangling C, ça m'oblige à le déclarer, Delphi ne le fait pas pour moi
Code:

1 2 function test: integer; external 'madll.dll' name '_test@8'; stdcall;
idem pour du C++, c'est juste le nom qui change.

donc je préfère comme l'API Win32 ne pas avoir de mangling, et en grand fan de OpenGL je préfère éviter les overload, même si j'ai déjà vu ce genre de chose sous Delphi :
Code:

1 2 3 4 procedure glVertex(x, y, z: Single); external 'opengl32.dll' name 'glVertex3f'; overload; procedure glVertex(x, y, z: Double); external 'opengl32.dll' name 'glVertex3d'; overload; procedure glVertex(x, y, z: Integer); external 'opengl32.dll' name 'glVertex3i'; overload;
ce code consiste à réintroduire de l'overload sur glVertex* alors que l'API utilise un suffixe de type.

21/11/2018, 12h19
bacelar

J'avais oublié que Delphi est basé sur le Pascal. :aie:
Ça fait plus de 25 ans que j''utilise plus de Pascal, c'était même pas objet à l'époque. :oops:

Le fait qu'il fasse spécifier les conventions d'appel dans le code Delphi indique plutôt que c'est au programmeur de faire attention aux conventions d'appel et que la décoration C n'est pas utilisé pour inférer du code d'interconnexion entre Delphi et la Dll.

Citation:

la convention d'appel Pascal (qui utilise des registres) est différente du stdcall, d'où le mot clé stdcall en fin de ligne; globalement la logique Pascal est l'inverse du C, le "int ()" retourné est donné par ": Integer" en Pascal

Heu, c'est pas vraiment ça pour les registres: https://en.wikipedia.org/wiki/X86_calling_conventions
A moins d'une spécificité Delphi ???
J'ai indiqué le terme "pascal" car cela intervient dans la documentation M$, mais la page Wikipédia est bien plus précise.
Oui, "stdcall" est différent de la convention Pascal/Delphi, désolé.

Citation:

tout est indiqué dans le source, pas besoin d'un .lib, .def ou autre (comme en Visual Basic finalement), le mot clé external précise le nom de la DLL; si elle est omise c'est qu'on a lié un .OBJ avec la directive {$L fichier.obj}, là aussi directement dans le source, pas besoin d'ajouter un paramètre de compilation pour préciser qu'on fait référence à autre chose.

Attention, le .def n'est nécessaire que si l'on n'utilise pas les conventions de nommage de Windows ET qu'on n'utilise pas les extensions des compilateurs pour faire cela.
(Et .def, c'est juste pour la génération de la dll, pas pour son utilisation)

Comme je pense que les personnes de Google ont déjà pensées à cela, je suis à peu près sûr qu'en utilisant les MACRO "FPDF_EXPORT" et "FPDF_CALLCONV" sur votre fonction "test" permettra de vous en servir comme les autres fonctions exportées par la Dll.
Pas la peine de faire de la fonction "test" un cas particulier.
Et on est d'accord que c'est juste pour un test, cette fonction "test", non ?

Le .lib, c'est aussi non obligatoire. C'est juste pour ne pas galérer avec les "LoadLibrary/GetProcAdress" et d'utiliser les Dll encore plus facilement qu'en Pascal/Delphi ou en VB6, où il faut faire toutes les déclarations à la main, et sans se planter ni dans la signature ni dans les conventions d'appel.

Citation:

si je conserve le mangling C, ça m'oblige à le déclarer, Delphi ne le fait pas pour moi

Comme indiqué avant, on ne devrait pas se focaliser sur la fonction "test" qui ne sert à rien mais sur l'usage des "vraies" fonctions exportées par la Dll (usage de dependency walker pour savoir où on en est du mangling de ces fonctions).
Il faudrait aussi vérifier que la valeur de "FPDF_CALLCONV" soit en adéquation avec ce que vous donnez comme convention dans votre code Delphi.

Citation:

donc je préfère comme l'API Win32 ne pas avoir de mangling

Heu, non, elle est manglée selon les conventions C + extension Windows (pour les conventions d'appel).

Citation:

et en grand fan de OpenGL

Sauf erreur de ma part, OpenGL utilise une API C avec des conventions d'appel _cdecl, donc elle est aussi manglée selon les conventions C + extension Windows (pour les conventions d'appel).
22/11/2018, 13h18
Paul TOTH

Citation:

Envoyé par bacelar

Heu, non, elle est manglée selon les conventions C + extension Windows (pour les conventions d'appel).

Sauf erreur de ma part, OpenGL utilise une API C avec des conventions d'appel _cdecl, donc elle est aussi manglée selon les conventions C + extension Windows (pour les conventions d'appel).

pour le coup je suis sur de moi puisque Delphi ne gère pas le mangling :)

Pour OpenGL, la seule différence est la convention d'appel stdcall sous Windows et le préfixe "_" sous OSX

https://github.com/tothpaul/Delphi-L...ossGL.pas#L389

et pour Win32 on a juste un éventuel suffixe A ou W pour les fonctions Ansi/Unicode

https://github.com/tothpaul/Delphi/b...nSSPI.pas#L548
22/11/2018, 16h52
bacelar

Ok, comme je fais jamais (plus) de "LoadLibrary/GetProcAdress" et que j'utilise toujours les .lib (qui contiennent ces informations), c'est le genre de détail qu'on oublie.

Citation:

Sauf erreur de ma part,

:aie:

Effectivement des dll Win32 exportent sans suivre les conventions que M$ préconisent, car ils fournissent les .lib, et aussi pour "simplifier" le travail des générateurs de code de glue "langage hôte <-> API C" "basique".

Pour cela, M$ utilise les extensions de MSVC pour piloter le mangling sans avoir recourir au .def.

En utilisant les 2 MACRO, "FPDF_EXPORT" et "FPDF_CALLCONV", je pense que votre fonction "test" suivra les mêmes conventions que le reste des fonctions de la Dll et sera utilisable comme celles-ci sous Delphi.

Vérifiez quand même que la convention d'appel attendue par les fonctions de la Dll (via la valeur de "FPDF_CALLCONV") correspond bien à ce que vous spécifiez dans Delphi.
Comme les conventions de nommage ne seraient pas respecter (via la valeur de "FPDF_EXPORT"), vous devriez tester via le débogueur que les paramètres sont bien compris/transmis.

Citation:

et pour Win32 on a juste un éventuel suffixe A ou W pour les fonctions Ansi/Unicode

C'est pas vraiment du mangling, c'est 2 fonctions différentes, pour faire la même chose. Maintenant, la version A appel la version W après transformation des chaines de caractères.

Bonjour,

je viens de publier le résultat des mes premiers travaux sur github
https://github.com/tothpaul/PDFiumReader

la partie C++ est dans
https://github.com/tothpaul/PDFiumRe...ster/libPDFium

je n'ai pas trouvé comment inclure un fichier version.rc dans le projet..enfin si mais j'ai des erreurs de compilation ce qui ne m'avances pas beaucoup.

NB: je ne sais pas comment on gère les Interfaces en C++, j'ai donc utilisé du code C pour faire tout ça, ça me convient comme ça vu que mon but est d'utiliser la DLL sous Delphi

j'ai testé tout de même la compilation en C, avec TCC car c'est le seul compilateur C que j'arrive à faire fonctionner sans problème..peut-être car il est plus permissif que les autres...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 #include <windows.h> #include <stdio.h> #include "libpdfium.h" int main(void) { IPDFium pdf = 0; IPDFPage page = 0; IPDFText text = 0; unsigned short buffer[1024]; int len; printf("C raw API\n"); PDF_Create(1, &pdf); PDF_LoadFromFile(pdf, "hello.pdf", NULL); PDF_GetPage(pdf, 0, &page); PDFPage_GetText(page, &text); len = PDFText_CharCount(text); PDFText_GetText(text, 0, len, buffer); printf("%d: %S\n", len, buffer); PDF_FreeHandle(text); PDF_FreeHandle(page); PDF_FreeHandle(pdf); text = 0; page = 0; pdf = 0; printf("COM API\n"); PDF_Create(1, &pdf); (*pdf)->LoadFromFile(pdf, "hello.pdf", NULL); (*pdf)->GetPage(pdf, 0, &page); (*page)->GetText(page, &text); len = (*text)->CharCount(text); (*text)->GetText(text, 0, len, buffer); printf("%d: %S\n", len, buffer); (*text)->Release(text); (*page)->Release(page); (*pdf)->Release(pdf); }

30/11/2018, 18h05
bacelar

GG :mouarf:

Citation:

je n'ai pas trouvé comment inclure un fichier version.rc dans le projet..enfin si mais j'ai des erreurs de compilation ce qui ne m'avances pas beaucoup.

Vous pouvez toujours mettre les messages d'erreur dans ce fil de message pour c'est qui connaissent la toolchaine Clang, mais bon, c'est loin d'être la seule Dll sans numéro de version. :aie:

Citation:

NB: je ne sais pas comment on gère les Interfaces en C++, j'ai donc utilisé du code C pour faire tout ça, ça me convient comme ça vu que mon but est d'utiliser la DLL sous Delphi

Il n'y a pas encore de standard au niveau du C++.
Faire une API C++ obligerait l'utilisateur de votre Dll à utiliser le même compilateur, voire la même version de ce compilateur, et les mêmes options de compilation, une énorme galère pour pas grand-chose.

Un programmeur C++ à l'habitude de faire sont wrapping C++ autour de l'API C.
En plus votre API est conçue avec les paradigmes COM, donc pas de problème de conception objet.
De simples CComPtr<IPDFium>, CComPtr<IPDFPage>, etc devrait même suffire pour un usage simple en C++.

Encore Merci.