Re: Emacs on AMD64
It seems that this is still a problem, at least it is for us on RHEL4 64-bit. We have partially looked into this and found that it might be able to be fixed with the newer release or maybe by doing some hacking with shtool or whatnot to add in the new architectures to it's detection. I would think that just MFC'ing the newer version into the 2-Stable would be easiest though. Could this be done? On Tue, 2006-07-18 at 13:33 -0700, Doug Summers wrote: Bill Campbell wrote: On Tue, Jul 18, 2006, Ralf S. Engelschall wrote: On Tue, Jul 18, 2006, Doug Summers wrote: I can't build emacs from any version available. It keeps complaining about the host type not being supported. I noticed that the code is fairly old - is there a newer version available? Which particular Emacs version on which AMD64-based OS have you tried? I just tried this on SuSE Linux Enterprise 9 with an Athlon 64, building emacs-21.4a-2.5.0.src.rpm. The problem appears that the configure script at line 1643 recognizes amd64*-*-*, and at line 1635 recognizes ia64*-*-* while the host system type comes up with x86_64-unknown-linux-gnu. It appears that some hacking is necessary on the configure file to get the right combination. I'm up to my a$$ in alligators now so don't have time to hack on this (and I'm a vi bigot not emacs :-). Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 The Constitution is a written instrument. As such, its meaning does not alter. That which it meant when it was adopted, it means now. -- SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org Supposedly the more recent CVS versions of Emacs fix this problem, but I haven't tested it yet. Ralph - I'll give this a try later on tonight and let you know if it works and what version. Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: a2ps fails to build on RHEL4 64-bit
On Wed, Mar 21, 2007, David M. Fetter wrote: It seems that we have found yet another package that has issues on RHEL4 64-bit. Has anybody run into this and might know how this could be fixed? Just curious before we start wasting time on looking into it ourselves. :-) Anything to save time, you know. /usr/local/bin/cc -fPIC -o a2ps main.o read.o sshread.o ssheet.o select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o version-etc.o long-options.o parsessh.o lexssh.o lexps.o sheets-map.o ../lib/.libs/liba2ps.a -lfl -lm main.o: In function `spy_user': main.c:(.text+0xda4): warning: the use of `tempnam' is dangerous, better use `mkstemp' ssheet.o: In function `free_rule': ssheet.c:(.text+0x619): undefined reference to `faced_string_free' ../lib/.libs/liba2ps.a(encoding.o): In function `font_table_free': encoding.c:(.text+0x4a6): undefined reference to `font_entry_free' collect2: ld returned 1 exit status make[2]: *** [a2ps] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 Give CURRENT's a2ps-4.13b-20070321 a try. I've tried to circumvent the problem... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: a2ps fails to build on RHEL4 64-bit
On Wed, 2007-03-21 at 20:18 +0100, Ralf S. Engelschall wrote: On Wed, Mar 21, 2007, David M. Fetter wrote: It seems that we have found yet another package that has issues on RHEL4 64-bit. Has anybody run into this and might know how this could be fixed? Just curious before we start wasting time on looking into it ourselves. :-) Anything to save time, you know. /usr/local/bin/cc -fPIC -o a2ps main.o read.o sshread.o ssheet.o select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o version-etc.o long-options.o parsessh.o lexssh.o lexps.o sheets-map.o ../lib/.libs/liba2ps.a -lfl -lm main.o: In function `spy_user': main.c:(.text+0xda4): warning: the use of `tempnam' is dangerous, better use `mkstemp' ssheet.o: In function `free_rule': ssheet.c:(.text+0x619): undefined reference to `faced_string_free' ../lib/.libs/liba2ps.a(encoding.o): In function `font_table_free': encoding.c:(.text+0x4a6): undefined reference to `font_entry_free' collect2: ld returned 1 exit status make[2]: *** [a2ps] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 Give CURRENT's a2ps-4.13b-20070321 a try. I've tried to circumvent the problem... Sweet! That fixed it. Can this be MFC'ed into the 2.20061018 release please? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
It seems that for some reason gcc is not acknowledging
our /usr/local/include directory in it's includes when building. In
fact, there is this specific bit in the spec file:
%{l_shtool} subst -v -s \
-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
gcc/configure
We happen to use /usr/local as our openpkg prefix since this is an
unused location for us across all of our systems and it is a common
place where software like this is typically found so it makes it easy
for the end users to find. In any case, we're still looking into this
but it seems that by removing this bit from the spec file, it causes
another series of dilemmas. One such dilemma is that multilib is being
enabled on RHEL4 64-bit when apparently that's not a good thing on that
particular platform. Any help with this would be great. Thanks. :-)
On Wed, 2007-02-21 at 10:19 -0800, David M. Fetter wrote:
Ya, we did just that already. We need gcc to exist in general, but a
specific group of folks want gcc with_fortran, so we need to have that
as well. Believe me, I wouldn't be spending time on it if somebody
didn't specifically request it. ;-)
On Wed, 2007-02-21 at 11:51 -0500, Doug Henry wrote:
gcc with fortran from current (4.1.2) builds for me under
debian/ubuntu. If you haven't already, I would build gcc without
fortran, and then rebuild it with fortran so it builds using the same
version of openpkg gcc and not the system compiler. I have seen cases
with several packages where the build works with the openpkg gcc and
not the system gcc. If you are already doing this, it would have to
be some sort of system header weirdness.
-good luck
On 2/20/07, David M. Fetter [EMAIL PROTECTED] wrote:
Thanks. I'll try that out.
On Tue, 2007-02-20 at 16:18 -0800, Bill Campbell wrote:
On Tue, Feb 20, 2007, David M. Fetter wrote:
Ya, I did that already. It has the same failure.
It looks like some structure is missing members.
Look at line 2440 in this file to see what structure is
referenced with the
term gfc_expr:
/usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c
Then try to figure out which header file contains the
structure and whether
you can see gfc_expr anyplace.
I frequently use the attached perl script to create a
pre-processed tmp.c
file so I can see exactly what's going on. Capture the
output of the build
so you have the compile line that failed, then replace the
first ``gcc'' or
``cc'' part with this script redirecting the output to a
file for analysis
(watch out for -o options as the preprocessed output will
end up there if
it's present).
The line with do.*csspath can be removed, and the spitshell
stuff at the
top fixed to fit your system.
...
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial
Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer
Way
FAX:(206) 232-9186 Mercer Island, WA
98040-0820; (206) 236-1676
``One of the common failings among honorable people is a
failure to
appreciate how thoroughly dishonorable some other people can
be, and how
dangerous it is to trust them.''
- Thomas Sowell
--
David M. Fetter - Portland State University - UNIX Systems
Administrator
Reality is merely an illusion, albeit a very persistent one.
~Einstein
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
On Wed, Mar 21, 2007, David M. Fetter wrote:
On Wed, 2007-03-21 at 13:25 -0700, Bill Campbell wrote:
On Wed, Mar 21, 2007, David M. Fetter wrote:
It seems that for some reason gcc is not acknowledging
our /usr/local/include directory in it's includes when building. In
fact, there is this specific bit in the spec file:
%{l_shtool} subst -v -s \
-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
gcc/configure
We happen to use /usr/local as our openpkg prefix since this is an
unused location for us across all of our systems and it is a common
place where software like this is typically found so it makes it easy
for the end users to find. In any case, we're still looking into this
but it seems that by removing this bit from the spec file, it causes
another series of dilemmas. One such dilemma is that multilib is being
enabled on RHEL4 64-bit when apparently that's not a good thing on that
particular platform. Any help with this would be great. Thanks. :-)
A symlink from a ``normal'' OpenPKG instance to /usr/local?
I often make symlinks such as %{l_prefix}/bin/perl to /usr/local/bin/perl
to deal with software that may have this hard coded.
That's not really a viable option for us now. We have been
using /usr/local as the prefix for openpkg since it has been setup here.
However, even so, should there really be prefix locations that are
essentially off limits for openpkg installations? It seems like the
option to set the prefix to /usr/local is there so it should be a usable
option. I'm thinking the problem should be fixed within gcc.
I would avoid /usr/local as a prefix, particularly since FreeBSD systems
use that extensively for anything not in the core distribution (as $DEITY
intended :-). We also have several ISP customers who, after long training
and browbeating, have learned to put their site-specific scripts under
/usr/local, not in /usr/bin or simlar travesties.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
``It is better to die on your feet than to live on your knees!''
-- Emiliano Zapata.
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: [2.20061018 stable] gcc with_fortran fails to build
On Wed, 2007-03-21 at 13:40 -0700, Bill Campbell wrote:
On Wed, Mar 21, 2007, David M. Fetter wrote:
On Wed, 2007-03-21 at 13:25 -0700, Bill Campbell wrote:
On Wed, Mar 21, 2007, David M. Fetter wrote:
It seems that for some reason gcc is not acknowledging
our /usr/local/include directory in it's includes when building. In
fact, there is this specific bit in the spec file:
%{l_shtool} subst -v -s \
-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
gcc/configure
We happen to use /usr/local as our openpkg prefix since this is an
unused location for us across all of our systems and it is a common
place where software like this is typically found so it makes it easy
for the end users to find. In any case, we're still looking into this
but it seems that by removing this bit from the spec file, it causes
another series of dilemmas. One such dilemma is that multilib is being
enabled on RHEL4 64-bit when apparently that's not a good thing on that
particular platform. Any help with this would be great. Thanks. :-)
A symlink from a ``normal'' OpenPKG instance to /usr/local?
I often make symlinks such as %{l_prefix}/bin/perl to /usr/local/bin/perl
to deal with software that may have this hard coded.
That's not really a viable option for us now. We have been
using /usr/local as the prefix for openpkg since it has been setup here.
However, even so, should there really be prefix locations that are
essentially off limits for openpkg installations? It seems like the
option to set the prefix to /usr/local is there so it should be a usable
option. I'm thinking the problem should be fixed within gcc.
I would avoid /usr/local as a prefix, particularly since FreeBSD systems
use that extensively for anything not in the core distribution (as $DEITY
intended :-). We also have several ISP customers who, after long training
and browbeating, have learned to put their site-specific scripts under
/usr/local, not in /usr/bin or simlar travesties.
I totally understand. However, environments can be and typically are
very different from one another. We don't use FreeBSD, we only use
Solaris and RHEL. We don't have people putting things in /usr/local
either. In fact, since we have now been using /usr/local for our core
software for the past couple years now, our end-users have become
accustomed to that location as to where they can find what they need.
We have also wrapped cfengine around openpkg in a very intricate manner.
Changing the /usr/local prefix for us would mean a major project for
restructuring our environment. In the end, it seems that only gcc
itself is having some oddity and that if said oddity is fixed then it no
longer becomes an issue. Ultimately, we just want to get gcc fixed and
working how we need without having to restructure our entire
environment. ;-)
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
``It is better to die on your feet than to live on your knees!''
-- Emiliano Zapata.
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: a2ps fails to build on RHEL4 64-bit
On Wed, Mar 21, 2007, David M. Fetter wrote: On Wed, 2007-03-21 at 20:18 +0100, Ralf S. Engelschall wrote: On Wed, Mar 21, 2007, David M. Fetter wrote: It seems that we have found yet another package that has issues on RHEL4 64-bit. Has anybody run into this and might know how this could be fixed? Just curious before we start wasting time on looking into it ourselves. :-) Anything to save time, you know. /usr/local/bin/cc -fPIC -o a2ps main.o read.o sshread.o ssheet.o select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o version-etc.o long-options.o parsessh.o lexssh.o lexps.o sheets-map.o ../lib/.libs/liba2ps.a -lfl -lm main.o: In function `spy_user': main.c:(.text+0xda4): warning: the use of `tempnam' is dangerous, better use `mkstemp' ssheet.o: In function `free_rule': ssheet.c:(.text+0x619): undefined reference to `faced_string_free' ../lib/.libs/liba2ps.a(encoding.o): In function `font_table_free': encoding.c:(.text+0x4a6): undefined reference to `font_entry_free' collect2: ld returned 1 exit status make[2]: *** [a2ps] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 Give CURRENT's a2ps-4.13b-20070321 a try. I've tried to circumvent the problem... Sweet! That fixed it. Can this be MFC'ed into the 2.20061018 release please? Now also MFC'd. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
