Perché alcuni progetti incorporati evitano la compilazione incrociata?

5

Mentre mi trovo nei sistemi embedded ho notato che alcuni progetti (Arch Arm e OpenBSD per esempio) disapprovano la compilazione incrociata. Qual è il ragionamento per questo? Un binario compilato in modo incrociato è in qualche modo diverso da uno compilato in modo nativo?

OpenBSD suggerisce che la costruzione dell'hardware garantisce che il sistema sia completamente funzionale (e anche auto-ospitante) e che abbia perfettamente senso. Ma le persone effettivamente sviluppano e compilano i driver del kernel sull'hardware per cui si stanno sviluppando? Sembra molto dispendioso in termini di tempo.

Da Domande frequenti su OpenBSD:

"Gli strumenti di cross-compiling sono nel sistema, per essere usati dagli sviluppatori per creare una nuova piattaforma, ma non sono mantenuti per uso generale."

- link

Vedrò se posso rintracciare il registro IRC in cui uno sviluppatore di ArchLinux Arm mi ha detto che non eseguono il cross-compile, anche se sembra che abbiano aggiornato le loro informazioni sulla compilazione incrociata con DistCC: link

    
posta tpaul 24.02.2014 - 15:22
fonte

1 risposta

1

Per progetti come Arch Linux ARM e OpenBSD che stanno cercando di costruire e mantenere un ambiente utente interattivo complicato, una strong preferenza per fare "build native" (nella terminologia di OpenBSD) costringe gli sviluppatori a " mangiare il proprio cibo per cani "e minimizza il problema MxN di mantenere i generatori di codici M in ambienti N.
Per un progetto di sistemi embedded con un ambiente di destinazione e un codice di applicazione sotto il controllo di un piccolo gruppo di sviluppatori, tale ragionamento non si applica.

    
risposta data 01.05.2014 - 22:22
fonte

Leggi altre domande sui tag