Unlike bug 195411, eix will configure on ia64-hpux however you will hit errors with the first source file it tries to make. Here is the snippet: eix version 0.10.2 configured successfully. Good luck with make :) make all-recursive make[1]: Entering directory `/home/jolexa/portage/hpia64-11.23/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2' Making all in src make[2]: Entering directory `/home/jolexa/portage/hpia64-11.23/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2/src' depbase=`echo update-eix.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ ia64-hp-hpux11.23-g++ -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fomit-frame-pointer -MT update-eix.o -MD -MP -MF $depbase.Tpo -c -o update-eix.o update-eix.cc &&\ mv -f $depbase.Tpo $depbase.Po In file included from ./portage/mask_list.h:18, from ./portage/conf/cascadingprofile.h:14, from update-eix.cc:26: ./portage/package.h: In constructor 'SlotVersions::SlotVersions(const char*, Version*)': ./portage/package.h:53: error: anachronistic old-style base class initializer ./portage/package.h:53: error: unnamed initializer for 'SlotVersions', which has no base classes ./portage/package.h:54: error: expected primary-expression before 'int' ./portage/package.h:54: error: no matching function for call to 'VersionList::VersionList()' ./portage/package.h:31: note: candidates are: VersionList::VersionList(Version*) ./portage/package.h:29: note: VersionList::VersionList(const VersionList&) ./portage/package.h:54: error: expected `{' before '(' token make[2]: *** [update-eix.o] Error 1
let's see if upstream is interested in this. I don't know much from C++
Created attachment 137639 [details, diff] Replace every "m_slot" with "_slot" It looks like hp-ux has a macro "m_slot" in /usr/include/sys/sysmacros.h (or some other place). We use that name as a member variable of a class, and the initialization of said member does unfortunately invoke the macro. Please apply and test this patch, I should solve the problem for "package.h".
(In reply to comment #2) > Please apply and test this patch, I should solve the problem for "package.h". That patch fixed the package.h error, which lead me to the next one in database/package_reader.cc. Here is that snippet: eix version 0.10.2 configured successfully. Good luck with make :) make all-recursive make[1]: Entering directory `/home/jolexa/portage/hpia64-11.23/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2' Making all in src make[2]: Entering directory `/home/jolexa/portage/hpia64-11.23/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2/src' depbase=`echo database/package_reader.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ ia64-hp-hpux11.23-g++ -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fomit-frame-pointer -MT database/package_reader.o -MD -MP -MF $depbase.Tpo -c -o database/package_reader.o database/package_reader.cc &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo portage/conf/cascadingprofile.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ ia64-hp-hpux11.23-g++ -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fomit-frame-pointer -MT portage/conf/cascadingprofile.o -MD -MP -MF $depbase.Tpo -c -o portage/conf/cascadingprofile.o portage/conf/cascadingprofile.cc &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo portage/basicversion.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ ia64-hp-hpux11.23-g++ -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fomit-frame-pointer -MT portage/basicversion.o -MD -MP -MF $depbase.Tpo -c -o portage/basicversion.o portage/basicversion.cc &&\ mv -f $depbase.Tpo $depbase.Po database/package_reader.cc: In member function 'void PackageReader::skip()': database/package_reader.cc:69: error: 'fseeko' was not declared in this scope database/package_reader.cc: In member function 'bool PackageReader::next()': database/package_reader.cc:87: error: 'ftello' was not declared in this scope make[2]: *** [database/package_reader.o] Error 1
do you have man-pages for fseeko and ftello?
and if not, I guess it is important to know if you have some sort of way to get an 64-bit return and offset argument type.
(In reply to comment #4) > do you have man-pages for fseeko and ftello? Is this the information you are looking for? int fseeko(FILE *stream, off_t offset, int whence); off_t ftello(FILE *stream);
what are the include directives you need for that? (Top of the manpage)
(In reply to comment #7) > what are the include directives you need for that? (Top of the manpage) include <stdio.h> for both.
and package_reader.cc doesn't include <stdio.h>?
(In reply to comment #9) > and package_reader.cc doesn't include <stdio.h>? > package_reader.cc includes package_reader.h which includes stdio.h - that should work. I tried adding include <stdio.h> to package_reader.cc just to test and it failed with the same issue.
I already found it hard to imagine. Then I suck and have no clue what the error message means otherwise. You could try to look into /usr/include/stdio.h to see if there are guards perhaps for the definitions? Maybe some defines are enabled which disable the functions in the headers. But again, I may have it all wrong and the compiler telling something completely different.
Please try putting "#define _LARGEFILE_SOURCE 1" at the top of src/database/package_reader.cc before the includes.
(In reply to comment #12) > Please try putting "#define _LARGEFILE_SOURCE 1" at the top of > src/database/package_reader.cc before the includes. > Yes! That did it. To recap, needed the patch that you provided and the #define that you listed above. % eix --version eix 0.10.2 (gcc-4.2.2, ia64-hp-hpux11.23)
Created attachment 137702 [details, diff] Remove m_slot and patch configure.in to check for fseeko As I don't know how other systems will respond to this #define, I've created a second patch that lets autoconf do the work. This will unfortunately require the ebuild to execute `eautoreconf`.
(In reply to comment #14) > As I don't know how other systems will respond to this #define, I've created a > second patch that lets autoconf do the work. This will unfortunately require > the ebuild to execute `eautoreconf`. IMO, You could make the m_slot change global (ie. change it in the source code) I will work on a new ebuild tomorrow.
Created attachment 137815 [details, diff] patch to modify eix-0.10.2.ebuild (In reply to comment #15) > I will work on a new ebuild tomorrow. @grobian: What do you think of this patch to the eix ebuild? (You will need "eix-hpux.patch" in $FILESDIR) I have also tested the modified ebuild on x86 hardware, no issues.
patch is fine, but if upstream will (very) soon release a new version for this, I prefer to wait for it to hit the tree, such that I can be ultra lazy and just don't patch it now, and don't patch it then (because auto syncing copies over the changes made to the ebuild to the new version).
(In reply to comment #17) > patch is fine, but if upstream will (very) soon release a new version for this, > I prefer to wait for it to hit the tree, such that I can be ultra lazy and just > don't patch it now, and don't patch it then (because auto syncing copies over > the changes made to the ebuild to the new version). makes complete sense to me, I'm happy with what I have now anyways. We may not need to patch it at all in prefix-world if the changes make it to the main tree. Should genstef be CC'd on this bug? he is the proxy for eix. @Emil Beinroth: Could you please let us know your intentions? I see in the eix svn changlog that you have already made the m_slot change.
There have been no changes in our repository that would merit a new release. And we have been - and will be for some time - very busy with our day-to-day jobs, so I don't see that change. IMO, the patch should be added to the ebuild without version-bump, so the users that are not affected by this bug don't have to do a useless upgrade.
prefix only so, bleh. Will add it. Thanks
