Vraagje aan de *BSD community

[user]

Ik zie dat mijn tomtom one compatibel is met de hpcarm tak van bvb netbsd.

Nu: zouden die binaries werken, als je de mod van netbsd---> linux toepast,
plus LDFLAGS zet naar de dir met netbsd libs??

http://www.netbsd.org/docs/pkgsrc/platforms.html#linux

ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/hpcarm/4.0/



-- Gezocht netbsd programmeur voor de GSM van MS ... ;-)

--
700+ Radio Stations on SW http://swstations.tk/
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://radiolanguages.tk Updated every month or so ....

[Martijn van Buul]

Post by user
Ik zie dat mijn tomtom one compatibel is met de hpcarm tak van bvb netbsd.

Dan zie je meer dan ik. Waaruit trek je die conclusie? Vziw ondersteunt
NetBSD/hpcarm alleen SA-1110 System-on-a-chip CPU, en zit er in een TomTom
toch echt een ARM920T. Dat mag dan wel een verwante CPUfamilie zijn, maar
daarmee houdt de vergelijking op.

Post by user
Nu: zouden die binaries werken, als je de mod van netbsd---> linux toepast,
plus LDFLAGS zet naar de dir met netbsd libs??

Schrijf je vraag eens in fatsoenlijk Nederlands; misschien begrijpt er iemand
dan *wel* wat je bedoelt; nu is het een onsamenhangende brij van kreten waar
geen touw aan vast te knopen valt.

1) *welke* binaries??
2) *welke* "mod van netbsd---> linux"
3) WTF heeft LDFLAGS daarmee te maken!?

Zoals het er nu staat denk ik dat je uit de Linux-binary compatibiliteit
van NetBSD de conclusie hebt getrokken dat het andersom ook moet kunnen
(lees: NetBSD binaries onder Linux), en alhoewel jij er wel vaker een
bijzonder wereldbeeld op nahoudt is dat wel *heel* erg vergezocht.

Post by user
-- Gezocht netbsd programmeur voor de GSM van MS ... ;-)

Uh, sinds wanneer doe jij recruiting voor Sidekick?

[user]

Post by Martijn van Buul

Post by user
Ik zie dat mijn tomtom one compatibel is met de hpcarm tak van bvb netbsd.

Dan zie je meer dan ik. Waaruit trek je die conclusie? Vziw ondersteunt
NetBSD/hpcarm alleen SA-1110 System-on-a-chip CPU, en zit er in een TomTom
toch echt een ARM920T. Dat mag dan wel een verwante CPUfamilie zijn, maar
daarmee houdt de vergelijking op.

"The ARM920T processor is 100% user code binary compatible
with ARM7TDMI, and backwards compatible with the ARM7
ThumbR Family and the StrongARM processor families"


StrongArm = SA.

Post by Martijn van Buul

Post by user
Nu: zouden die binaries werken, als je de mod van netbsd---> linux
toepast, plus LDFLAGS zet naar de dir met netbsd libs??

Schrijf je vraag eens in fatsoenlijk Nederlands; misschien begrijpt er
iemand dan *wel* wat je bedoelt; nu is het een onsamenhangende brij van
kreten waar geen touw aan vast te knopen valt.

Hou eens op met leeghoofderij.. ;-)

Post by Martijn van Buul
1) *welke* binaries??

de netbsd bins zouden kunnen werken als je die LDFLAGS etc zet die nodig
zijn om netbsd bins te laten werken onder linux. Nu zijn we misschien niet
ver weg van compilatie en installatie van tal van libs, zodat Navit er nog
komt, maar ik vraag me af of dat niet automatisch kan??
http://www.opentom.org/Navit#building_toolchain_.28so_far_.28not_far_enough.29.29


Bestaat er in Redhat ( = tomtom linux) een commando om sources en
dependencies te compileren??

Op debian/ubuntu is dat zo
apt-get -b source pkgname

bvb
apt-get -b source libdvdcss

if the source won't build, try:
apt-get -b build-dep libdvdcss
apt-get -b source libdvdcss

replace the "libdvdcss" with whatever package you want to build.

Post by Martijn van Buul
2) *welke* "mod van netbsd---> linux"
3) WTF heeft LDFLAGS daarmee te maken!?

zie de link
of vergis ik me: ik denk toch dat
http://www.netbsd.org/docs/pkgsrc/platforms.html#linux
gaat over omzetten van pkgsrc naar linux en daar de nebsd pkgsrc systeem
gebruiken??

[Martijn van Buul]

Post by user

Post by Martijn van Buul
Dan zie je meer dan ik. Waaruit trek je die conclusie? Vziw ondersteunt
NetBSD/hpcarm alleen SA-1110 System-on-a-chip CPU, en zit er in een TomTom
toch echt een ARM920T. Dat mag dan wel een verwante CPUfamilie zijn, maar
daarmee houdt de vergelijking op.

"The ARM920T processor is 100% user code binary compatible
with ARM7TDMI, and backwards compatible with the ARM7
ThumbR Family and the StrongARM processor families"

Post by Martijn van Buul
Dat mag dan wel een verwante CPUfamilie zijn, maar daarmee houdt de
vergelijking op.

Een ARM920T kan dan wel een verwante CPU core hebben, maar daarmee is het
nog niet dezelfde architectuur. Een m68K mac, een Amiga en een Atari ST hebben
ook dezelfde CPU, maar de hardware eromheen zorgt ervoor dat het nog steeds
een volledig ander platform is. Datzelfde geldt *nog* meer voor ARM systemen.

De enige conclusie die je uit de beschikbaarheid van ARM-based ports kunt
concluderen is dat het relatief eenvoudig is om een nieuwe port te maken,
*mits documentatie beschikbaar is*.

Post by user

Post by Martijn van Buul
1) *welke* binaries??

de netbsd bins zouden kunnen werken als je die LDFLAGS etc zet die nodig
zijn om netbsd bins te laten werken onder linux.

Nee, dat kunnen ze *niet*. Een *BSD systeem kan Linux binaries uitvoeren,
maar het omgekeerde is absoluut niet het geval. Het is veel meer dan enkel
en alleen een libraryverhaal.

Overigens ontgaat mij het nut nog steeds; wat wil je eigenlijk bereiken? De
enige reden waarom binary compatibility met een ander OS een issue is, is de
beschikbaarheid van binary-only software. Het is handig/prettig om op een
*BSD systeem Linux binaries te kunnen draaien, omdat er vrij veel software
is die alleen als linux/i386 (of linux/amd64) binary beschikbaar is - denk
aan flash, bijvoorbeeld. Het omgekeerde is veel minder het geval; er is
amper software die alleen beschikbaar is als NetBSD binary.

Post by user
http://www.opentom.org/Navit#building_toolchain_.28so_far_.28not_far_enough.29.29

Joh, wat wil je nou eigenlijk bereiken!? Wil je op je stomstom (die Linux
draait) een zelfgebakken binary draaien, en heb je in een vlaag van gekkigheid
besloten dat het frivool gaat wezen om dat via een NetBSD binary te doen!?

Ik weet niet wie deze wikipagina geschreven heeft (ik vermoed een bepaalde
"user" op een domain met een domme taalfout), maar hij heeft weinig kaas
gegeten van cross development. Eigenlijk helemaal geen; misschien moest 'ie
eens beginnen met het lezen van de beschikbare documentatie hierover, want hij
doet zo ongeveer alles fout. Het gaat al mis bij "./configure"; autoconfig is
de nagel aan de doodskist van cross development. De meeste autoconfig scripts
die ik heb gezien zijn bijzonder stuk, en doen zonder meer de aanname dat de
host ook het target is.

Je zult op z'n minst aan configure moeten vertellen dat je wil crosscompileren.
Dat doe je *niet* met enkel en alleen het opgeven van LDFLAGS, en --host is
al helemaal het verkeerde antwoord. Probeer --target eens; misschien is het opgeven van CC, LD en CXX wel voldoende - het hangt allemaal van het autoconfig
script af...

De kans is echter vrij groot dat je autoconfig de prullenbak in moet
gooien en zelf even een makefile in elkaar moet flansen. Maar NetBSD heeft in
dit feestje helemaal niets te zoeken!

Post by user

Post by Martijn van Buul
2) *welke* "mod van netbsd---> linux"
3) WTF heeft LDFLAGS daarmee te maken!?

zie de link
of vergis ik me: ik denk toch dat
http://www.netbsd.org/docs/pkgsrc/platforms.html#linux
gaat over omzetten van pkgsrc naar linux en daar de nebsd pkgsrc systeem
gebruiken??

Wat heeft pkgsrc er nou meer mee te maken!? pkgsrc is een package system,
en is toevallig het 'native' package system van NetBSD en DragonFlyBSD. Het
werkt echter ook op een aantal andere platforms, waaronder Linux. Maar dat
wil nog niet zeggen dat het daarmee "NetBSD" binaries zouden zijn; als je
pkgsrc gebruikt op een Linux systeem, levert je dat Linux binaries op, geen
NetBSD binaries!

pkgsrc is uitdrukkelijk *niet* bedoeld voor cross development.

[user]

Post by Martijn van Buul
maar hij heeft weinig kaas
gegeten van cross development

Die kerel die met de TT bezig is heeft hetzelfde probleem. EN nu ?? Daarom
vraag ik hulp, geen gulp die openvliegt..

[Huub Reuver]

Post by user

Post by Martijn van Buul
maar hij heeft weinig kaas
gegeten van cross development

Die kerel die met de TT bezig is heeft hetzelfde probleem. EN nu ?? Daarom
vraag ik hulp, geen gulp die openvliegt..

Never mind Martijn.

Wat wil je eigenlijk?
Ik lees in verschillende threads dat je iets wil compileren. Dat je het pad
dat OpenTom gebruikt niet bruikbaar vindt.

Ik zie nergens iets van een praktisch probleem.
Een praktisch probleem als:
- ik heb (X) hardware;
- ik wil (Y) software draaien;
- dit lukt niet dus wil ik (Y) (cross)compilen.
Ik ga er vanuit dat je in elk geval bekend bent met "Linux from Scratch"
(het bouwen van een compiler en minimale toolset voor gebruik op
vergelijkbare hardware).

En is het een programma dat alleen wat speelt met geheugen en registers?
Of moet het ook allerlei vage hardware aanspreken?
Bij vage hardware wordt documentatie belangrijk.

Ik verwacht dan iets als "ik loop vast bij het builden van een toolchain
bijvoorbeeld op http://frank.harvard.edu/~coldwell/toolchain/ bij de stap
(Z)".

Graag met meldingen erbij (script is daarbij een handig hulpmiddel).
Vraag van ons geen HOWTO "Hoe compileer ik hello_world.c voor ARM/Linux"
for dummies.

Voor cross-compilen geldt dat je je zelf het kunstje eigen moet maken en
dat simpel "hij doet 't niet" voor de meeste hobbyisten exit betekent.
Zonder goede probleemomschrijving heb JIJ een probleem.

Als je een specifieke vraag hebt over een specifieke architectuur kan ik
wel een NetBSD developper polsen met ARM-ervaring. Als je iets met NetBSD
wil zou je dat natuurlijk ook zelf via de BSD mailinglijst kunnen doen.
Ieder systeem heeft zijn eigen supportmedium. Het uitvinden daarvan is
natuurlijk gewoon part of the game.

Met vriendelijke groet,
Huub Reuver

[Martijn van Buul]

Post by Huub Reuver
Never mind Martijn.

Danku.

Post by Huub Reuver
Wat wil je eigenlijk?
Ik lees in verschillende threads dat je iets wil compileren. Dat je het pad
dat OpenTom gebruikt niet bruikbaar vindt.
Ik zie nergens iets van een praktisch probleem.

Ik *denk* dat 'ie een programma wil compileren voor zijn TomTom, niet weet
hoe met de toolchain van TomTom om te gaan, en nu van ons verwacht dat
wij wel even alles voor hem oplossen.

Crosscompilen is helaas niet zo simpel als het zou kunnen zijn. GNU AutoTools
maakt meer kapot dan je lief is.

Post by Huub Reuver
Ik ga er vanuit dat je in elk geval bekend bent met "Linux from Scratch"
(het bouwen van een compiler en minimale toolset voor gebruik op
vergelijkbare hardware).

Dat werk heeft TomTom al voor 'em gedaan, want er is een nette toolchain
voor linux-i386 die je zo kunt downloaden vanaf tomtom.com.

Post by Huub Reuver
En is het een programma dat alleen wat speelt met geheugen en registers?

Aangezien ik de thread *wel* heb gelezen, en jij blijkbaar niet, weet ik dat
het om Navit gaat (http://www.navit-project.org), een open source navigatie
systeem op basis van X11. Da's dus krek heel wat meer dan enkel en
alleen helloworld.c :-/

Post by Huub Reuver
Of moet het ook allerlei vage hardware aanspreken?

Niet direct, vermoed ik. Ik weet niet hoe de GPS module van een stomstom
precies werkt, maar de kans is heel erg groot dat het gewoon stiekum een
RS232 seriele GPS module heeft. In dat geval valt het met de vage hardware
wel mee - dat neemt de Linux kernel en/of de framebuffer wel voor je over.

Post by Huub Reuver
Ik verwacht dan iets als "ik loop vast bij het builden van een toolchain
bijvoorbeeld op http://frank.harvard.edu/~coldwell/toolchain/ bij de stap
(Z)".

Voor zover ik het kan zien (maar dat is speculatie) heeft 'ie een toolchain
gedownload, maar gebruikt 'ie hem verder niet, behalve dat hij het standaard
includepad er ook naar laat wijzen. Dat levert uiteraard geen werkend
programma op.

Post by Huub Reuver
Graag met meldingen erbij (script is daarbij een handig hulpmiddel).
Vraag van ons geen HOWTO "Hoe compileer ik hello_world.c voor ARM/Linux"
for dummies.

Dat doet 'ie dus wel, alleen begint hij niet met hello_world.c, maar met een
groot project met allerlei dependencies waar ongetwijfeld niet aan voldaan
wordt. Alleen hieruit blijkt wat mij betreft dat "User" niet weet waar hij
mee bezig is; iedere developer die ik ken begint bij het werken met een
nieuwe toolchain met iets simpels als hello_world, helemaal als het een
embedded platform is, en je met crossdevelopment bezig bent.

Ik denk dat "User" het zich allemaal veel te simpel voorstelt[1], en denkt
dat het aan het werk schoppen van een embedded toepassing op een nog-niet-
ondersteund platform een kwestie is van "./configure; make". In dat geval
zal 'ie van een koude kermis thuiskomen, en gaat het hem ongetwijfeld niet
lukken. Gezien de vraagstelling denk ik niet dat je er vanuit mag gaan
dat "User" een doorgewinterde programmeur is - en dat moet je wel zijn om
zoiets tot een succesvol einde te brengen.

Post by Huub Reuver
Als je een specifieke vraag hebt over een specifieke architectuur kan ik
wel een NetBSD developper polsen met ARM-ervaring. Als je iets met NetBSD
wil zou je dat natuurlijk ook zelf via de BSD mailinglijst kunnen doen.

NetBSD heeft er voor zover ik weet helemaal *niets* mee te maken. Die tomtom
draait Linux, en de wetenschap dat NetBSD ook op arm bordjes draait gaat
hier absoluut niet helpen - NetBSD is namelijk nooit geport naar deze
specifieke CPU/toepassing, wat "User" ook mag beweren, en een voor netbsd-arm
gecompileerde 'navit' is voor "User" onbruikbaar, want Linux draait geen
NetBSD binaries.

Tenzij "User" mij kan uitleggen wat de link met NetBSD is - anders dan dat
'ie pkgsrc heeft proberen te draaien - zie ik niet in waarom die mensen moeten
worden lastig gevallen.

Martijn - kan wel lezen.

[1] Ook gebaseerd op eerdere ervaringen met dit sujet

[Huub Reuver]

Post by Martijn van Buul

Post by Huub Reuver
Never mind Martijn.

Danku.

Post by Huub Reuver
Wat wil je eigenlijk?
Ik lees in verschillende threads dat je iets wil compileren. Dat je het pad
dat OpenTom gebruikt niet bruikbaar vindt.
Ik zie nergens iets van een praktisch probleem.

Ik *denk* dat 'ie een programma wil compileren voor zijn TomTom, niet weet
hoe met de toolchain van TomTom om te gaan, en nu van ons verwacht dat
wij wel even alles voor hem oplossen.
Crosscompilen is helaas niet zo simpel als het zou kunnen zijn. GNU AutoTools
maakt meer kapot dan je lief is.

Ah, de link over Navit had ik gemist.

Cross-compilen is niet onoverkomelijk. Feitelijk kun je als je de
Linux-from-Scratch handleiding hebt gevolg ook al bijna cross-compilen.
Alleen moet je dan toch wel links en rechts nog even zoeken.

Voordeel van Linux-from-Scratch is gewoon dat je elke stap voor het
compileren 4x moet doorlopen (2x native en 2x cross). Meeste mensen leren
door het doen, niet door het denken. Vooral als het doel niet voor de
hand ligt.

Met GNU autotools heb ik de meeste programma's die ik wilde compileren
wel aan het werk gekregen. Dat doe je een paar keer zolang je de cvs-versies
volgt, maar daarna werken .deb's en .rpm's toch makkelijker. Het is vrij
eenvoudig als je weet hoe de source-rpm's en de source-deb's een en ander
doen. Maar het is wel veel werk de 1ste keer (en voor elk programma).

Post by Martijn van Buul

Post by Huub Reuver
Ik ga er vanuit dat je in elk geval bekend bent met "Linux from Scratch"
(het bouwen van een compiler en minimale toolset voor gebruik op
vergelijkbare hardware).

Dat werk heeft TomTom al voor 'em gedaan, want er is een nette toolchain
voor linux-i386 die je zo kunt downloaden vanaf tomtom.com.

Linux-from-Scratch gaat niet om de compiler maar om het leerproces.
Misschien wijst TomTom de weg, maar hij zal het zelf moeten doen.

Overigens zag ik ook nog wat geouwehoer over rpm's op een Debian-systeem.
Bij cross-compilen gaat het over de sources. Dan begin je liever met
tar-files als met rpm's of deb's. Een rpm op Debian betekent alleen meer
werk.

Detail: de meeste cross-compile HOWTO's die ik even zag gaan uit van
RedHat. Dus misschien is het toch een stap die je zelf moet doen.
.deb-files maken kan achteraf altijd nog, als je weet hoe alles werkt.

Misschien is het helloworld.c plan niet zo gek.

Post by Martijn van Buul
Voor zover ik het kan zien (maar dat is speculatie) heeft 'ie een toolchain
gedownload, maar gebruikt 'ie hem verder niet, behalve dat hij het standaard
includepad er ook naar laat wijzen. Dat levert uiteraard geen werkend
programma op.

Post by Huub Reuver
Graag met meldingen erbij (script is daarbij een handig hulpmiddel).
Vraag van ons geen HOWTO "Hoe compileer ik hello_world.c voor ARM/Linux"
for dummies.

Dat doet 'ie dus wel, alleen begint hij niet met hello_world.c, maar met een
groot project met allerlei dependencies waar ongetwijfeld niet aan voldaan
wordt. Alleen hieruit blijkt wat mij betreft dat "User" niet weet waar hij
mee bezig is; iedere developer die ik ken begint bij het werken met een
nieuwe toolchain met iets simpels als hello_world, helemaal als het een
embedded platform is, en je met crossdevelopment bezig bent.

Dat doet ie dus niet. Als je script kent (en volgens mij zou je het moeten
kennen of op z'n minst heb je vast ooit ergens gezien), dan weet je dat
het alles vastlegt. Van de ingevoerde commando's tot aan de "ls" tussendoor.

Als je niet weet waar het probleem ligt kun je niet veel knippen, omdat
je misschien belangrijke informatie weglaat. Bij het intikken van "ik heb
dit en dit gedaan" vergeet je nog wel eens een belangrijk commando. Dan
zouden jij en ik zijn meldingen debuggen in plaats van zijn compiler.

Ik voorzie in dat geval veel "Oh, waar dat had ik ook al gedaan"-opmerkingen.
Zonder goede meldingen is fouten zoeken gewoon zonde van de tijd.

Post by Martijn van Buul

Post by Huub Reuver
Als je een specifieke vraag hebt over een specifieke architectuur kan ik
wel een NetBSD developper polsen met ARM-ervaring. Als je iets met NetBSD
wil zou je dat natuurlijk ook zelf via de BSD mailinglijst kunnen doen.

NetBSD heeft er voor zover ik weet helemaal *niets* mee te maken. ...

Misschien een leuk projectje: Navit porten naar NetBSD.
Ik denk dat de NetBSD-developpers wel hier en daar wat tips willen geven.
Nadat user laat zien dat hij serieus bezig is ;-)

Van user weet ik niet of hij ooit wel eens iets heeft gecompileerd vanaf
CVS/SVN als een KDE of Gnome-programma. Martijn zal met mij eens zijn
dat dit meestal een leuke kennismaking is met autotools. En genoeg
om menig ideaal te smoren.

En ik ben met Martijn eens dat Navit waarschijnlijk een stapje verder is.

Maar zoals gezegd heeft elk project zijn eigen communicatiekanelen. Bij
OpenTom kun je verwachten dat het meer een bulletinbord is van "kijk wat
ik in de afgelopen maanden heb gedaan" (kathedral). De meeste hackers
actief met de TT waren volgens mij buiten TomTom al verenigd in een
hackersclub.

Met vriendelijke groet,
Huub Reuver

[Martijn van Buul]

Post by user
Ik zie dat mijn tomtom one compatibel is met de hpcarm tak van bvb netbsd.

Overigens hebben we daar nl.comp.os.unix.bsd voor.