Soucis au niveau de mon RInside

Bonjour à toutes à tous,

Actuellement je suis sur un code en C++ sur codeBlocks.
Voilà un extrait de mon code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <iostream> #include <RInside> #include <stdio.h> #include <stdlib.h> //#include <R.h> //#include <Rmath.h>   using namespace std;   int main(int argc, char *argv[]) { RInside R(argc, argv); R["txt"]= "Hello, world!\n"; R.parseEvalQ("cat(txt)"); // cout << "Hello world!" << endl; return 0; }

---

Et j'obtiens comme erreurs:

Bien cordialement

Je ne connais pas Code::Block, mais tu dois manifestement configurer ton projet concernant les chemins vers les include.

Ou alors utiliser des guillemets plutôt que des chevrons et donner un chemin relatif adéquat.

Je ne crois pas que ce soit les guillemets, mais plutôt le chemin concernant les includes.
Je viens de télécharger le fichier Zip du RInside. Que dois je faire à ce niveau?

J'avais conseillé de faire une recherche sur le forum C++, pas nécessairement de poser la question ici : c'est un problème qui a déjà été posé plusieurs fois
http://www.developpez.net/forums/d11...-dossier-type/
http://www.developpez.net/forums/d83...h-sous-ubuntu/

Bonjour,

As-tu résolu ton soucis de RInside ?
Je suis moi même face à un soucis à ce niveau.
J'utilise également CodeBlocks, sous Windows 7.
A priori, mon soucis n'est pas dans le chemin des #include, mais plutot dans le linkage des lib...

Voici les erreurs à la compilation :

Code:

---

1 2 3 4

obj\Release\main.o:main.cpp|| undefined reference to `Rf_mkString'| obj\Release\main.o:main.cpp|| undefined reference to `Rcpp::Environment::assign(std::string const&, SEXPREC*) const'| C:\R\R-2.13.1\library\RInside\lib\i386\libRInside.a(RInside.o):RInside.cpp|| undefined reference to `Rf_protect'| C:\R\R-2.13.1\library\RInside\lib\i386\libRInside.a(RInside.o):RInside.cpp|| undefined reference to `Rf_cons'|

---

etc...


Je fait bien le lien vers les lib de RInside et de Rcpp mais n'ai pas de lib pour R pur...

Quelqu'un a-t-il la solution ou une piste de réflexion ?
Merci d'avance et bonne journée

A mon avis tu as oublié de référencer des lib (pas dans les includes, mais dans tes options de link)

Je pense aussi qu'il me manque un ou plusieurs link vers des lib !
Mais je n'arrive à savoir quelles lib (en plus de libRInside.a et libRcpp.a) sont à linker...
As-tu déjà utilisé RInside ?

Merci en tout cas

Non, je répondais d'un point de vue général...

Citation:

---

Envoyé par Pinou08

Je fait bien le lien vers les lib de RInside et de Rcpp mais n'ai pas de lib pour R pur...

---

Tu as la lib de R a inclure (de mémoire R.dll ou libR.dll)

Bonjour,
Merci de ta réponse.

J'ai effectivement ajouté le lien vers la dll R.dll, mais Code blocks ou mon compilateur ne semble pas accepter les fichiers dll (mes autres lib sont en *.a)

voici l'erreur à la compilation :

Code:

---

1 2 3 4

C:\R\R-2.13.1\bin\x64\R.dll: file not recognized: File format not recognized collect2: ld returned 1 exit status Process terminated with status 1 (0 minutes, 2 seconds) 0 errors, 0 warnings

---

Existe-t-il un moyen de "convertir" cette dll en .a ? ou bien faut il configurer code blocks différement ?

Merci de votre aide

Elle serait pas 64 bits au lieu de 32? Genre ton env de build est 32 bits et t'as pris par mégarde la dll 64?

Tu inclues le dll comment ? De mémoire, avec gcc/mingw, j'ajoutais simplement -l R.dll -Lc:/bla/bla/blaSinon, tu peux utiliser Dependency Walker pour connaître les dll nécessaire au programme.

Salut

Citation:

---

Envoyé par Pinou08

Existe-t-il un moyen de "convertir" cette dll en .a ?

---

Oui mais c'est atrocement compliqué. Réservé aux experts qui savent ce qu'ils font et uniquement quand c'est impossible de faire autrement.

J'ai personnellement arrêté d'utiliser GCC+MinGW sur Windows car la compilation avec cette plateforme est tout simplement désastreuse, le résultat pas terrible en performance et l'intégration à windows vraiment mauvaise. MinGW, c'est bien pour porter des soft GNU sur Windows, mais si tu es l'auteur de ton programme, je te conseille plutôt de compiler avec cl (le compilo de microsoft) que tu peux avoir gratuitement en installant Visual C++ Express. Il y a même moyen d'avoir la version 64 bits. Il suffit de lancer CodeBlocks depuis une invite Visual Studio Command Prompt pour que celui-ci bénéficie des bonnes variables d'environnement.

Je sais, ça ne résout pas ton problème directement, et tu ne pourras peut être pas si tu as des libs GNU dans ton code, c'est juste un conseil.

J'irai même jusqu'à dire que l'idéal est d'avoir un système d'intégration continue qui va compiler avec plusieurs compilateur (gcc, vc, icc...), lancer les tests, etc. etc.
Sauf que...
Dans ce cas, a priori, RInside utilise Rcpp qui n'est pas compatible avec Visual (voir la FAQ chapitre 2.7).

Citation:

---

Envoyé par gbdivers

J'irai même jusqu'à dire que l'idéal est d'avoir un système d'intégration continue qui va compiler avec plusieurs compilateur (gcc, vc, icc...), lancer les tests, etc. etc.

---

Oui, CMake + CTest fait bien l'affaire, mais j'évite de faire trop vite du prosélytisme pour ne pas faire peur à l'op :mrgreen:.

Citation:

---

Envoyé par gbdivers

Dans ce cas, a priori, RInside utilise Rcpp qui n'est pas compatible avec Visual (voir la FAQ chapitre 2.7).

---

Bah, avec les headers et les DLLs, on doit bien pouvoir faire ce qu'on veut non ? L'op ne veut pas compiler lui même la lib que je sache, ou bien il peut le faire dans une étape indépendante.

Edit : Le post est marqué résolu ? Tu peux nous dire comment tu as fait Pinou finalement ?

Ce qui me chiffonne, c'est quand même qu'habituellement les problèmes d'ABI se soldent par des erreurs de linkage (symbol not found) pas par un brutal "bad file format" c'est pour ça que je me demandais si on n'avait pas affaire à un binaire 64 bits au milieu d'un environnement 32 (ou l'inverse, mais vu le chemin posté par l'OP)

Je pensais plus à une erreur dans la façon de linker la dll dans code block (par exemple, la dll qui serait ajoutée à la liste des fichiers à compiler, comme un .cpp)

Bref, dans tous les cas, la conversion dll -> a n'est pas la bonne approche.
Peut être qu'une copie d'écran de code block pourrait aider (ou alors le script invoquant les commande gcc)

Citation:

---

Envoyé par jblecanard

Oui, CMake + CTest fait bien l'affaire, mais j'évite de faire trop vite du prosélytisme pour ne pas faire peur à l'op .

---

Je suis entrain de tester CDash à la place de Jenkins... mais j'évite aussi de faire trop de pub (c'est bien de garder nos techniques de sioux pour nous faciliter la vie... sinon après les débutants n'auront plus besoin de nous)

Citation:

---

Envoyé par gbdivers

Je pensais plus à une erreur dans la façon de linker la dll dans code block (par exemple, la dll qui serait ajoutée à la liste des fichiers à compiler, comme un .cpp)

---

Si on voyait la ligne de commande on serait plus fixés...il les montre?

Merci à tous, je fatigue pour ce soir, je m'y remet dès demain et vous tiens au courant !
Concernant le post marqué en "Résolu", en réalité ce n'est pas moi qui ai lancé le sujet, donc pas moi qui l'ai résolu, je me suis juste incrusté dans la discussion, ayant un problème à peu près similaire

A demain donc :ccool:

Bonjour à tous,

Merci pour vos conseils ; Effectivement je n'avais pas prêté attention aux versions 32 ou 64 bits des libs que je linkais...En ne pointant que vers les libs 32 bits, je n'ai plus de soucis à la compilation ;)
Pour info, pour linker les libs dans Code Blocks, je passe par :
Project > Build Options > Linker Settings > Link Libraries

Donc plus de problème à la compil', en revanche une fenêtre d'erreur apparaît à l'execution :

Citation:

---

Fatal Error : Unable to open the base package

---

Je pense qu'il s'agit d'un problème de répertoire... J'ajouterai qu'habituellement je travaille avec la version 64bits de R, pour le chargement des packages, etc. ; Et là, forcé, je pointe vers la lib 32bits ; je ne sais pas si ça vient de là...

Pour info voici mon code cpp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <iostream> #include <RInside.h>   using namespace std;   int main(int argc, char *argv[]) { RInside R(argc, argv); R["txt"]= "Hello, world!\n"; R.parseEvalQ("cat(txt)"); cout << "Hello world!" << endl; return 0; }

---

Une idée ??

Les libs 32 et 64 sont dans des répertoires différents ou dans le même ? Ils utilisent le même répertoire de paquets ? Dans ce cas, tu as du installer les paquets 64 et R ne trouve pas les paquets 32 peut être.
Je viens de vérifier chez moi, il n'y a pas de dll dans les libs et ce sont des répertoires commun pour 32 et 64.
Il ne trouve peut être pas le paquet "base" (qui se trouve normalement dans library/base).
En fait, cette erreur me dit quelque chose, je l'ai peut être déjà eu...

Dans la maillist, le dev de RInside parle d'un bug connu avec la version 0.2.4 et il suffit de passer simplement à la version 0.2.5

Le paquet "base" est effectivement dans library/base.
Y a t il un moyen de vérifier où R pointe vers ses paquets ?
Je dis ça car lorsque j'installais de nouveaux paquets, il ne le faisait pas dans le répertoire de R sous library, mais dans Mes document/R/win-library/2.13/nomdupaquet...

Si cette erreur te revient en mémoire (surout la solution ;)) n'hésite pas
Merci en tout cas

Tu as quelles versions de Rcpp et RInside ?

RInside version 0.2.6
Rcpp version 0.9.9

Apparemment c'est un problème assez fréquent, mais je n'arrive pas à trouver une solution efficace...
Je soupçonne un confilt 64/32 mais je n'en sais rien !

Si quelqu'un à un proposition ... ? ;)

Ouf, réussi. Je me souviens pas d'avoir eu autant de problème lorsque j'avais testé RInside sous windows (je crois que je vais rester encore longtemps sous linux :) )
Le problème vient bien du fait que R a besoin du paquet "base" et qu'il ne le trouve pas puisque le répertoire courant est celui de l'application et non celui de R.dll. Normalement, il devrait être possible de faire simplement (en paramétrant l'appel de R pour indiquer le répertoire de recherche des paquets).
J'ai utilisé simplement la variable d’environnement R_HOME pour indiquer le répertoire de R ([codeinline]C:\Program Files\R\R-2.14.1[codeinline] chez moi)

Merci ! je te tiens au courant dès que j'ai le temps pour tester ça
Sans doute lundi matin

Plus simple (j'aime pas devoir modifier mes variables d'environnements) :

Code:

---

1 2	putenv("R_HOME=C:/Program Files/R/R-2.14.1"); RInside R(argc, argv);

---

(HS, pour mémoire) L'explication :
- au démarrage, la fonction Rf_initialize_R() de embeddedR.c appelle la fonction get_R_HOME() de rhome.c pour connaître le répertoire principal de R
- get_R_HOME() teste dans l'ordre : les variables environnement de C, puis les variables d'environnement de Windows, puis les registres de Windows.
- en utilisant putenv(), on peut définir R_HOME dans les variables d’environnement de C

Merci vraiment !!
Plus de problème à l'exécution !! Je vais pouvoir me plonger dans la doc de RInside et avancer un peu dans mon projet...
Si jamais j'ai d'autres soucis, je créerai un nouveau post ! Celui-ci est, du coup, vraiment "résolu"!!

Bon week-end