Link librerie statiche

[Stilgar]

Aggiornamento.
La libreria ".a" essendo scritta in c++ potrebbe avere qualche problema col linker?
Non so, sta di fatto che non ho capito come fare il bind statico.
Amen.
Nel controllare gli howto e demo di Newton-dynamics mi sono accorto che SDL per freepascal è abbastanza indietro ... 2013 per capirci. Ma SDL mi sembra sia un pochino più aggiornato. (Il repository controllato oggi mi dice 5 days ago   release-2.0.4 ...)
C'è qualche repository più aggiornato rispetto a quello jedy?

Stilgar

[Stilgar]

Ciao a tutti.
https://github.com/danpla/sdl2-fpc

Trovato questo

Stilgar

[nomorelogic]

dicci Stilgar, cosa bolle in pentola?

[Stilgar]

Niente.
Avevo tempo e non sapevo come impegnarlo


:p

[nomorelogic]

non ci credo

tira fuori il progetto di esempio hahahahaah

[Legolas]

La libreria ".a" essendo scritta in c++ potrebbe avere qualche problema col linker?
Non so, sta di fatto che non ho capito come fare il bind statico.

In teoria no, in pratica devi stare attento all'ordine in cui le librerie esterne vengono linkate nel tuo eseguibile, ma questo vale anche per librerie scritte in c. Se ti va di condividere in uno zippone il punto in cui ti sei bloccato, posso provare a darci uno sguardo

[Stilgar]

https://sourceforge.net/p/lazarusiug/liug/HEAD/tree/trunk/bindings/newtonApplication/

Ho già pubblicato lo stato attuale su sourceforge.
Se non sbaglio sei già amministratore come  "p4p3r0" ..
Non ti arrivano le notifiche per mail?

Stilgar

[Legolas]

Uh... no, in effetti 

Devo vedere se mi vanno in spam o le ho disattivate sul profilo...

Comunque vedo di darci un'occhiata

EDIT: appunto, avevo le notifiche disattivate 

[Stilgar]

Mingw mi sta facendo impazzire.
Ho creato una macchina virtuale e ho installato debian.

Vediamo se sotto linux le cose vanno meglio

Stilgar

[Legolas]

Ok, ho avuto modo di giocareci un pochino per vedere come linkare staticamente la baracca.

La risposta è che non si può, almeno non direttamente. Provando a linkare la libreria statica libNewton.a, il linker non trova delle funzioni (_Z1vattelappesca). Quel prefisso _Z1 indica che si tratta di nomi di funzioni mangled, assegnate dal compilatore c++.

Per accedervi dal free pascal, come dicevo, bisognerebbe wrappare la libreria c++ in una c, compilarla con gcc e utilizzare la libreria ottenuta, nella quale non ci dovrebbero più essere nomi di funzioni mangled, per linkarla con il free pascal.

Si stava lavorando su una soluzione interna, che permette di dichiarare classi presenti in una libreria esterna in c++, ma al momento è tutto fermo. L'ho provata su una libreria semplicissima e sembra funzionare, ma ho paura che per una libreria complessa come newton non sia ancora pronta... In ogni caso, se vuoi darci un'occhiata:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/cg/tcppcl1.pp
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/cg/tcppcl2.pp

PS. Che problemi ti da Mingw?

[Stilgar]

Gli stessi che hai appena spiegato tu
Speravo fosse una menata del porting per windows del GCC visto che la versione di Linux non introduce "_" prima del nome della funzione

Controllo i link che hai messo.

Grazie.

Stilgar

[Stilgar]

Legolas.
Se controlli i log del linker su Windows e quelli del linker su Linux sono abbastanza differenti.
Quello per Windows si incasina con i nomi e basta.
Quello per Linux mi indica problemi con le classi c++

Per questo dicevo che Mingw mi faceva impazzire

Sembra che il linker si trovi a non trovare i simboli con "classe->metodo", ma in effetti sono le funzioni wrapper (newton le wrappa già per poter esporre funzioni semplici tramite dll) a chiamare le classi internamente. Quindi newton ha già "Spianto" le funzioni.
Riwrapparle non credo risolva il problema 
 

(Si lo so.. mettere su una macchina virtuale con Linux per lanciare una compilazione è come asciugarsi i capelli con un turbo reattore per aerei, ma visto che c'ero mi sono preparato anche un macchina virtuale con haiku os, tanto per vedere il porting lazarus girare ).

Stilgar

PS:
Controllando le estensioni al linguaggio che stanno provando vedo i test, ma non il c++ che genera quelle classi.
Poi linkano classe per classe. quindi i ".o" e non la ".a"
Se al linker sotto Lazarus ci fosse un benedetto parametro per dirgli si smenare codice oggetto c++ e non c (o come lo interpreta lui ....)

[Legolas]

Aspe'

Allora, prendiamo il log su windows. Questo è uno degli errori:

C:\lavoro\lazarus\code\libraries\liug\trunk\bindings\newtonApplication\pck\NewtonDemos.lpr(19,1) Error: Multiple defined symbol __ZNK5dgRef9GetTypeIdEv

Facendo un demangling casereccio, si fa riferimento al metodo GetTypeId della classe dgRef. Nei sorgenti non trovo da nessuna parte la funzione spianata GetTypeId che richiama il metodo dalla classe. Per questo dico che non ci sono le funzioni "spianate"

Ci dovrebbe essere da qualche parte un file c con una cosa del tipo

Codice: [Seleziona]

int GetTypeId() {
    return dgRef.GetTypeId();
}

e un file h in cui viene esportata la funzione GetTypeId.

[Stilgar]

Si esiste quel metodo.

Codice: [Seleziona]

class dgRef: public dgRefFlags
{
[..]
   virtual dgUnsigned32 GetTypeId () const;
[..]
}

Il "problema" è che non viene usato in fase di export ....
Quindi cosa serve creare una funzione che prenda in ingresso dgRef * per darti un dato che non "serve" al chiamante esterno?

Sono confuso...

Prendiamo ad esempio questo pezzo di codice:

Codice: [Seleziona]

// Name: NewtonCreate 
// Create an instance of the Newton world.
//
// Parameters:
// *NewtonAllocMemory* mallocFnt -    is a pointer to the memory allocator callback function. If this parameter is 
//                                    NULL the standard *malloc* function is used.
// *NewtonFreeMemory* mfreeFnt -    is a pointer to the memory release callback function. If this parameter is NULL
//                                    the standard *free* function is used.
// 
// Return: a pointer to an instance of the Newton world.
//
// Remarks: this function must be called before any of the other API functions.
//
//
// See also: NewtonDestroy, NewtonDestroyAllBodies
NewtonWorld* NewtonCreate()
{
    TRACE_FUNCTION(__FUNCTION__);
    dgMemoryAllocator* const allocator = new dgMemoryAllocator();

    NewtonWorld* const world = (NewtonWorld*) new (allocator) Newton (dgFloat32(1.0f), allocator);
    return world;
}

// Name: NewtonDestroy 
// Destroy an instance of the Newton world.
//
// Parameters:
// *const NewtonWorld* *newtonWorld - is the pointer to the Newton world.
// 
// Return: Nothing.
//
// Remarks: This function will destroy the entire Newton world.
//
// See also: NewtonCreate, NewtonDestroyAllBodies
void NewtonDestroy(const NewtonWorld* const newtonWorld)
{
    TRACE_FUNCTION(__FUNCTION__);
    
    Newton* const world = (Newton *) newtonWorld;
    dgMemoryAllocator* const allocator = world->dgWorld::GetAllocator();

    delete world;
    delete allocator;
}

La prima funzione chiama 2 classi.
Newton e dgMemoryAllocator.
Crea dgMemoryAllocator e lo passa come parametro al costruttore di Newton.

La seconda a partire dal parametro che gli si passa esegue il cast. Ottiene l'allocator e distrugge entrambe le istanze.

Da quello che mi sembra di capire del tuo suggerimento:
Dovrei creare delle funzioni del tipo:

Codice: [Seleziona]

void * NewtonWorld(void* instance)
{
  Newton* const world = (Newton *) instance;
  return world->dgWorld;
}

Poi però il codice originale continuerebbe a non usare questa funzione. Quindi mi sfugge il significato di scrivere funzioni che non sono usate internamente

Cioè dovessi mappare tutte le classi (cosa che con i test che hai linkato si potrebbe pure fare ) avrebbe senso spianare tutta la libreria.
Poi però le chiamte "interne" sarebbero fatte lo stesso in c++. Quindi mi sento "confuso e infelice". La trovo una cosa senza senso ... poi mi sbaglierò e verrà fuori che bisogna simulare le chiamate alla VMT del c++

Da quello che ho capito, la "spianatura" serve solo per le chiamate esterne non in c++.

Stilgar

[Legolas]

Infatti, serviva solo per le chiamate esterne.

Però.

Qualche anno fa mi contattò Gilles Marcou, che stava scrivendo la guida su come linkare in free pascal librerie in c\c+. Mi inviò un'anteprima del documento che stava scrivendo, per controllare se ci fossero inesattezze. Allora, (parlo di circa 10 anni fa!) provai a compilare i progetti di esempio e, se la memoria non mi fa difetto, filò tutto liscio, tant'è che poi la guida è stata pubblicata. 

L'altro giorno ho provato a ricompilare gli esempi della guida e SBAM! sono usciti fuori gli errori che stiamo incontrando con Newton! 

Ora, di cose da 10 anni a questa parte ne sono cambiate, quindi è difficile dire con esattezza cosa può aver determinato gli errori in fase di linking... 

Nel frattempo credo che bisognerà accontentarsi di utilizzare la dll, oppure di "embeddarla" nell'eseguibile come risorsa...