11:16 a.m.
Compiling xemacs with NMAKE.EXE -f xemacs.mak
Compiler: MS VC 6.0 Got errors from linker.
Nick.
-------------------------------------------------------------------------------
minitar.c
LIBC.lib(crt0dat.obj): error LNK2005: _exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0dat.obj): error LNK2005: __exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_a already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_a already defined in
MSVCRTD.lib(cinitexe.obj)
LINK: warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
LINK: warning LNK4098: defaultlib "LIBC" conflicts with use of other libs;
use/NODEFAULTLIB:library
c:\software\SRC\xemacs-beta\nt\..\lib-src/minitar.exe : fatal error LNK1169: one or more
multiply defined symbols found
NMAKE: fatal error U1077: 'cl' : return code '0x2'
12:36 p.m.
Nickolay,
Compiling xemacs with NMAKE.EXE -f xemacs.mak
Compiler: MS VC 6.0 Got errors from linker.
minitar.c
LIBC.lib(crt0dat.obj): error LNK2005: _exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0dat.obj): error LNK2005: __exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_a already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_a already defined in
MSVCRTD.lib(cinitexe.obj)
LINK: warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
LINK: warning LNK4098: defaultlib "LIBC" conflicts with use of other libs;
use/NODEFAULTLIB:library
c:\software\SRC\xemacs-beta\nt\..\lib-src/minitar.exe : fatal error LNK1169: one or more
multiply defined symbols found
NMAKE: fatal error U1077: 'cl' : return code '0x2'
A recent patch turned on portable dumping by default. Portable dumping
needs a different C runtime library (MSVCRT) than before, so everything
needs to be rebuilt from clean. If you have DEPEND=1 set in config.inc
this ought to happen automatically - do you have this set?
Jonathan.
12:48 p.m.
Jonathan,
thanks for your comment.
I turned pdump off and set DEPEND=1
Now it works fine.
Nick.
intro: "JH" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes:
JH> Nickolay,
> Compiling xemacs with NMAKE.EXE -f xemacs.mak Compiler: MS VC 6.0
Got
> errors from linker.
> minitar.c LIBC.lib(crt0dat.obj): error LNK2005: _exit already
defined in
> MSVCRTD.lib(MSVCRTD.dll) LIBC.lib(crt0dat.obj): error LNK2005: __exit
> already defined in MSVCRTD.lib(MSVCRTD.dll) LIBC.lib(crt0init.obj): error
> LNK2005: ___xc_z already defined in MSVCRTD.lib(cinitexe.obj)
> LIBC.lib(crt0init.obj): error LNK2005: ___xc_a already defined in
> MSVCRTD.lib(cinitexe.obj) LIBC.lib(crt0init.obj): error LNK2005: ___xi_z
> already defined in MSVCRTD.lib(cinitexe.obj) LIBC.lib(crt0init.obj): error
> LNK2005: ___xi_a already defined in MSVCRTD.lib(cinitexe.obj) LINK:
> warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
> use /NODEFAULTLIB:library LINK: warning LNK4098: defaultlib "LIBC"
> conflicts with use of other libs; use/NODEFAULTLIB:library
> c:\software\SRC\xemacs-beta\nt\..\lib-src/minitar.exe : fatal error
> LNK1169: one or more multiply defined symbols found NMAKE: fatal error
> U1077: 'cl' : return code '0x2'
JH> A recent patch turned on portable dumping by default. Portable dumping
JH> needs a different C runtime library (MSVCRT) than before, so everything
JH> needs to be rebuilt from clean. If you have DEPEND=1 set in config.inc
JH> this ought to happen automatically - do you have this set?
JH> Jonathan.
1:01 p.m.
Nickolay,
I turned pdump off and set DEPEND=1
Now it works fine.
I would recommend not turning portable dumping off since it is now the
default option for UNIX and Win32, and there's no reason not to use it.
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com
1:25 p.m.
New subject: Have problems with pdump
When compiling with pdump I had several troubles. I have reported them one
day but there was no constructiv reply. Now portable dumper adds one more
problem with minitar.exe
I turned pdump on and minitar stopped linking.
-------------------------------------------------------------------------------
minitar.c
LIBC.lib(crt0dat.obj): error LNK2005: _exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0dat.obj): error LNK2005: __exit already defined in MSVCRTD.lib(MSVCRTD.dll)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xc_a already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_z already defined in
MSVCRTD.lib(cinitexe.obj)
LIBC.lib(crt0init.obj): error LNK2005: ___xi_a already defined in
MSVCRTD.lib(cinitexe.obj)
LINK: warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
LINK: warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use
/NODEFAULTLIB:library
c:\software\SRC\xemacs-beta\nt\..\lib-src/minitar.exe : fatal error LNK1169: one or more
multiply defined symbols found
NMAKE: fatal error U1077: 'cl' : return code '0x2'
Stop.
-------------------------------------------------------------------------------
In order to compile XEmacs I disabled building minitar.exe. XEmacs failed to
build. The log:
-------------------------------------------------------------------------------
rc -Foc:\software\SRC\xemacs-beta\nt\obj\xemacs.res xemacs.rc
bscmake -nologo -oc:\software\SRC\xemacs-beta\nt\..\src\temacs.bsc ＠c:\s
oftware\SRC\xemacs-beta\nt\obj\bscmake.tmp
del c:\software\SRC\xemacs-beta\nt\obj\bscmake.tmp
nmake -nologo -f xemacs.mak OUTDIR=c:\software\SRC\xemacs-beta\nt\obj c:
\software\SRC\xemacs-beta\nt\obj\dump-id.obj
WARNING: Compiling without dependency information.
Creating c:\software\SRC\xemacs-beta\nt\..\lib-src\config.values
cd c:\software\SRC\xemacs-beta\nt\..\src
c:\software\SRC\xemacs-beta\nt\..\lib-src\make-dump-id.exe
cd c:\software\SRC\xemacs-beta\nt
dump-id.c
link.exe ＠.\nmb01768.
Xpm.lib(parse.obj): error LNK2001: unresolved external symbol __pctype
Xpm.lib(data.obj): error LNK2001: unresolved external symbol __pctype
Xpm.lib(parse.obj): error LNK2001: unresolved external symbol ___mb_cur_max
Xpm.lib(data.obj): error LNK2001: unresolved external symbol ___mb_cur_max
c:\software\SRC\xemacs-beta\nt\..\src\temacs.exe : fatal error LNK1120: 2 unreso
lved externals
NMAKE: fatal error U1077: 'link.exe' : return code '0x460'
Stop.
-------------------------------------------------------------------------------
intro: "JH" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes:
JH> Nickolay,
> I turned pdump off and set DEPEND=1 Now it works fine.
JH> I would recommend not turning portable dumping off since it is now the
JH> default option for UNIX and Win32, and there's no reason not to use it.
JH> Jonathan.
JH> -- Jonathan Harris | jhar(a)tardis.ed.ac.uk London, England |
JH> Jonathan.Harris(a)symbian.com
12:31 a.m.
On Mon, 22 Apr 2002, Jonathan Harris moaned:
I would recommend not turning portable dumping off since it is now
the
default option for UNIX and Win32, and there's no reason not to use
it.
... except for a couple of megs of extra memory consumption per XEmacs
process after the first (as the pdumped stuff, last I checked, got
modified after being loaded, which is not --- cannot be --- the case for
the dumped stuff).
It's true that a couple of pettifogging megabytes is pretty unimportant
given the memory consumption of XEmacs these days, but still...
--
`Unless they've moved it since I last checked, travelling between
England and America does not involve crossing the equator.'
--- pir
1:18 a.m.
Nix wrote:
On Mon, 22 Apr 2002, Jonathan Harris moaned:
I resemble that remark!
>I would recommend not turning portable dumping off since it is now
the
>default option for UNIX and Win32, and there's no reason not to use
>it.
... except for a couple of megs of extra memory consumption per XEmacs
process after the first (as the pdumped stuff, last I checked, got
modified after being loaded, which is not --- cannot be --- the case for
the dumped stuff).
It's true that a couple of pettifogging megabytes is pretty unimportant
given the memory consumption of XEmacs these days, but still...
True - on Win32 none of the pdumped stuff is shared between processes. I
can see that this might be a more serious issue on multiuser UNIX boxes.
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com
8:15 a.m.
On Tue, 23 Apr 2002, Jonathan Harris spake:
Nix wrote:
> On Mon, 22 Apr 2002, Jonathan Harris moaned:
I resemble that remark!
(I really should revise my autoattributor to stop it being automatically
insulting to people. :) )
True - on Win32 none of the pdumped stuff is shared between
processes. I can see that this might be a more serious issue on
multiuser UNIX boxes.
It was the original raison d'etre of dumping. But these days it's
questionable how much it's worth it; the average XEmacs memory hit is
probably far above the couple of megabytes saved by dumping, so the only
remaining advantage of dumping is saving startup time.
--
`Unless they've moved it since I last checked, travelling between
England and America does not involve crossing the equator.'
--- pir
10:39 a.m.
>>>> "nix" == nix
<nix(a)esperi.demon.co.uk> writes:
nix> (I really should revise my autoattributor to stop it being
nix> automatically insulting to people. :) )
Better yet, add enough intelligence to make the insults accurate. :)
nix> It was the original raison d'etre of dumping. But these days
nix> it's questionable how much it's worth it; the average XEmacs
nix> memory hit is probably far above the couple of megabytes
nix> saved by dumping, so the only remaining advantage of dumping
nix> is saving startup time.
The key word is "multiuser." Many people even run multiple sessions
because Gnus (in particular) is such a pig as long as XEmacs isn't
multithreaded. Also, you might be surprised by how much junk is
getting pulled in by autoloads just starting up; there might be a lot
more stuff that justifies being dumped.
But you're right that it's questionable whether it's worth developer
time at this point.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8:28 p.m.
On 23 Apr 2002, Stephen J. Turnbull mused:
Also, you might be surprised by how much junk is
getting pulled in by autoloads just starting up; there might be a lot
more stuff that justifies being dumped.
I've tried to do that myself, but I eventually gave up for most packages
because it's so fiddly to ensure that a dumped package is still working
properly:( `time', `uniquify' and `advice' are examples (although I
can't remember the specifics of the failure modes: things like
destructive mods of things that were initialized in defvars later
failing... I can check them if you like.)
But you're right that it's questionable whether it's
worth developer
time at this point.
I'm hoping against hope that the cons cells can be shrunk again:
XEmacs's memory use shot up by 10Mb on the average when they grew.
--
`Unless they've moved it since I last checked, travelling between
England and America does not involve crossing the equator.'
--- pir
8041
days inactive
8042
days old
9 comments
4 participants
participants (4)
-
Jonathan Harris -
Nickolay Pakoulin -
Nix -
Stephen J. Turnbull