problem with 'make host' on amd64

[Mark Paulus]

I spent a couple of hours last night trying to do a
'make host' on my amd64 system.  Ran into many problems,
which I wouldn't mind submitting patches for, however....

I would like to have a discussion about best way to
go about fixing this.  Do I need to wrapper all these
problem lines with #ifdef __x86_64__?
Or, is there some set of defines and/or compiler
options I can set to make this work on an amd64
system?

Most of these issues seem to be related to sizing differences,
most notably, the fact that
(void*) is 8 bytes
int is 4 bytes

There were also complaints that we are using __off_t instead
of (long long int) for printf("%lld"), and (_uint_64)
instead of (long long int) also in the printf.

Here's a sampling of the errors:
cc1: warnings being treated as errors
src/fb.c: In function 'fb_osd_update':
src/fb.c:154: error: format '%lld' expects type 'long long int', but argument 4
has type '__off_t'
src/fb.c:154: error: format '%lld' expects type 'long long int', but argument 4
has type '__off_t'
src/fb.c: In function 'hilite_callback':
src/fb.c:359: error: format '%lld' expects type 'long long int', but argument 5
has type '__off_t'
src/fb.c:359: error: format '%lld' expects type 'long long int', but argument 5
has type '__off_t'
src/fb.c: In function 'add_dirs':
src/fb.c:406: error: cast to pointer from integer of different size
src/fb.c: In function 'do_glob':
src/fb.c:437: error: cast to pointer from integer of different size
src/fb.c: In function 'fb_shuffle':
src/fb.c:550: error: cast to pointer from integer of different size
src/fb.c: In function 'fb_next_image':
src/fb.c:654: error: cast to pointer from integer of different size
src/fb.c:660: error: cast to pointer from integer of different size
src/fb.c:664: error: cast to pointer from integer of different size
src/fb.c:670: error: cast to pointer from integer of different size
scons: *** [src/obj/host/fb.o] Error 1

But, first, you need this patch:
diff --git a/include/mvp_atomic.h b/include/mvp_atomic.h
index 827199c..af330df 100644
--- a/include/mvp_atomic.h
+++ b/include/mvp_atomic.h
@@ -11,7 +11,7 @@ static inline unsigned
 __mvp_atomic_increment(mvp_atomic_t *valp)
 {
        mvp_atomic_t __val;
-#if defined __i486__ || defined __i586__ || defined __i686__
+#if defined __i486__ || defined __i586__ || defined __i686__ || __x86_64__
        __asm__ __volatile__(
                "lock xaddl %0, (%1);"
                "     inc   %0;"
@@ -56,7 +56,7 @@ static inline unsigned
 __mvp_atomic_decrement(mvp_atomic_t *valp)
 {
        mvp_atomic_t __val;
-#if defined __i486__ || defined __i586__ || defined __i686__
+#if defined __i486__ || defined __i586__ || defined __i686__ || __x86_64__
        __asm__ __volatile__(
                "lock xaddl %0, (%1);"
                "     inc   %0;"


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[rldiss]

Mark Paulus wrote:

I spent a couple of hours last night trying to do a
'make host' on my amd64 system.  Ran into many problems,
which I wouldn't mind submitting patches for, however....

I would like to have a discussion about best way to
go about fixing this.  Do I need to wrapper all these
problem lines with #ifdef __x86_64__?
Or, is there some set of defines and/or compiler
options I can set to make this work on an amd64
system?

...snip...

I am in the same boat. I'd like to begin building the "host" version on my AMD64 platform, and am running into the identical issues.  Has there been any discussion on this issue?

[stuart-20]

rldiss wrote:

>
> Mark Paulus wrote:
>> I spent a couple of hours last night trying to do a
>> 'make host' on my amd64 system.  Ran into many problems,
>> which I wouldn't mind submitting patches for, however....
>>
>> I would like to have a discussion about best way to
>> go about fixing this.  Do I need to wrapper all these
>> problem lines with #ifdef __x86_64__?
>> Or, is there some set of defines and/or compiler
>> options I can set to make this work on an amd64
>> system?
>>
>> ...snip...
>>
>
> I am in the same boat. I'd like to begin building the "host" version on my
> AMD64 platform, and am running into the identical issues.  Has there been
> any discussion on this issue?

Hi, I don't want you guys to think there isn't any support around here.
  Unfortunately, I'm probably not the one to answer your questions.

 From what I remember, Jon created the host build w/libraries that are
not available on all platforms.  Perhaps that can be your starting point
if you want to wrestle with the problem.  I'm not sure if conditional
compiling is the way to go here.

Even if you get the host to build, it's only really good for debugging
the GUI.  Since the underlying MediaMVP hardware isn't there, not much
works from what I remember.  I think the argument can be made that many
mvpmc features are well represented by other applications (mplayer,
mythfrontend, softsqueeze, vncviewer, xmms, dvarchive, ...) on several
different hosts (redhat, debian, windoze, ...).







------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[rldiss]

rldiss wrote:

Mark Paulus wrote:

I spent a couple of hours last night trying to do a
'make host' on my amd64 system.  Ran into many problems,
which I wouldn't mind submitting patches for, however....

I would like to have a discussion about best way to
go about fixing this.  Do I need to wrapper all these
problem lines with #ifdef __x86_64__?
Or, is there some set of defines and/or compiler
options I can set to make this work on an amd64
system?

...snip...

I am in the same boat. I'd like to begin building the "host" version on my AMD64 platform, and am running into the identical issues.  Has there been any discussion on this issue?

Ok - I've got the main code to compile cleanly by using a couple of macros to cast cleanly from int to pointer and pointer to int.  However, when I try to "run_host.sh", I get a seg fault after the error "createfont: (height == 0) found builtin font System (0)".  I'm wondering if it's trying to tell me that I don't have my X environment setup the way it's expecting.  Is there anything additional I need to do when running the host version of mvpmc?

[Michael Drons]

Can you share your patch?  I have an AMD_64 that I can also test on.  

Thanks, Mike



----- Original Message ----
From: rldiss <rldiss@...>
To: mvpmc-devel@...
Sent: Saturday, December 20, 2008 2:24:00 AM
Subject: Re: [Mvpmc-devel] problem with 'make host' on amd64




rldiss wrote:

>
>
> Mark Paulus wrote:
>>
>> I spent a couple of hours last night trying to do a
>> 'make host' on my amd64 system.  Ran into many problems,
>> which I wouldn't mind submitting patches for, however....
>>
>> I would like to have a discussion about best way to
>> go about fixing this.  Do I need to wrapper all these
>> problem lines with #ifdef __x86_64__?
>> Or, is there some set of defines and/or compiler
>> options I can set to make this work on an amd64
>> system?
>>
>> ...snip...
>>
>
> I am in the same boat. I'd like to begin building the "host" version on my
> AMD64 platform, and am running into the identical issues.  Has there been
> any discussion on this issue?
>

Ok - I've got the main code to compile cleanly by using a couple of macros
to cast cleanly from int to pointer and pointer to int.  However, when I try
to "run_host.sh", I get a seg fault after the error "createfont: (height ==
0) found builtin font System (0)".  I'm wondering if it's trying to tell me
that I don't have my X environment setup the way it's expecting.  Is there
anything additional I need to do when running the host version of mvpmc?

--
View this message in context: http://www.nabble.com/problem-with-%27make-host%27-on-amd64-tp20323596s24862p21102551.html
Sent from the MediaMVP Media Center - Development mailing list archive at Nabble.com.


------------------------------------------------------------------------------
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel



     

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[rldiss]

Michael Drons wrote:

Can you share your patch?  I have an AMD_64 that I can also test on.  

I confess that I gave up.  After a bit more digging, I discovered that, while I had eliminated the sizeof(void *) != sizeof(int) issues in the mvpmc code, the libraries that it relies on also have this problem, and I wasn't willing to fix it throughout all the supporting libraries.

So, I don't think my patches are very useful.  If you were interested, I put the following macro definitions in mvpmc.h and then sprinkled them around any time a ptr => int or int => ptr assignment was made:

#if defined __x86_64__

#define CAST_POINTER_TO_INT(p)          ((int) (long) (p))
#define CAST_INT_TO_POINTER(i)          ((void *) (long) (i))

#elif defined __i386__ || defined __i486__ || defined __i586__ || defined __i686__

#define CAST_POINTER_TO_INT(p)          ((int) (p))
#define CAST_INT_TO_POINTER(i)          ((void *) (i))

#elif defined __powerpc__

#define CAST_POINTER_TO_INT(p)          ((int) (p))
#define CAST_INT_TO_POINTER(i)          ((void *) (i))

#else

#warn "mvpmc.h cannot determine your architecture!"
#define CAST_POINTER_TO_INT(p)          ((int) (p))
#define CAST_INT_TO_POINTER(i)          ((void *) (i))

#endif

Oh, and my solution -- fire up an old x86 box for development.  :-)

-Bob

[Tom Metro-9]

rldiss wrote:
> Oh, and my solution -- fire up an old x86 box for development.  :-)

Shouldn't a virtual machine work for running host mode? I assume you can
run a 32-bit OS guest inside a 64-bit VM host.

In theory someone could set up a VM image with all the mvpmc dev tools,
so all a new dev needs to do is download the image, and run an update
script.

  -Tom

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Andreas Bach Aaen]

Torsdag den 8. Januar 2009 skrev Tom Metro:
 
> In theory someone could set up a VM image with all the mvpmc dev
> tools, so all a new dev needs to do is download the image, and run
> an update script.

Not a bad idea.
I do a little arm development. Often it's faster to do an arm
compilation natively within qemu on a fast x86 machice than on an
embedded arm target. Also you can have more RAM available on the
virtual machine than on the real one.

I run my mythtv backend on a arm based NAS device: a Buffalo
Linkstation. The compilation machine that works for Debian multimedia  
is actually just a virtual arm machine, that runs inside qemu.

So all in all why use a cross compiler for mvpmc when you can use a
native powerpc compiler within a qemu image?

Regards,
--
 /\ ,_  _|,_ _  _  _,  |¨) _  _ |_    /\  _  _ ,_
/¨¨\| )(_|| (-'.-|`-,  |¨).-|(_ | )  /¨¨\.-|(-'| )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Open Source og Linux:  http://www.bachaaen.dk/blog

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[peteshew]

Andreas Bach Aaen wrote:
> I run my mythtv backend on a arm based NAS device: a Buffalo
> Linkstation. The compilation machine that works for Debian multimedia  
> is actually just a virtual arm machine, that runs inside qemu.
>
>
>  
What tuner cards do you use - USB connected to your Buffalo or a
separate box that powers up to do the recordings? I currently have a
Synology DS207+ NAS (with no MythTV) and a separate MythTV server that
is powered down most of the time. I have to power it up to watch stuff
and to set up scheduling, but if it were controlled by the 24/7 NAS that
would be better.

Sorry about the OT post
Pete

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Andreas Bach Aaen]

Fredag den 9. Januar 2009 skrev pslists:
> What tuner cards do you use - USB connected to your Buffalo or a
> separate box that powers up to do the recordings?

I use a usb dvb-t stick.
Analog signalt will be switched off in the fall anyhow here in Denmark

Unfortunately all new channels will be in mpeg4 and not mpeg2, so I am
looking for an alternative for my MVP frontend.

> I currently have
> a Synology DS207+ NAS (with no MythTV) and a separate MythTV server
> that is powered down most of the time. I have to power it up to
> watch stuff and to set up scheduling, but if it were controlled by
> the 24/7 NAS that would be better.
>
> Sorry about the OT post

just change the heading then :-)

Regards,
--
 /\ ,_  _|,_ _  _  _,  |¨) _  _ |_    /\  _  _ ,_
/¨¨\| )(_|| (-'.-|`-,  |¨).-|(_ | )  /¨¨\.-|(-'| )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Open Source og Linux:  http://www.bachaaen.dk/blog

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel