7:32 p.m.
When I build 21.4.14 using gcc 3.3, I get the following build error:
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
unexec(): dldump(/homes/nj/colman/src/xemacs-21.4.14/src/xemacs): ld.so.1: ./temacs:
fatal: /homes/nj/colman/src/xemacs-21.4.14/src/xemacs: unknown dynamic entry: 1879048176
make[1]: *** [xemacs] Error 1
make[1]: Leaving directory `/homes/nj/colman/src/xemacs-21.4.14/src'
make: *** [src] Error 2
If I execute 'gmake' a second time, without doing anything else, it completes
building. The resultant executable seems ok.
It is not impossible that my gcc installation is screwed up but I don't think
so. So, where do I go from here?
Current Installation Info:
-------------------------
uname -a: SunOS newjersey 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4
./configure '--prefix=/homes/nj/colman'
'--site-prefixes=/homes/nj/colman' '--without-dragndrop'
'--without-cde' '--with-tooltalk' '--with-workshop'
'--without-sound' '--with-pop' '--with-widgets=athena'
'--with-dialogs=athena'
XEmacs 21.4.14 "Reasonable Discussion" configured for
`sparc-sun-solaris2.7'.
Compilation / Installation:
Source code location: /homes/nj/colman/src/xemacs-21.4.14
Installation prefix: /homes/nj/colman
Additional prefixes: /homes/nj/colman
Runtime library search path:
/usr/ccs/lib:/homes/nj/colman/lib:/usr/openwin/lib:/usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.7/3.3/../../..
Operating system description file: `s/sol2.h'
Machine description file: `m/sparc.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -fno-strict-aliasing -Wshadow -Wpointer-arith
Relocating allocator for buffers: yes
GNU version of malloc: yes
Linking with `-z nocombreloc'.
- Consider configuring with --pdump.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/openwin/include
- X Windows libraries location: /usr/openwin/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Sound:
Databases:
Compiling in support for DBM.
Compiling in support for LDAP.
Internationalization:
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for ToolTalk.
Compiling in support for Sun WorkShop.
Compiling in support for dynamic shared object modules.
--
Jake Colman -- XEmacs Tinkerer
9:28 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
When I build 21.4.14 using gcc 3.3, I get the following build error:
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
unexec(): dldump(/homes/nj/colman/src/xemacs-21.4.14/src/xemacs): ld.so.1: ./temacs:
fatal: /homes/nj/colman/src/xemacs-21.4.14/src/xemacs: unknown dynamic entry: 1879048176
make[1]: *** [xemacs] Error 1
make[1]: Leaving directory `/homes/nj/colman/src/xemacs-21.4.14/src'
make: *** [src] Error 2
If I execute 'gmake' a second time, without doing anything else, it completes
building. The resultant executable seems ok.
It is not impossible that my gcc installation is screwed up but I don't think
so. So, where do I go from here?
Aren't you trying to use binutils? From the PROBLEMS file:
*** Dumping error when using GNU binutils / GNU ld on a Sun.
Errors similar to the following:
Dumping under the name xemacs unexec():
dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
1879048176
are caused by using GNU ld. There are several workarounds available:
In XEmacs 21.2 or later, configure using the new portable dumper
(--pdump).
Alternatively, you can link using the Sun version of ld, which is
normally held in /usr/ccs/bin. This can be done by one of:
- building gcc with these configure flags:
configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as
- adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
(Note: The trailing '/' there is significant.)
- uninstalling GNU ld.
- Vin
3:27 p.m.
So how is that a second build (IOW just restarting after the build completed
with the erro) runs through to completion? And what is that I have built -
is it something good?
>>>> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> Aren't you trying to use binutils? From the PROBLEMS file:
VS> *** Dumping error when using GNU binutils / GNU ld on a Sun.
VS> Errors similar to the following:
VS> Dumping under the name xemacs unexec():
VS> dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
VS> fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
VS> 1879048176
VS> are caused by using GNU ld. There are several workarounds available:
VS> In XEmacs 21.2 or later, configure using the new portable dumper
VS> (--pdump).
VS> Alternatively, you can link using the Sun version of ld, which is
VS> normally held in /usr/ccs/bin. This can be done by one of:
VS> - building gcc with these configure flags:
VS> configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as
VS> - adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
VS> (Note: The trailing '/' there is significant.)
VS> - uninstalling GNU ld.
VS> - Vin
--
Jake Colman -- XEmacs Tinkerer
4:22 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
So how is that a second build (IOW just restarting after the build
completed
with the erro) runs through to completion? And what is that I have built -
is it something good?
I have no idea about answers to any of these questions. I have always
taken the advice not to use binutils on Solaris as gospel, so I don't
build/install/use binutils on my Solaris systems.
- Vin
6:51 p.m.
I reconfigured with "--pdump" and now I am "garbage collecting" like
crazy!
This is definitely not an improvement!
>>>> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> Jake Colman <jake.colman(a)xemacs.org> writes:
> So how is that a second build (IOW just restarting after the
build completed
> with the erro) runs through to completion? And what is that I have built -
> is it something good?
VS> I have no idea about answers to any of these questions. I have always
VS> taken the advice not to use binutils on Solaris as gospel, so I don't
VS> build/install/use binutils on my Solaris systems.
VS> - Vin
--
Jake Colman -- XEmacs Tinkerer
8:12 p.m.
I followed the suggestion of specifying the --cflags option to configure and
the link problem occurred exactly the same. The output from configure did
show that it recognised the command-line option.
>>>> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> Aren't you trying to use binutils? From the PROBLEMS file:
VS> *** Dumping error when using GNU binutils / GNU ld on a Sun.
VS> Errors similar to the following:
VS> Dumping under the name xemacs unexec():
VS> dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
VS> fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
VS> 1879048176
VS> are caused by using GNU ld. There are several workarounds available:
VS> In XEmacs 21.2 or later, configure using the new portable dumper
VS> (--pdump).
VS> Alternatively, you can link using the Sun version of ld, which is
VS> normally held in /usr/ccs/bin. This can be done by one of:
VS> - building gcc with these configure flags:
VS> configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as
VS> - adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
VS> (Note: The trailing '/' there is significant.)
VS> - uninstalling GNU ld.
VS> - Vin
--
Jake Colman -- XEmacs Tinkerer
8:57 a.m.
>>>> "Jake" == Jake Colman
<jake.colman(a)xemacs.org> writes:
Jake> I followed the suggestion of specifying the --cflags option
The suggestion was to modify CFLAGS. --cflags has different semantics,
in particular, IIRC --cflags is intended to affect only the C compiler
flags, while CFLAGS will end up in the environment and affect all
programs call by the compiler controller (GCC).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:19 p.m.
If I export CFLAGS into the environment will it be addeded to whatever
default CFLAGS value would have been used? I think that it will not. I'l
have to check what the default values are and then add the /B option to that.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "Jake" == Jake Colman
<jake.colman(a)xemacs.org> writes:
Jake> I followed the suggestion of
specifying the --cflags option
SJT> The suggestion was to modify CFLAGS. --cflags has different semantics,
SJT> in particular, IIRC --cflags is intended to affect only the C compiler
SJT> flags, while CFLAGS will end up in the environment and affect all
SJT> programs call by the compiler controller (GCC).
--
Jake Colman -- XEmacs Tinkerer
3:41 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
If I export CFLAGS into the environment will it be addeded to
whatever default CFLAGS value would have been used? I think that it
will not. I'l have to check what the default values are and then
add the /B option to that.
CFLAGS will specify completely the flags to pass to the compiler, so
you will need to add whatever the default options are to the CFLAGS
environment variable.
- Vin
4:19 p.m.
Fine. I did this and it made no difference.
export CFLAGS="-B/usr/ccs/bin/ -g -O"
./configure --prefix=/homes/nj/colman --site-prefixes=/homes/nj/colman
--without-dragndrop --without-cde --with-tooltalk --with-workshop
--without-sound --with-pop --with-widgets=athena --with-dialogs=athena
I get the same error. As a matter of fact, the configure output looked
indentical to the output from when I specified the "--cflags" option and it
still mentioned about adding "-z combreloc" option.
So is it possible to build with gcc and gnu binutils under Solaris?
If not, is there a way to reduce the amount of garbage collection when using
pdump?
>>>> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> Jake Colman <jake.colman(a)xemacs.org> writes:
> If I export CFLAGS into the environment will it be addeded to
> whatever default CFLAGS value would have been used? I think that it
> will not. I'l have to check what the default values are and then
> add the /B option to that.
VS> CFLAGS will specify completely the flags to pass to the compiler, so
VS> you will need to add whatever the default options are to the CFLAGS
VS> environment variable.
VS> - Vin
--
Jake Colman -- XEmacs Tinkerer
5:35 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
Fine. I did this and it made no difference.
export CFLAGS="-B/usr/ccs/bin/ -g -O"
./configure --prefix=/homes/nj/colman --site-prefixes=/homes/nj/colman
--without-dragndrop --without-cde --with-tooltalk --with-workshop
--without-sound --with-pop --with-widgets=athena --with-dialogs=athena
I get the same error. As a matter of fact, the configure output looked
indentical to the output from when I specified the "--cflags" option and it
still mentioned about adding "-z combreloc" option.
So is it possible to build with gcc and gnu binutils under Solaris?
Can you tell me what linker was used? That is to say, when you ran
make, what was the contents of the line that contained the pattern '-o
temacs'?
As you have probably guessed by now, I'm not an expert on using
binutils under Solaris. :-)
If not, is there a way to reduce the amount of garbage collection
when using pdump?
I don't know what is causing your garbage collection problem with
--pdump. Do you have a minimal recipe to reproduce the problem? Does
increasing your gc-cons-threshold help?
Thanks for the info,
Vin
9:28 p.m.
>>>> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> Can you tell me what linker was used? That is to say, when you ran
VS> make, what was the contents of the line that contained the pattern '-o
VS> temacs'?
VS> As you have probably guessed by now, I'm not an expert on using
VS> binutils under Solaris. :-)
Unfortunately, I don't have the time to puruse this. I switched to using
"--pdump" since that solves the link problem too.
> If not, is there a way to reduce the amount of garbage
collection
> when using pdump?
VS> I don't know what is causing your garbage collection problem with
VS> --pdump. Do you have a minimal recipe to reproduce the problem? Does
VS> increasing your gc-cons-threshold help?
Looking at it again, I don't think I have a GC problem with the pdumper. I
do think, however, that XEmacs start-up time when processing my init file is
definitely slower when using the pdumper. Would that make sense? Is it
Supposed To Be That Way?
--
Jake Colman -- XEmacs Tinkerer
2:05 a.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
>>>>> "VS" == Vin Shelton
<acs(a)xemacs.org> writes:
VS> Can you tell me what linker was used? That is to say, when you ran
VS> make, what was the contents of the line that contained the pattern '-o
VS> temacs'?
VS> As you have probably guessed by now, I'm not an expert on using
VS> binutils under Solaris. :-)
Unfortunately, I don't have the time to puruse this. I switched to
using "--pdump" since that solves the link problem too.
It might still be a good idea to follow Vin's advice and use the
native linker. (People I consider Solaris experts have always avoided
GNU binutils on Solaris.) You never know when you're going to run
into problems that could have been solved simply by choosing the right
linker.
>> If not, is there a way to reduce the amount of garbage
collection
>> when using pdump?
VS> I don't know what is causing your garbage collection problem with
VS> --pdump. Do you have a minimal recipe to reproduce the problem? Does
VS> increasing your gc-cons-threshold help?
Looking at it again, I don't think I have a GC problem with the
pdumper. I do think, however, that XEmacs start-up time when
processing my init file is definitely slower when using the pdumper.
Would that make sense? Is it Supposed To Be That Way?
Pdump startup might be somewhat slower due to the overhead of mapping
in the pdump file, but that shouldn't be noticeable and, more
importantly, it shouldn't affect processing the init file.
In short, AFAIK it's not supposed to be that way.
4:03 a.m.
>>>> "Jake" == Jake Colman
<jake.colman(a)xemacs.org> writes:
Jake> Looking at it again, I don't think I have a GC problem with
Jake> the pdumper. I do think, however, that XEmacs start-up time
Jake> when processing my init file is definitely slower when using
Jake> the pdumper. Would that make sense? Is it Supposed To Be
Jake> That Way?
No, and no.
Startup time _is_ presumably affected, but all the additional time
should be spent in initialization of the Lisp environment, ie,
_before_ init files are processed. I imagine you've thought of this,
but didn't you recently update your packages as well? Is it possible
that you're confounding increases in autoload processing or package
initialization time due to changes in the packages with slowness in
XEmacs itself?
Note that XEmacs 21.4 is probably somewhat slower than 21.1; a lot of
effort went into tuning 21.1 for performance, while 21.4 was extremely
feature-rich. However, there should not be any noticable difference
between 21.4.x, for x < 14, and 21.4.14.
Also, Motif is known to have bad performance interactions with
widgets, in the generic sense that all of tabs, progress gauges, and
dialogs have had flickering and redundant redisplay reported with
Motif. It is known to have extremely bad performance in clipboard
interaction (shouldn't affect startup, though, unless you're doing
something really fancy in init). It is known to interact badly with
standard configurations to optimize Xt Expose processing.
I'm sorry to put the burden of disentangling all that on you, but
... that's Motif AFAICT.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7892
days inactive
7895
days old
13 comments
4 participants
participants (4)
-
Hrvoje Niksic -
Jake Colman -
Stephen J. Turnbull -
Vin Shelton