Bug 10020 - Support M32R target
Summary: Support M32R target
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: Build/Monolithic (show other bugs)
Version: 7.2 (2007.02)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard: 2011BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-18 08:44 UTC by Brice Goglin
Modified: 2018-04-23 21:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch for m32r (4.04 KB, patch)
2007-02-18 08:45 UTC, Brice Goglin
no flags Details | Splinter Review
moduler X-server (32.98 KB, patch)
2007-03-15 20:00 UTC, Kazuhiro Inaoka
no flags Details | Splinter Review

Description Brice Goglin 2007-02-18 08:44:29 UTC
Bug reported by Kazuhiro Inaoka on the Debian BTS twice within the last 7 months.

Patch below to support the m32r target.
Comment 1 Brice Goglin 2007-02-18 08:45:16 UTC
Created attachment 8770 [details] [review]
patch for m32r
Comment 2 Daniel Stone 2007-02-27 01:36:31 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Adam Jackson 2007-03-11 18:22:09 UTC
That patch appears to be against a monolithic X server, which means the odds of this getting applied are astonishingly low.  Is there a corresponding patch for a modular X server?
Comment 4 Brice Goglin 2007-03-12 14:56:13 UTC
I am not the original bug reporter, I forwarded your note to him.

It seems to me that this patch applies to current git:
* xorg/util/imake (first hunk, applies fine)
* xorg/util/makedepend (second hunk, applies fine)
* xorg/util/cf (other hunks, probably with an offset)

From my point of view, this patch is against the modular tree. I agree it changes some utility programs (imake and makedepend) that were used for building the monolithic tree. I don't know whether these programs are still used by the modular server nowadays. But, if the submitter wants these utility programs to work on m32r, and if they are still maintained, the patch should be applied. If they are not maintained anymore, I don't see the point of keeping them in the repo, especially if you don't want to receive any other bug report like this one :)

Thanks.
Brice
Comment 5 Kazuhiro Inaoka 2007-03-15 20:00:32 UTC
Created attachment 9174 [details] [review]
moduler X-server
Comment 6 Daniel Stone 2007-03-15 23:48:55 UTC
hi,
the elf loader is no longer used, as we just use libdl instead, so that part of the patch isn't necessary.
your pci patch also looks flat-out wrong to me: defining it to use linuxPciInit and then ifdef'ing the entire thing out is a bit ... weird.  if m32r has no pci bus at all, then either you should define your own no-op pci init function; or you can just use the linux one, and it will try /proc/bus/pci, and fail because of that.
Comment 7 Kazuhiro Inaoka 2007-03-19 03:01:55 UTC
> the elf loader is no longer used, as we just use libdl instead, so that part of
> the patch isn't necessary.
Is it meaning elf loader's patch should be removed when using libdl?

> your pci patch also looks flat-out wrong to me: defining it to use linuxPciInit
> and then ifdef'ing the entire thing out is a bit ... weird.  if m32r has no pci
> bus at all, then either you should define your own no-op pci init function; or
> you can just use the linux one, and it will try /proc/bus/pci, and fail because
> of that.
Sorry, the patch for Pci.c was including workaround.

Thanks!
Kazuhiro Inaoka
Comment 8 Daniel Stone 2007-03-19 03:11:05 UTC
hi,

(In reply to comment #7)
> > the elf loader is no longer used, as we just use libdl instead, so that part of
> > the patch isn't necessary.
> Is it meaning elf loader's patch should be removed when using libdl?

yes, that's correct.  that file doesn't even exist in the current server.  but as long as libdl works on m32r, then you're okay.

> > your pci patch also looks flat-out wrong to me: defining it to use linuxPciInit
> > and then ifdef'ing the entire thing out is a bit ... weird.  if m32r has no pci
> > bus at all, then either you should define your own no-op pci init function; or
> > you can just use the linux one, and it will try /proc/bus/pci, and fail because
> > of that.
> Sorry, the patch for Pci.c was including workaround.

okay, so we can just ignore this part of the diff?

cheers.
Comment 9 Kazuhiro Inaoka 2007-03-19 03:37:49 UTC
(In reply to comment #8)
> hi,
> (In reply to comment #7)
> > > the elf loader is no longer used, as we just use libdl instead, so that part of
> > > the patch isn't necessary.
> > Is it meaning elf loader's patch should be removed when using libdl?
> yes, that's correct.  that file doesn't even exist in the current server.  but
> as long as libdl works on m32r, then you're okay.
Yes, our libdl works. Please ignore them.

> > Sorry, the patch for Pci.c was including workaround.
> okay, so we can just ignore this part of the diff?
Of course.

Thanks
Kazuhiro Inaoka
Comment 10 Daniel Stone 2008-04-30 01:59:16 UTC
I've merged your patch, minus the xf86sym bits (as they would seem to be indicative of other problems), the Pci.c patch, and the elfloader patch.  To work, configure.ac would still need to be changed; please send an updated patch that works with the autotools when you update to current X sources.
Comment 11 Daniel Stone 2008-04-30 02:09:21 UTC
Removing keyword and block.
Comment 12 Daniel Stone 2008-04-30 02:09:36 UTC
Removing keyword and block.
Comment 13 Jeremy Huddleston Sequoia 2011-10-03 00:35:36 UTC
imake is dead.  Do you still care about this landing?
Comment 14 Adam Jackson 2018-04-23 21:14:24 UTC
I don't know if M32R is still relevant, but the X server basically no longer has any per-arch #defines. As of 1.18 the code this patch touched no longer exists.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.