<Fallenou>
lekernel: kristianpaul  : cannot get mupdf to link
<Fallenou>
I git weird messages
<Fallenou>
got*
<Fallenou>
the lm32 toolchain cannot find -lfreetype -ljbig2dec -lopenjpeg -ljpeg and -lz
<kristianpaul>
yeah !
<kristianpaul>
same here
<Fallenou>
even if it is in $RTEMS_MAKEFILE_PATH/lib
<kristianpaul>
lekernel: ^^^^
<kristianpaul>
yes thats weird..
<Fallenou>
and the variable correctly set and so on
<kristianpaul>
exactly !
<lekernel>
there's nothing to link with mupdf, it's a static library only
<Fallenou>
I am just following what's in the wiki
<kristianpaul>
me too
<Fallenou>
and actually it is trying to link cmapdump
<Fallenou>
the line before the errors is
<Fallenou>
LD build/release/cmapdump
<lekernel>
iirc cmapdump should be compiled with your *native* toolchain
<Fallenou>
yes I thought I did
<Fallenou>
I will check why it is not done
<lekernel>
so the Makefile should not touch it again
<lekernel>
mupdf isn't made for cross compiling, so you need a bit of hand-tweaking
<kristianpaul>
harcode Makefile !
<lekernel>
for example compile the code generation tools manually before... then the makefile should think they're up to date and not touch them anymore
<lekernel>
if you can't get that to work,remove the rules in the makefile
<Fallenou>
ok it works now
<Fallenou>
there seem to be a command order issue
<Fallenou>
since I am sure I did the gcc -o stuff before
<Fallenou>
somehow I had to do it after compilation fails
<Fallenou>
and then retry to compile
<Fallenou>
it's fixed for me
<Fallenou>
I will try to find out the real command order and update the wiki
<kristianpaul>
let me check
<Fallenou>
kristianpaul: when the make build=release fails, just do again the two gcc -o commands
<Fallenou>
and then again make build=release .........
<Fallenou>
worked for me
<kristianpaul>
let see
<Fallenou>
ok flickernoise compiles and links without any error
<Fallenou>
let's try it with qemu
<kristianpaul>
cmapdump: could not open output file 'build/generated/cmap_unicode.c'
<kristianpaul>
arg
<kristianpaul>
trying agin
<Fallenou>
:o
<lekernel>
Fallenou: so, works?
<Fallenou>
yes but not if you just follow exactly the tutorial
<Fallenou>
the tutorial needs a little modification
<lekernel>
ah?
<Fallenou>
I think
<Fallenou>
I will try again later
<lekernel>
Fallenou: btw, have you used svn bisect already?
<lekernel>
we need to fix that damn gcc 4.6 bug
<Fallenou>
lekernel: never used svn bisect
<Fallenou>
but used git bisect
<Fallenou>
to spot a problem in rtems
<lekernel>
ok, that's what I feared
<Fallenou>
and it works damn well
<lekernel>
yeah, git tools usually work well
<lekernel>
svn tools don't
<Fallenou>
I try as much as I can to stay away from svn and cvs
<lekernel>
iirc there's an unofficial git mirror of the gcc svn, maybe i'll try with that instead of messing with svn
<Fallenou>
hum there is a missing line too in qemu wiki
<Fallenou>
should add git pull origin milkymist:milkymist
<Fallenou>
right after the clone
<Fallenou>
to get the milkymist branch
<Fallenou>
by default a simple git clone just pulls the master branch
<Fallenou>
on which there is no milkymist file
<lekernel>
yeah or just git checkout milkymist
<Fallenou>
lekernel: when starting flickernoise under qemu
<Fallenou>
I have infinite loop with "milkymist_memcard: read more cmd bytes than available.
<Fallenou>
Clipping
<Fallenou>
and nothing shows up, the screen stays black
<lekernel>
obviously, it's a problem with the memory card emulation
<lekernel>
try disabling it
<lekernel>
or fixing the driver (mwalle posted about the problem on the mailing list a while ago)
<Fallenou>
ok
<kristianpaul>
Fallenou: whicj version of mupdf r u using?
<kristianpaul>
wich*
<Fallenou>
the one in milkymist wiki
<kristianpaul>
the file build/generated/cmap_unicode.c is in your side?
<lekernel>
as well as a "patch store" i.e. a simple online interface, accessible from the M1, where people can browse and upload patches
<rejon>
that is cool
<rejon>
i wonder how we could get that patch store done?
<lekernel>
well it's pretty easy... one part of web and one part of C :)
<lekernel>
there's already unix-like tcp/ip networking available on the board
<lekernel>
with the BSD stack
<lekernel>
the patch store should give the option to the user to try the proposed patches with a single click
<lekernel>
and then download them with another click
<lekernel>
ah, we'll need a filemanager too... unfortunately we can't re-use one since they all need X11 or other crazy libraries
<lekernel>
though it's a rather critical task (atm there's no possibility to delete or rename files in the GUI for example) so I'm not really sure it's fit for gsoc
<lekernel>
but you can still add in the task list, we'll see
<rejon>
yes, totally
<rejon>
what about fixes on the board
<lekernel>
everything should be fine with the board now
<lekernel>
the fpga design still has a few issues with USB, but it's a super crappy job and also needs some hardware
<lekernel>
oh, you can still also add one task to implement OHCI into the USB controller
<lekernel>
same with linux, it would be nice to have (enables a lot of devices and stuff to be supported) but non-critical
<lekernel>
so what I see:
<lekernel>
1. Linux port (device drivers)
<lekernel>
2. patch store + online upgrade
<lekernel>
3. on-video controls
<lekernel>
4. file manager
<lekernel>
5. ohci
<lekernel>
also, maybe LM32 MMU, but I doubt there are many motivated and competent people for that
<rejon>
hahaha
<lekernel>
what? :)
<lekernel>
every geek is asking about it, but no one fucking does it
<kristianpaul>
ask != need
<lekernel>
oh, totally, it's a non-critical task for me :)
<lekernel>
that's why it might belong in gsoc
<rejon>
ok cool
<kristianpaul>
ah,so gcc is critical for you now :-)
<kristianpaul>
eventought you should consider it for gsoc i think.