Discussion :

[Jipété]

Bonjour,

après un très long temps sous Windows avec Bass, je décide de voir ce que ça donne sous Linux et, bien sûr, comm' d'hab', y a tout qui foire.

La question que je me pose c'est : "est-ce que tu es vraiment mauvais, mon gars, et que tu ferais bien de raccrocher les valises ?" et pour y répondre, j'ai besoin d'un tout petit projet bass prévu pour Linux (un truc tout simple, hein, juste un bouton pour jouer un fichier sans aucun autre réglage), avant que je ne finisse à l'asile.

Car j'ai téléchargé la dernière de bass (2.4.15), j'ai trouvé sur le web un tout petit truc histoire de me remettre le pied à l'étrier, bon, il faut faire quelques adaptations (windows <> linux) mais au bout d'un moment ça compile, j'ai mis la librairie trouvée dans le zip libbass.so dans /usr/local/lib, dans le dossier du projet et dans le dossier du projet/lib/i386, j'ai modifié les options des Chemins / Bibliothèques et malgré tout ça, quand je tente de l'exécuter, je gagne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./project1: error while loading shared libraries: libbass.so: cannot open shared object file: No such file or directory

Je ne sais plus quoi faire. Il doit y avoir une blague ailleurs mais où ?

Merci à ceux qui répondront,

[Jipété]

Bon, laissez tomber, il suffisait juste de mettre le .so dans /lib.

Ce qui m'a mis dans la pagaille, c'est des tests récents avec uos (rien de cohérent, fuyez !) qui supportait très bien les .so dans /usr/local/lib.

Ce qui est ennuyeux, c'est de lire ça là :

the linker tries:

• directories listed in the LD_LIBRARY_PATH environment variable;
• directories listed in the executable's rpath;
• directories on the system search path, which (on Linux at least) consists of the entries in /etc/ld.so.conf plus /lib and /usr/lib.

ou aussi

Note that the "system search path" for *.so libraries is not the same as $PATH. The search path is as given by @enzotib in their answer. To print out the paths that will be searched, run ldconfig -v 2>/dev/null | grep -v ^$'\t'.

Cette commande me retourne une longue liste de chemins (17) dont entre autres /usr/local/lib où j'avais posé le .so de Bass ce matin et dont il se tamponne allègrement le coquillard.

tout comme il se moque du contenu de /etc/ld.so.conf.d/libc.conf

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# libc default configuration
/usr/local/lib

Le plus dingue, c'est le contenu du fichier texte accompagnant l'archive :

Linux version
-------------
The LIBBASS.SO file needs to be in the OS's library search path for it to
be found; simply placing it in the same directory as the executable won't
necessarily work as it does on other platforms. The BASS libraries should
also not be placed in the standard library directories to avoid version
conflicts. To meet those competing requirements, a wrapper script could be
used to set the "LD_LIBRARY_PATH" environment variable before loading the
executable.

Or il est plus que déconseillé de tripatouiller cette "LD_LIBRARY_PATH" variable.

Encore un mystère insondable…

[BeanzMaster]

Salut JP, j'ai déja eu ce genre de soucis (et sous Windows en plus ) souvent il faut regarder dans le fichier d'en-tête de la bibliothèque

Après je ne sais pas quelle unité de déclaration des en-têtes tu utilises mais dans l'original il n'y a pas de dossier, c'est quand même surprenant qu'il ne trouve pas le fichier "so"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
{$IFDEF MSWINDOWS}
  bassdll = 'bass.dll';
{$ENDIF}
{$IFDEF LINUX}
  bassdll = 'libbass.so';
{$ENDIF}
{$IFDEF MACOS}
  bassdll = 'libbass.dylib';
{$ENDIF}

après dans le "Readme" on trouve cela :

Linux version
-------------
The LIBBASS.SO file needs to be in the OS's library search path for it to
be found; simply placing it in the same directory as the executable won't
necessarily work as it does on other platforms. The BASS libraries should
also not be placed in the standard library directories to avoid version
conflicts. To meet those competing requirements, a wrapper script could be
used to set the "LD_LIBRARY_PATH" environment variable before loading the
executable. Another option is to set the "rpath" in the executable, to tell
it where to look for libraries. That is what the example makefiles do.

When building both 32-bit and 64-bit executables, it is possible to simply
try linking with both LIBBASS.SO versions, and the linker will use the
appropriate version and ignore the other.

Quid ????

A+

Jérôme

[Jipété]

Salut JP, j'ai déja eu ce genre de soucis (et sous Windows en plus )

après dans le "Readme" on trouve cela :

Oui, je l'ai cité aussi, mais pas en entier.

Écoute, ça fonctionne comme ça, avec le .so dans /lib, vais pas me prendre la tête plus (ai déjà perdu suffisamment de temps comme ça avec uos [tu connais ?]), je me suis fait une note dans mon dossier bass24 et voilà.

Amitiés,

PS : je vois ailleurs que tu es toujours à bloc, et avec des trucs (polygones) auxquels je n'entrave que pouic, alors je m'abstiens -- mais je lis !

[BeanzMaster]

Écoute, ça fonctionne comme ça, avec le .so dans /lib, vais pas me prendre la tête plus (ai déjà perdu suffisamment de temps comme ça avec uos [tu connais ?]), je me suis fait une note dans mon dossier bass24 et voilà.

Amitiés,

Oui je connais UOS j'ai testé, mais je la trouve brouillon à utiliser. Tout est en procédurale et les noms des méthodes sont à se tordre le coup et pas très explicites (souvent), c'est dommage à mon avis car c'est une bonne idée à la base. Cette bibliothèque mériterait d'être plus orienté objet, pour être exploité plus facilement. Mais ça c'est mon avis personnel.

PS : je vois ailleurs que tu es toujours à bloc, et avec des trucs (polygones) auxquels je n'entrave que pouic, alors je m'abstiens -- mais je lis !

Oui carrément, par contre pour la transcription du code C en pascal , tu pourrais peut-être me donner quelques explications, car je ne pige pas tout en C et je sais que tu taquine un peu le C

Et mes trucs, polygone et tout et tout c'est que je fignole petit à petit ma bibliothèque sur les bitmaps et là je galère un peu avec les méthodes du "Canvas" et notamment pour créer des contours de plus de 1 pixels.
J'ai également fait des tests en cross-compilation 32 bits et régler pas mal de chose, mais il reste deux trois petites chose, pour la compatibilité 32 vs 64 bits. Sinon ça tourne plutôt bien sous Windows et Linux.
Le plus long c'est la rédaction des commentaires des méthodes pour donner un peu d'aide à l'utilisateur directement dans l'edi. (chose qu'il manque à beaucoup de bibliothèque)
Je me donne encore max 2 mois avant de mettre à disposition les sources continuer son évolution et m'aider.
Il y a pas mal de choses qui vont te plaire j'en suis sûre, j'ai implémenté pas mal de filtres à la Gimp/photoshop (convolution, histogramme, etc....). J'ai essayé de faire en sorte que leur application soit le plus simple possible dans le genre MonBmp.ColorFilter.AdjustContrast(Facteur : Single, TonClair, TonMoyen, TonFonce, PreserveLuminosite : Boolean);

Voilà en gros, mais il y a encore de pas mal de choses (que j'aimerai) incorporer et développer sur le sujet des images, comme tu le sait, il y a de quoi faire sur le sujet (Transformation de fourrier, wavelet, quantization..., meilleurs gestion des espaces de couleurs CIExxx, Lab, etc...)

Bref, tout cela c'est pour bientôt

A+

Jérôme

[Jipété]

Pour uos : moi j'ai trouvé des exemples avec même des binaires (pour Windows), alors je les ai compilés sous Linux, ça a parfois été laborieux ("ça commence mal" je me suis dit), et à l'exécution, certains codes identiques génèrent d'un exemple à l'autre des SIGSEGV ou pas.
C'est juste épuisant.
Je pense que je serai plus productif avec Bass, et puis c'est un retour aux sources pour moi, qui ai connu cette librairie il y a une quinzaine d'années…

Pour le C, détrompe-toi, je suis souvent comme une poule qui a trouvé un couteau, ce langage est terriblement hermétique, exemple avec un bout trouvé dans la démo devlist de bass :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#if 0//def _WIN32
	const char *path = di->driver + strlen(di->driver) + 1;
	if (path[0])
		printf("%s\n\tdriver: %s\n\tpath: %s\n\ttype: ", di->name, di->driver, path);
	else
#endif

C'est quoi ce #if 0//def _WIN32 ? Je ne comprends pas…

Enfin, pose toujours ta question, on verra bien.

Et courage pour le reste, je vois que tu ne manques pas d'imagination, fais gaffe à pas te perdre !