mupen64plus-ui-console compilation error with SHAREDIR
Jared Breland
current mercurial version. The ebuild mostly works fine, but I'm
encountering a really strange error when it builds the console:
Here's the relevant output:
make -j3 -C mupen64plus-ui-console/projects/unix all PREFIX="/usr/
games" SHAREDIR="/usr/share/games" LIBDIR="/usr/games/lib64" DESTDIR="/
tmp/portage/games-emulation/mupen64plus-9999/image/"
make: Entering directory `/tmp/portage/games-emulation/
mupen64plus-9999/work/mupen64plus-ui-console/projects/unix'
CC _obj/cheat.o
CC _obj/compare_core.o
CC _obj/core_interface.o
CC _obj/main.o
CC _obj/plugin.o
../../src/main.c:58: error: ‘usr’ undeclared here (not in a function)
../../src/main.c:58: error: ‘share’ undeclared here (not in a
function)
../../src/main.c:58: error: ‘games’ undeclared here (not in a
function)
../../src/main.c:58: error: expected ‘,’ or ‘;’ before string constant
make: *** [_obj/main.o] Error 1
Line 58 in main.c, btw, is:
static const char *l_DataDirPath = SHAREDIR;
Now, here's the weird part: this only occurs when compiling through
portage. If I take that same make command and run it manually from
the portage temp dir, it'll compile and link just fine. Also, if I
remove the SHAREDIR setting for the parameter list, it'll build fine
through portage as well.
Any idea what might be causing this? I'm afraid my C skills are quite
lacking, so I haven't had much luck troubleshooting this myself.
Would appreciate any pointers.
Thanks.
Sven Eckelmann
Please write it in portage without "". I would guess that portage interprets
it in a different way than your shell. So your shell would remove (actually
use it to find the start of a string) it and give that information to make as
/usr/games/share. It seems that portage doesn't do that (please correct me...
I don't have access to a gentoo machine right now).
Kind regards,
Sven
Jared Breland
Very odd, though. I've never seen that happen before. Though as long
as it works, I'm not complaining.
Now, to figure out why the plugin path isn't being detected
properly... Appreciate the help. Hopefully I won't have to bother
you any more.
Sven Eckelmann
What do you mean by "detected properly"? If you want something specific then
you have to specify it everywhere during the all/install make target with
PLUGINDIR=...
Otherwise it will just search in /usr/local/lib/mupen64plus or
/usr/lib/mupen64plus or .
The same thing can be done for the path to the core (libmupen64plus.so.2). It
can be set using COREDIR=...
Some hints: The ebuild should use OPTFLAGS= to prevent any extra optimizations
not enabled by the user (currently -O3). Also V=1 can be used to get the full
output of the build system. I don't know what the current gentoo policy says
about build verbosity. PIC/PIE[1] can be enabled using PIE=1 and PIC=1.
Otherwise it would be disabled on 32 bit x86 architectures.
The plugins from https://bitbucket.org/wahrhaft are also quite interesting as
they are the only (as far as I know) alternatives to the plugins maintained by
Richard. And mupen64plus-rsp-z64 (which is usually used together with the low
level video plugin mupen64plus-video-z64) can be used with high level video
plugins and still provide low level audio emulation when compiled/installed
with HLEVIDEO=1. Also mupen64plus-video-glide can provide a better visual
experience for some roms (but we are still waiting for someone to step up and
port glide napalm to 64 bit with support for mupen64plus ;) ).
Kind regards,
Sven
[1] http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml
Jared Breland
last couple nights, so I haven't been able to spend any more time on
mupen64plus yet, but I'm sure this will come in handy.
Just to answer your question about the plugins, I mean it's not
searching the path where they're installed, and I did set PLUGINDIR
during compilation. I'm sure I probably overlooked something,
somewhere, just haven't had time to dig into it yet.
Jared Breland
after all. I was confusing that with LIBDIR in my second post.
Appreciate the tips once again.
Sven Eckelmann
> Just FYI, I got everything working now. It was related to PLUDINDIR
> after all. I was confusing that with LIBDIR in my second post.
Ok :D
I am just a little bit curious about the current state of the ebuild. Do you
want to publish it over Gentoo or was it only for personal use?
I am the maintainer of the Debian package and maybe we can share backported
patches. An overview of all patches in current versions of Debian can be
found at:
* http://patch-tracker.debian.org/package/mupen64plus-audio-sdl
* http://patch-tracker.debian.org/package/mupen64plus-core
* http://patch-tracker.debian.org/package/mupen64plus-input-sdl
* http://patch-tracker.debian.org/package/mupen64plus-rsp-hle
* http://patch-tracker.debian.org/package/mupen64plus-rsp-z64
* http://patch-tracker.debian.org/package/mupen64plus-ui-console
* http://patch-tracker.debian.org/package/mupen64plus-video-arachnoid
* http://patch-tracker.debian.org/package/mupen64plus-video-glide64
* http://patch-tracker.debian.org/package/mupen64plus-video-rice
* http://patch-tracker.debian.org/package/mupen64plus-video-z64
The repositories with the current debian packages (and maybe more backported
patches) can be found at:
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-audio-sdl.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-core.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-input-sdl.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-rsp-hle.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-rsp-z64.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-ui-console.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-arachnoid.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-rice.git
* http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-z64.git
Of course, this is not important for your ebuild from the hg repos, but maybe
when you are packaging the next release.
Kind regards,
Sven
Jared Breland
here:
https://bugs.gentoo.org/show_bug.cgi?id=385297
It, optionally, includes the 3rd party plugins you suggested (glide64
seems to work best for me, though I have no idea how I'm supposed to
configure/tweak it like I can rice), but doesn't include any extra
patches. Well, except for "ftbfs-gvariant-type-conflicts.patch",
which seems to be security related and still applies. I figured all
of the other patches should already be included in the latest HG
version. If that's not the case, please let me know.
There's another bug report that was recently filed against the 1.5
version that does seek to include, what appears to be, all of the
patches you listed:
https://bugs.gentoo.org/show_bug.cgi?id=381655
Again, though, I'm assuming that shouldn't apply to the HG snapshot.
I'm hoping this will be used as the basis for the 2.0 ebuild once that
time comes, so I'm definitely open to any suggestions you have
regarding regarding changes or patches. I'm not the official
maintainer, though, so I can't promise anything official. :-)
--
Jared
Sven Eckelmann
> It, optionally, includes the 3rd party plugins you suggested (glide64
> seems to work best for me, though I have no idea how I'm supposed to
> configure/tweak it like I can rice), but doesn't include any extra
> patches. Well, except for "ftbfs-gvariant-type-conflicts.patch",
> which seems to be security related and still applies. I figured all
> of the other patches should already be included in the latest HG
> version. If that's not the case, please let me know.
The ftbfs patch is for 1.5 and is not related to 1.99.x + is not security
related.
> There's another bug report that was recently filed against the 1.5
> version that does seek to include, what appears to be, all of the
> patches you listed:
> https://bugs.gentoo.org/show_bug.cgi?id=381655
>
> Again, though, I'm assuming that shouldn't apply to the HG snapshot.
Correct. The patches for 1.99.x are either Debian specific or included in the
mercurial repostories (the only exception is the cheat patch... which wasn't
accepted by Richard yet).
Kind regards,
Sven
Sven Eckelmann
> here:
> https://bugs.gentoo.org/show_bug.cgi?id=385297
I looked at the ebuild and I am quite sure that the mentioned dependencies
are... weird. Can you please explain why media-libs/sdl-ttf and media-
fonts/dejavu and app-arch/xz-utils and dev-lang/yasm is needed? And also
explain why the dependencies virtual/glu and media-libs/glew is missing. The
latter one is only needed for mupen64plus-video-z64.
Why are you using sed to change the mandir instead of using the make parameter
MANDIR? What will you do when the next version is released to get the extra
plugins which aren't part of the bundle? Will you split the ebuild and use the
already splitted tarballs? Will you create a gentoo specific tarball? Will you
manually fetch the files? ...
Why don't you use the external minizip shipped by zlib? Now you just added
another regression: https://bugs.gentoo.org/383845
Kind regards,
Sven
nitro322
1. Removed old/unneeded dependencies
2. Added undocumented dependencies for plugins (if USE flag enabled)
3. Dropped sed man dir fix in favor of MANDIR build option
Thanks for the suggesitons.
nitro322
> I looked at the ebuild and I am quite sure that the mentioned dependencies
> are... weird. Can you please explain why media-libs/sdl-ttf and media-
> fonts/dejavu and app-arch/xz-utils and dev-lang/yasm is needed? And also
> explain why the dependencies virtual/glu and media-libs/glew is missing. The
> latter one is only needed for mupen64plus-video-z64.
asked about were already there, so no, I don't know why they were
added. I assumed it was for a reason and left them to be safe, but if
none of those are used any more then I can certainly remove them. As
for glu and glew, they're missing because they're not listed as
dependencies either on the CompilingFromHg wiki page or any of the
README files included with the source code.
> Why are you using sed to change the mandir instead of using the make parameter
> MANDIR?
since it's documented further down the wiki page. I built the package
using the options documented for the core, and only added/changed what
was necessary for the rest after the fact. I'll revisit this.
> What will you do when the next version is released to get the extra
> plugins which aren't part of the bundle?
some kind of master file I could pull from to fetch all of this using
portage's native mercurial support instead of rolling my own. I get
splitting the code into separate modules, but having separate top-
level repos for them seems excessive.
> Will you split the ebuild and use the
> already splitted tarballs? Will you create a gentoo specific tarball? Will you
> manually fetch the files? ...
split ebuild for this. Maybe someone else in Gentoo will. My goal,
once either a 2.0 or 1.99.5 or whatever release comes out is to switch
to downloading those tarballs from the single ebuild rather than
pulling from the repo. The only reason I didn't do that now is
because the last snapshot is almost a year old and I wanted something
more recent to play with.
> Why don't you use the external minizip shipped by zlib? Now you just added
> another regression:https://bugs.gentoo.org/383845
documented anywhere. I do, however, see zlib listed as a dependency,
which seems to compile and work fine in in the dev version. Is there
some reason I should not do this?
Sven Eckelmann
> On Oct 4, 3:59 pm, Sven Eckelmann <s...@narfation.org> wrote:
> > I looked at the ebuild and I am quite sure that the mentioned
> > dependencies are... weird. Can you please explain why
> > media-libs/sdl-ttf and media- fonts/dejavu and app-arch/xz-utils and
> > dev-lang/yasm is needed? And also explain why the dependencies
> > virtual/glu and media-libs/glew is missing. The latter one is only
> > needed for mupen64plus-video-z64.
>
> I updated the existing stable ebuild. All of the dependencies you
> asked about were already there, so no, I don't know why they were
> added. I assumed it was for a reason and left them to be safe, but if
> none of those are used any more then I can certainly remove them. As
> for glu and glew, they're missing because they're not listed as
> dependencies either on the CompilingFromHg wiki page or any of the
> README files included with the source code.
But mupen64plus 1.99.x is _not_ mupen64plus 1.5. There was a big
redesign/refactoring going on for many components and therefore the
dependencies were changed a lot.
The dependencies for all components shipped in the core bundle are mentioned
in the wiki --- but not in a Distribution specific way. So it cannot say "hey,
use xyz that is actually a part of abc for upstream but an extra package on
distribution asdf"
And glew isn't mentioned there because the helper scripts don't build
mupen64plus-video-z64.
[...]
> > What will you do when the next version is released to get the extra
> > plugins which aren't part of the bundle?
>
> Update the ebuild. It would be nice if there was a single repo or
> some kind of master file I could pull from to fetch all of this using
> portage's native mercurial support instead of rolling my own. I get
> splitting the code into separate modules, but having separate top-
> level repos for them seems excessive.
A single repo for everything seems to counterproductive. The idea was to
create a real modular "thing" that could be used for many purposes. That
includes Linux targets on PC, handhelds like Pandora, mobile phones or some
gaming consoles like xbox360. Those need different frontends and plugins. So
it is not really useful to create a big blob that includes everything
possible.
I think that Richard also said that he encourages people to develop more
things (like graphical user interfaces), but that he don't want to be
responsible for them/maintaining them. So I would doubt that you will see a
big repo containing everything again in the near future.
And why merging those things when the trend on gentoo was to split things (see
how the x11 stuff was handled during the xfree86 days or the split of KDE
packages)? Richard42 and wahrhaft already provide extra tarballs on bitbucket
for each component.
> > Will you split the ebuild and use the
> > already splitted tarballs? Will you create a gentoo specific tarball?
> > Will you manually fetch the files? ...
>
> I'm not sure what you're asking here. No, I don't plan on creating a
> split ebuild for this. Maybe someone else in Gentoo will. My goal,
> once either a 2.0 or 1.99.5 or whatever release comes out is to switch
> to downloading those tarballs from the single ebuild rather than
> pulling from the repo. The only reason I didn't do that now is
> because the last snapshot is almost a year old and I wanted something
> more recent to play with.
That is exactly what I wanted to know.
> > Why don't you use the external minizip shipped by zlib? Now you just
> > added another regression:https://bugs.gentoo.org/383845
>
> Because I don't know what minizip is, and again, I don't see it
> documented anywhere. I do, however, see zlib listed as a dependency,
> which seems to compile and work fine in in the dev version. Is there
> some reason I should not do this?
It is not documented because it is normally not needed. But gentoo decided
that it is good to change the zconf.h included in zlib and therefore break the
included minizip stuff (and many other things in other packages). The only
reasonable solution in gentoo is to ignore the included minizip stuff and use
the minizip library from gentoo (something which many other distributions
don't provide because it is something which zlib upstream never intended to
have --- and gentoo only when haven the use flag minizip and zlib >=
zlib-1.2.5.1-r2). This is not a general dependency, but something which Gentoo
introduced. You have to deal with those things as ebuild maintainer/developer
and not upstream. You can try to get the minizip library stuff from
zlib-1.2.4-minizip-autotools.patch merged in zlib upstream and mupen64plus-
core will change his default behaviour, but not the other way around.
Your ebuild just fails to build at the moment with zlib >= zlib-1.2.5.1-r1 and
the minizip parts from mupen64plus-core.
[...]
> 2. Added undocumented dependencies for plugins (if USE flag enabled)
[...]
No, virtual/glu is also needed by mupen64plus-core.
Kind regards,
Sven
Sven Eckelmann
[...]
> It is not documented because it is normally not needed. But gentoo decided
> that it is good to change the zconf.h included in zlib and therefore break
> the included minizip stuff (and many other things in other packages). The
> only reasonable solution in gentoo is to ignore the included minizip stuff
> and use the minizip library from gentoo (something which many other
> distributions don't provide because it is something which zlib upstream
> never intended to have --- and gentoo only when haven the use flag minizip
> and zlib >= zlib-1.2.5.1-r2). This is not a general dependency, but
> something which Gentoo introduced. You have to deal with those things as
> ebuild maintainer/developer and not upstream. You can try to get the
> minizip library stuff from zlib-1.2.4-minizip-autotools.patch merged in
> zlib upstream and mupen64plus- core will change his default behaviour, but
> not the other way around.
>
> Your ebuild just fails to build at the moment with zlib >= zlib-1.2.5.1-r1
> and the minizip parts from mupen64plus-core.
Forgot to say that you also have to change the dependency to:
sys-libs/zlib[minizip]
I've prepared a change that makes it compile on gentoo for now. I am not happy
that this is a gentoo specific workaround (and only when libminizip is
installed), but thats the way it works at the moment. You can find it at
https://bitbucket.org/ecsv/mupen64plus-core/changeset/2c4486980d82
(this repo will be removed when Richard merges it).
Kind regards,
Sven
nitro322
> But mupen64plus 1.99.x is _not_ mupen64plus 1.5.
> mupen64plus-video-z64.
list based on what was documented, and left the original non-obvious
dependencies in place because I prefer to err on the side of caution
when updating existing ebuilds. As for glew, I understand the helper
scripts don't build the optional plugin. But if it's not documented
somewhere as a dependency, even in a readme or release notes with the
plugin, then I have no way to know that it's supposed to be included
as such in my ebuild.
> A single repo for everything seems to counterproductive.
big blob as you suggested, just that there should be some level of
hierarchy involved so that all the bits can be pulled from one source
if desired. I think a single repo with six modules that can be pulled
down separately or together would be much more convenient, without
eliminating the benefits of the split.
It's not my intent to debate the merits of this, however. I'm sure
Richard has his reasons, and since it's his project it's his
prerogative. I only mentioned it since you asked about updating my
ebuild and it plays a complicating factor.
> And why merging those things when the trend on gentoo was to split things (see
> how the x11 stuff was handled during the xfree86 days or the split of KDE
> packages)?
packages for a single application that is functionally useless if NOT
installed together.
> Your ebuild just fails to build at the moment with zlib >= zlib-1.2.5.1-r1 and
> the minizip parts from mupen64plus-core.
this ebuild I run stable on my system, so I haven't encountered this
problem. I'm not opposed to fixing it, but I can't fix something if I
don't know there's a problem, and I didn't know there was a problem
until it was reported.
> No, virtual/glu is also needed by mupen64plus-core.
dependency? I still can't find any mention of it. In fact, after
reviewing the virtual/opengl and virtual/glu ebuilds. it appears they
both depend on the exact same packages, so having both would be
redundant, at least in Gentoo.
nitro322
> Forgot to say that you also have to change the dependency to:
> sys-libs/zlib[minizip]
have this USE flag. This should work for both stable and unstable:
|| ( <sys-libs/zlib-1.2.5.1-r1 >=sys-libs/zlib-1.2.5.1-r2[minizip] )
> I've prepared a change that makes it compile on gentoo for now. I am not happy
> that this is a gentoo specific workaround (and only when libminizip is
> installed), but thats the way it works at the moment. You can find it at
> https://bitbucket.org/ecsv/mupen64plus-core/changeset/2c4486980d82
> (this repo will be removed when Richard merges it).
report it looks like this has already been merged. That'll be a big
help, especially going forward once the new zlib hits stable.
Sven Eckelmann
> On Oct 5, 4:00 am, Sven Eckelmann <s...@narfation.org> wrote:
> > But mupen64plus 1.99.x is _not_ mupen64plus 1.5.
> > <SNIP>
> > And glew isn't mentioned there because the helper scripts don't build
> > mupen64plus-video-z64.
>
> I'm aware of this, Sven. As I stated before, I build my dependency
> list based on what was documented, and left the original non-obvious
> dependencies in place because I prefer to err on the side of caution
> when updating existing ebuilds. As for glew, I understand the helper
> scripts don't build the optional plugin. But if it's not documented
> somewhere as a dependency, even in a readme or release notes with the
> plugin, then I have no way to know that it's supposed to be included
> as such in my ebuild.
Are you sure that you are capable of handling the mercurial ebuild? Because it
is not true that you cannot know what dependencies are needed. Just look at
the Makefile and you will see the dependencies. It is not like you are
building a final version which should be polished, but a randomly chosen
development snapshot. Maybe you will see in the near future that wahrhafts
plugins aren't maintained by Richard and therefore become incompatible with
the core for some time. It happened in the past and it will probably happen in
the future.
So it is important that you can deal with such a problem. And mupen64plus has
a quite open development model. So get a fork of the repo and fix the
problems. Or ask Richard whether you can have write access to the google code
page to fix/extend the wiki pages.
> > A single repo for everything seems to counterproductive.
>
> To you, maybe. I didn't say everything should be combined into one
> big blob as you suggested, just that there should be some level of
> hierarchy involved so that all the bits can be pulled from one source
> if desired. I think a single repo with six modules that can be pulled
> down separately or together would be much more convenient, without
> eliminating the benefits of the split.
So you want nested repositories... Small hint: Just create a mercurial master
repository with subrepo and maintain it. [1]
[...]
> > And why merging those things when the trend on gentoo was to split
> > things (see how the x11 stuff was handled during the xfree86 days or
> > the split of KDE packages)?
>
> Because that's my preference. I don't want to maintain and install 11
> packages for a single application that is functionally useless if NOT
> installed together.
Thats definitely wrong. You only need one frontend, one core, one audio
plugin, one rsp plugin, one input plugin and one video plugin.
There are:
* many frontends
* 1x core (there are some forks with a different dynarec.. so actually more
than one core)
* 1x audio plugin
* 2x rsp (rsp-z64 can be build for hle video or lle video... so I could
actually say that there are three rsp plugins)
* 1x input plugin (actually, there are forks of it for different purposes)
* 4x video plugins (video-z64 can only be used together with the lle version
of rsp-z64)
So it possible that the user just builds one of each category and is done.
> > No, virtual/glu is also needed by mupen64plus-core.
>
> Can you please show me some place where glu is documented as a
> dependency? I still can't find any mention of it. In fact, after
> reviewing the virtual/opengl and virtual/glu ebuilds. it appears they
> both depend on the exact same packages, so having both would be
> redundant, at least in Gentoo.
I don't like to repeat myself. Just look at the other mails.
And regarding the dependency to virtual/glu: I don't know the policy for it,
but glu and opengl are seen by Gentoo as two separate functionalities which
are currently provided by the same packages. Just look at packages like media-
libs/glew which seems to follow my interpretation.
Kind regards,
Sven
nitro322
* Thank you for being helpful in your first couple of posts.
* I never claimed anything about maintaining mercurial. I've never
even used it before last week. As for mupen64plus (in case that was a
typo on your part), I'm not the official maintainer, as I've already
stated. I'm simply trying to provide an up-to-date ebuild to help
others.
* You seem to have a problem with the fact that I don't dig through
source code and makefiles to look for dependencies when there is
already a documented dependency list and, since what I'm testing
already works, I had no reason to dig deeper. I guess I don't work
the same as you.
* For attempting to explain myself, you question my competency.
Thanks for that.
You can reply or not, I don't really care. I'm done with this thread.
Sven Eckelmann
> OK, this has gone way downhill. To summarize:
>
> * Thank you for being helpful in your first couple of posts.
>
> * I never claimed anything about maintaining mercurial.
No, not the ebuild for mercurial, but an ebuild which fetches from the
repositories using mercurial.
> I've never
> even used it before last week. As for mupen64plus (in case that was a
> typo on your part), I'm not the official maintainer, as I've already
> stated. I'm simply trying to provide an up-to-date ebuild to help
> others.
But is it helpful to put a ebuild in the wild and then not planning to
maintain it? And an ebuild which fetches from a live source is the one which
will fail relative "often".
> * You seem to have a problem with the fact that I don't dig through
> source code and makefiles to look for dependencies when there is
> already a documented dependency list and, since what I'm testing
> already works, I had no reason to dig deeper. I guess I don't work
> the same as you.
No, I am only against the statement that it was not possible for you to know
the dependencies. And I already said that the list in the wiki is not a
complete list, but only some hints (For example it said OpenGL and not
gl+glext+glu+.. development headers+libraries) and said that you can change
that fact.
It is ok not to get things right the first time (who does?), but the statement
you gave was weird.
> * For attempting to explain myself, you question my competency.
> Thanks for that.
No, I never questioned you competency, but asked you whether you (not me,
_you_) think that you can handle it and gave you some examples what this could
mean in context of your statement. And when not, who do you think should
handle the problems?
And the rest was only examples how you can easily get involved. You've
obviously detected some problems and I gave you hints how you can fix them.
> You can reply or not, I don't really care. I'm done with this thread.
I just take it as "I am currently in a bad mood" statement.
Kind regards,
Sven