problem with AS from binutils 2.21.1
32 views
Skip to first unread message
RayeR
Dec 25, 2011, 5:18:03 PM12/25/11
to
I'm trying to compile FFMPEG 0.9 / libavcodec under WinXP DOS box,
DJGPP 2.04 and got following error from AS that seems like some
internal error. To continue building proces I had to use AS from
mingw32 package that compiled it OK.
CC dsputil.o
e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
L:\WINXP\TEMP/ccOqvtFj.s: Assembler messages:
L:\WINXP\TEMP/ccOqvtFj.s: Fatal error: can't close dsputil.o: File
truncated
make.exe: *** [dsputil.o] Error 1
N:\x264\ffmpeg.09\LIBAVC~1>as --version
GNU assembler (GNU Binutils) 2.21.1
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
DJGPP 2.04 and got following error from AS that seems like some
internal error. To continue building proces I had to use AS from
mingw32 package that compiled it OK.
CC dsputil.o
e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
L:\WINXP\TEMP/ccOqvtFj.s: Assembler messages:
L:\WINXP\TEMP/ccOqvtFj.s: Fatal error: can't close dsputil.o: File
truncated
make.exe: *** [dsputil.o] Error 1
N:\x264\ffmpeg.09\LIBAVC~1>as --version
GNU assembler (GNU Binutils) 2.21.1
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
RayeR
Dec 25, 2011, 5:21:23 PM12/25/11
to
btw dsputil.o is quite large (3,4MB) file, compiling taken some
seconds maybe problem due to low memory?
seconds maybe problem due to low memory?
RayeR
Dec 25, 2011, 7:49:03 PM12/25/11
to
No, mingw AS cannot be used, no way.
I tried different AS from binutils packages stepping back to v2.14 but
all behaved the same.
When experimenting I found that if I compile the problem file with -O2
instead of -O3 it pass!
So now it seems that GCC 4.6.2 generates some crippled code that AS
cannot assemle?!
I tried different AS from binutils packages stepping back to v2.14 but
all behaved the same.
When experimenting I found that if I compile the problem file with -O2
instead of -O3 it pass!
So now it seems that GCC 4.6.2 generates some crippled code that AS
cannot assemle?!
RayeR
Dec 25, 2011, 9:10:41 PM12/25/11
to
The same problem was with h264.c where I had to use even -O0
I fixed it by preproc pragma - in this two files I added:
#ifdef __DJGPP__
#pragma GCC optimize ("O0")
#endif
So it finally compiled.
I also got some strange warning during linking the exe:
LD ffmpeg_g.exe
e:/djgpp/lib/libc.a(d0000.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0300_z.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0008.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0400.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0006.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(stdiohk.o): warning: definition of
`___stdio_cleanup_hook' o
verriding common
e:/djgpp/lib/libc.a(exit.o): warning: common is here
e:/djgpp/lib/libc.a(dpmi_lsl.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0202.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0203.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0204.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0205.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0201.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0304.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0200.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0303.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0600.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0300.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
Same for older libc.a ...
I fixed it by preproc pragma - in this two files I added:
#ifdef __DJGPP__
#pragma GCC optimize ("O0")
#endif
So it finally compiled.
I also got some strange warning during linking the exe:
LD ffmpeg_g.exe
e:/djgpp/lib/libc.a(d0000.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0300_z.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0008.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0400.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0006.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(stdiohk.o): warning: definition of
`___stdio_cleanup_hook' o
verriding common
e:/djgpp/lib/libc.a(exit.o): warning: common is here
e:/djgpp/lib/libc.a(dpmi_lsl.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0202.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0203.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0204.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0205.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0201.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0304.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0200.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0303.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0600.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0300.o): warning: multiple common of
`___dpmi_error'
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
Same for older libc.a ...
Hans-Bernhard Bröker
Dec 28, 2011, 3:39:23 PM12/28/11
to
On 25.12.2011 23:21, RayeR wrote:
> btw dsputil.o is quite large (3,4MB) file, compiling taken some
> seconds maybe problem due to low memory?
No. The problem is actually stated reasonably clearly right in that
> btw dsputil.o is quite large (3,4MB) file, compiling taken some
> seconds maybe problem due to low memory?
first error message you got:
e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
addresses left to be fixed up by the linker). Too many as in: more than
the object file format used by DJGPP can handle.
Bottom line: that source file is just too big.
Rugxulo
Dec 28, 2011, 9:54:56 PM12/28/11
to
Hi,
On Dec 28, 2:39 pm, Hans-Bernhard Bröker <HBBroe...@t-online.de>
wrote:
Yeah, it's well known that DJGPP's COFF is a bit limited (though
hardly anybody has ever been bothered by this so far). Presumably DJ
has too little free time, so I hardly expect him to fix it anytime
soon, though indeed he's shown some interest.
Your best bet (for now) is a workaround. ;-)
1). Split the problematic file(s) into smaller pieces (tedious, error-
prone), or ...
2). Recompile with DJELF "-B/dev/env/DJDIR/elf -static" (older GCC
4.0.0 + BinUtils 2.16 but should be "good enough")
http://na.mirror.garr.it/mirrors/djgpp/djelf/
On Dec 28, 2:39 pm, Hans-Bernhard Bröker <HBBroe...@t-online.de>
wrote:
hardly anybody has ever been bothered by this so far). Presumably DJ
has too little free time, so I hardly expect him to fix it anytime
soon, though indeed he's shown some interest.
Your best bet (for now) is a workaround. ;-)
1). Split the problematic file(s) into smaller pieces (tedious, error-
prone), or ...
2). Recompile with DJELF "-B/dev/env/DJDIR/elf -static" (older GCC
4.0.0 + BinUtils 2.16 but should be "good enough")
http://na.mirror.garr.it/mirrors/djgpp/djelf/
Hans-Bernhard Bröker
Dec 29, 2011, 11:28:01 AM12/29/11
to
On 29.12.2011 03:54, Rugxulo wrote:
> Yeah, it's well known that DJGPP's COFF is a bit limited (though
> hardly anybody has ever been bothered by this so far).
Just to be 101% clear about this: this is not a limitation of DJGPP's
> Yeah, it's well known that DJGPP's COFF is a bit limited (though
> hardly anybody has ever been bothered by this so far).
COFF, it's a general limitation of all 32-bit COFF formats.
Andris Pavenis
Dec 29, 2011, 4:43:52 PM12/29/11
to dj...@delorie.com
GCC.
It is still possible to compile GCC-4.6.2 as native compiler (with -O0,
-O1 and -O2 building GCC fails due to
the mentioned problem, with -Os it still is possible). It is rather
likely that it may not be possible any more
for GCC-4.7.0 when such will be released.
Andris
DJ Delorie
Dec 29, 2011, 3:56:06 PM12/29/11
to dj...@delorie.com
> > Just to be 101% clear about this: this is not a limitation of DJGPP's
> > COFF, it's a general limitation of all 32-bit COFF formats.
> Well. I'm also afraid that the same limitation will "kill" DJGPP port of
> GCC.
format) if someone wants to port it to djgpp...
Basically, if the number of relocs exceed 65534, 65535 is stored in
the count (or a flag is set) and the actual count is stored in a
32-bit field elsewhere.
Rugxulo
Dec 30, 2011, 12:48:53 AM12/30/11
to
Hi,
On Dec 29, 2:56 pm, DJ Delorie <d...@delorie.com> wrote:
>
> There is a way around this that Cygwin uses (PE is a coff-based
> format) if someone wants to port it to djgpp...
>
> Basically, if the number of relocs exceed 65534, 65535 is stored in
> the count (or a flag is set) and the actual count is stored in a
> 32-bit field elsewhere.
Is this what you mean? (Presumably so, but of course I haven't looked
further.)
http://sourceware.org/ml/binutils/2002-07/msg00144.html
On Dec 29, 2:56 pm, DJ Delorie <d...@delorie.com> wrote:
>
> There is a way around this that Cygwin uses (PE is a coff-based
> format) if someone wants to port it to djgpp...
>
> Basically, if the number of relocs exceed 65534, 65535 is stored in
> the count (or a flag is set) and the actual count is stored in a
> 32-bit field elsewhere.
further.)
http://sourceware.org/ml/binutils/2002-07/msg00144.html
DJ Delorie
Dec 30, 2011, 1:02:17 AM12/30/11
to 387b5be8-413c-45bc...@v14g2000yqh.googlegroups.com
That's a chunk of it, yes. The complete logic is, of course,
sprinkled liberally throughout the source tree...
Rod Pemberton
Dec 30, 2011, 1:37:07 PM12/30/11
to
"DJ Delorie" <d...@delorie.com> wrote in message
news:201112292056....@delorie.com...
AISI, ELF is already supported by the GNU toolchain and was implemented for
DJELF.
Rod Pemberton
news:201112292056....@delorie.com...
> > > Just to be 101% clear about this: this is not a limitation of DJGPP's
> > > COFF, it's a general limitation of all 32-bit COFF formats.
> > Well. I'm also afraid that the same limitation will "kill" DJGPP port of
> > GCC.
>
> There is a way around this that Cygwin uses (PE is a coff-based
> format) if someone wants to port it to djgpp...
>
Why PE? Why not ELF?
> > > COFF, it's a general limitation of all 32-bit COFF formats.
> > Well. I'm also afraid that the same limitation will "kill" DJGPP port of
> > GCC.
>
> There is a way around this that Cygwin uses (PE is a coff-based
> format) if someone wants to port it to djgpp...
>
AISI, ELF is already supported by the GNU toolchain and was implemented for
DJELF.
Rod Pemberton
Eli Zaretskii
Dec 30, 2011, 2:02:00 PM12/30/11
to dj...@delorie.com
> From: "Rod Pemberton" <do_no...@noavailemail.cmm>
> Date: Fri, 30 Dec 2011 13:37:07 -0500
by DJGPP work around the 64K limitation using the same technique as in
the PE format.
> Date: Fri, 30 Dec 2011 13:37:07 -0500
>
> "DJ Delorie" <d...@delorie.com> wrote in message
> news:201112292056....@delorie.com...
> > > > Just to be 101% clear about this: this is not a limitation of DJGPP's
> > > > COFF, it's a general limitation of all 32-bit COFF formats.
> > > Well. I'm also afraid that the same limitation will "kill" DJGPP port of
> > > GCC.
> >
> > There is a way around this that Cygwin uses (PE is a coff-based
> > format) if someone wants to port it to djgpp...
> >
>
> Why PE? Why not ELF?
DJ did not suggest to use PE in DJGPP. He suggested to make COFF used
> "DJ Delorie" <d...@delorie.com> wrote in message
> news:201112292056....@delorie.com...
> > > > Just to be 101% clear about this: this is not a limitation of DJGPP's
> > > > COFF, it's a general limitation of all 32-bit COFF formats.
> > > Well. I'm also afraid that the same limitation will "kill" DJGPP port of
> > > GCC.
> >
> > There is a way around this that Cygwin uses (PE is a coff-based
> > format) if someone wants to port it to djgpp...
> >
>
> Why PE? Why not ELF?
by DJGPP work around the 64K limitation using the same technique as in
the PE format.
Rod Pemberton
Dec 31, 2011, 2:40:44 AM12/31/11
to
"Eli Zaretskii" <el...@gnu.org> wrote in message
news:83d3b5u...@gnu.org...
> He suggested to make COFF used by DJGPP work around the
> 64K limitation using the same technique as in the PE format.
Well, I can only respond to what he actually wrote, and not what he,
nor you, thought he said. It's not logical to conclude that a fix was
present in a coff-based, PE format, used in Cygwin, given what
he wrote and the way he wrote it.
Rod Pemberton
news:83d3b5u...@gnu.org...
> > From: "Rod Pemberton" <do_no...@noavailemail.cmm>
> > Date: Fri, 30 Dec 2011 13:37:07 -0500
> > "DJ Delorie" <d...@delorie.com> wrote in message
> > news:201112292056....@delorie.com...
> > > > > Just to be 101% clear about this: this is not a limitation of
> > > > > DJGPP's COFF, it's a general limitation of all 32-bit COFF
> > > > > formats. Well. I'm also afraid that the same limitation will
> > > > > "kill" DJGPP port of GCC.
> > >
> > > There is a way around this that Cygwin uses (PE is a coff-based
> > > format) if someone wants to port it to djgpp...
> > >
> >
> > Why PE? Why not ELF?
>
> DJ did not suggest to use PE in DJGPP.
"There is a way around this that Cygwin uses (PE is a coff-based format)
[...]"
> > Date: Fri, 30 Dec 2011 13:37:07 -0500
> > "DJ Delorie" <d...@delorie.com> wrote in message
> > news:201112292056....@delorie.com...
> > > > > Just to be 101% clear about this: this is not a limitation of
> > > > > DJGPP's COFF, it's a general limitation of all 32-bit COFF
> > > > > formats. Well. I'm also afraid that the same limitation will
> > > > > "kill" DJGPP port of GCC.
> > >
> > > There is a way around this that Cygwin uses (PE is a coff-based
> > > format) if someone wants to port it to djgpp...
> > >
> >
> > Why PE? Why not ELF?
>
> DJ did not suggest to use PE in DJGPP.
"There is a way around this that Cygwin uses (PE is a coff-based format)
> He suggested to make COFF used by DJGPP work around the
> 64K limitation using the same technique as in the PE format.
nor you, thought he said. It's not logical to conclude that a fix was
present in a coff-based, PE format, used in Cygwin, given what
he wrote and the way he wrote it.
Rod Pemberton
Eli Zaretskii
Dec 31, 2011, 3:05:17 AM12/31/11
to dj...@delorie.com
> From: "Rod Pemberton" <do_no...@noavailemail.cmm>
> Date: Sat, 31 Dec 2011 02:40:44 -0500
"There is a way around this that Cygwin uses (the Cygwin work-around
is relevant to DJGPP because Cygwin uses PE, which is a COFF-based
format)."
> Date: Sat, 31 Dec 2011 02:40:44 -0500
>
> > DJ did not suggest to use PE in DJGPP.
>
> "There is a way around this that Cygwin uses (PE is a coff-based format)
> [...]"
Which I interpret as
> > DJ did not suggest to use PE in DJGPP.
>
> "There is a way around this that Cygwin uses (PE is a coff-based format)
> [...]"
"There is a way around this that Cygwin uses (the Cygwin work-around
is relevant to DJGPP because Cygwin uses PE, which is a COFF-based
format)."
DJ Delorie
Dec 31, 2011, 3:07:35 AM12/31/11
to dj...@delorie.com
> > DJ did not suggest to use PE in DJGPP.
>
> "There is a way around this that Cygwin uses (PE is a coff-based format)
> [...]"
quote was:
"There is a way around this that Cygwin uses (PE is a coff-based
format) if someone wants to port it to djgpp..."
DJGPP" so the only reasonable interpretation of what I actually said
was "if someone wants to port the way around it to DJGPP's COFF code".
The part in parens is a side-comment pointing out that Cygwin uses PE
file formats, and PE is a COFF variant, hence showing the relevence to
DJGPP's COFF limitation. It's in parens because it is *not* part of
the main sentence.
> > He suggested to make COFF used by DJGPP work around the
> > 64K limitation using the same technique as in the PE format.
>
> Well, I can only respond to what he actually wrote, and not what he,
> nor you, thought he said.
else interpreted my comment right. If you know what PE format is,
you'd not think I'd want to use it as DJGPP's file format, and if you
don't know what PE is, you should find that out before making
assumptions.
(PE is the Windows native executable format, which is a wrapper around
COFF like DJGPP is. DJGPP can't produce PE executables because then
they'd be Windows programs, not DOS programs)
> It's not logical to conclude that a fix was present in a coff-based,
> PE format, used in Cygwin, given what he wrote and the way he wrote
> it.
that Cygwin uses" ?
Also, as for your "Why not ELF?" question, the answer is: because I
said so. Using ELF will not magically fix COFF, and DJGPP will always
support COFF, even if it also supports ELF.
Rod Pemberton
Dec 31, 2011, 7:09:10 PM12/31/11
to
"DJ Delorie" <d...@delorie.com> wrote in message
news:201112310807....@delorie.com...
> > > DJ did not suggest to use PE in DJGPP.
> >
> > "There is a way around this that Cygwin uses (PE is a coff-based format)
> > [...]"
>
> Please don't cut out the important parts when quoting me.
Porting or not porting has no bearing on the availability
> >
> > "There is a way around this that Cygwin uses (PE is a coff-based format)
> > [...]"
>
> Please don't cut out the important parts when quoting me.
of a solution within the Cygwin code. It's there. So, I didn't.
> The full quote was:
>
> "There is a way around this that Cygwin uses (PE is a coff-based
> format) if someone wants to port it to djgpp..."
>
> was "if someone wants to port the way around it to DJGPP's COFF code".
>
You said the solution to the problem is to use Cygwin's solution which is to
>
use a coff-derived PE format, if someone wants to port the PE code from
Cygwin to DJGPP.
> The part in parens is a side-comment pointing out that Cygwin uses PE
> file formats, and PE is a COFF variant, hence showing the relevence to
> DJGPP's COFF limitation. It's in parens because it is *not* part of
> the main sentence.
otherwise it wouldn't be needed, or it'd be another sentence.
> Please use common sense when listening to what people say.
> Everyone else interpreted my comment right.
I guess it's truly time to unsubscribe. DJGPP is clearly dead.
Rod Pemberton
DJ Delorie
Dec 31, 2011, 7:36:37 PM12/31/11
to dj...@delorie.com
> You said the solution to the problem is to use Cygwin's solution
> which is to use a coff-derived PE format,
Rugxulo
Jan 1, 2012, 6:34:26 PM1/1/12
to
Hi,
On Dec 25 2011, 6:49 pm, RayeR <gl...@centrum.cz> wrote:
>
> e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
>
Okay, so we know that original COFF (and DJGPP) can't yet handle more
than 0xffff relocs.
Well, I grabbed your package from here (warning: 31 MB):
http://sourceforge.net/projects/ffmpeg-x264-dos/files/ffmpeg-x264-dos-26-11-2011.rar/download
I unpacked it and cross-compiled (this one file only!) atop PuppyLinux
with Ozkan's GCC 3.4.6 toolchain (as + ld 2.16.1). I didn't see any
reloc warnings, so I'm guessing it's something GCC 4.6.2 specific.
Granted, it is fairly large output, but definitely not 3.4 MB, only
800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
is more bloated than it used to be with older GCC 3.4.6 ??
-rw-r--r-- 1 root root 110618 2011-12-26 13:47 dsputil.c
-rw-r--r-- 1 root root 1484 2012-01-01 17:10 dsputil.d
-rw-r--r-- 1 root root 31890 2011-12-11 21:27 dsputil.h
-rw-r--r-- 1 root root 721274 2012-01-01 17:10 dsputil.i
-rw-r--r-- 1 root root 340295 2012-01-01 17:09 dsputil-nodebug.o
-rw-r--r-- 1 root root 853733 2012-01-01 16:57 dsputil.o
-rw-r--r-- 1 root root 56263 2011-12-11 21:27 dsputil_template.c
The "nodebug" is from "strip -d", so it still has relocs but no added
debug cruft. The .i is preprocessed ("gcc -E"), so that's basically
what we're dealing with when including all those 15+ headers
(right??). And this is indeed with -O3 (it ignored the pragma), though
I had to remove a few non-existent switches as FFMPEG apparently uses
a lot!
objdump -r dsputil.o | wc
14320 42925 501408
objdump -r dsputil-nodebug.o | wc
1266 3788 41956
Okay, so not exact by any means, but it's as close a reloc count as I
can guess (being a dummy, doh). Is there a better way without manually
reading the COFF headers?
Anyways, I don't think this helps explain much, but maybe it's a start.
On Dec 25 2011, 6:49 pm, RayeR <gl...@centrum.cz> wrote:
>
> e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
>
> btw dsputil.o is quite large (3,4MB) file, compiling taken some
> seconds maybe problem due to low memory?
>
> seconds maybe problem due to low memory?
>
> When experimenting I found that if I compile the problem file with -O2
> instead of -O3 it pass!
> So now it seems that GCC 4.6.2 generates some crippled code that AS
> cannot assemble?!
> instead of -O3 it pass!
> So now it seems that GCC 4.6.2 generates some crippled code that AS
Okay, so we know that original COFF (and DJGPP) can't yet handle more
than 0xffff relocs.
Well, I grabbed your package from here (warning: 31 MB):
http://sourceforge.net/projects/ffmpeg-x264-dos/files/ffmpeg-x264-dos-26-11-2011.rar/download
I unpacked it and cross-compiled (this one file only!) atop PuppyLinux
with Ozkan's GCC 3.4.6 toolchain (as + ld 2.16.1). I didn't see any
reloc warnings, so I'm guessing it's something GCC 4.6.2 specific.
Granted, it is fairly large output, but definitely not 3.4 MB, only
800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
is more bloated than it used to be with older GCC 3.4.6 ??
-rw-r--r-- 1 root root 110618 2011-12-26 13:47 dsputil.c
-rw-r--r-- 1 root root 1484 2012-01-01 17:10 dsputil.d
-rw-r--r-- 1 root root 31890 2011-12-11 21:27 dsputil.h
-rw-r--r-- 1 root root 721274 2012-01-01 17:10 dsputil.i
-rw-r--r-- 1 root root 340295 2012-01-01 17:09 dsputil-nodebug.o
-rw-r--r-- 1 root root 853733 2012-01-01 16:57 dsputil.o
-rw-r--r-- 1 root root 56263 2011-12-11 21:27 dsputil_template.c
The "nodebug" is from "strip -d", so it still has relocs but no added
debug cruft. The .i is preprocessed ("gcc -E"), so that's basically
what we're dealing with when including all those 15+ headers
(right??). And this is indeed with -O3 (it ignored the pragma), though
I had to remove a few non-existent switches as FFMPEG apparently uses
a lot!
objdump -r dsputil.o | wc
14320 42925 501408
objdump -r dsputil-nodebug.o | wc
1266 3788 41956
Okay, so not exact by any means, but it's as close a reloc count as I
can guess (being a dummy, doh). Is there a better way without manually
reading the COFF headers?
Anyways, I don't think this helps explain much, but maybe it's a start.
Rugxulo
Jan 1, 2012, 6:51:48 PM1/1/12
to
Hi,
On Jan 1, 5:34 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> On Dec 25 2011, 6:49 pm, RayeR <gl...@centrum.cz> wrote:
>
> > e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
>
> > btw dsputil.o is quite large (3,4MB) file, compiling taken some
> > seconds maybe problem due to low memory?
>
dsputil.o"):
-rw-r--r-- 1 root root 1782775 2012-01-01 17:48 dsputil.o
-rw-r--r-- 1 root root 367199 2012-01-01 17:49 dsputil-nodebug.o
objdump -r dsputil.o | wc
68448 205294 2326341
objdump -r dsputil-nodebug.o | wc
2034 6082 67179
strings *.o | grep -i gcc
GCC: (GNU) 4.6.2
On Jan 1, 5:34 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> On Dec 25 2011, 6:49 pm, RayeR <gl...@centrum.cz> wrote:
>
> > e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
>
> > btw dsputil.o is quite large (3,4MB) file, compiling taken some
> > seconds maybe problem due to low memory?
>
> Granted, it is fairly large output, but definitely not 3.4 MB, only
> 800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
> is more bloated than it used to be with older GCC 3.4.6 ??
>
> 800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
> is more bloated than it used to be with older GCC 3.4.6 ??
>
> objdump -r dsputil.o | wc
> 14320 42925 501408
> objdump -r dsputil-nodebug.o | wc
> 1266 3788 41956
This must be your "gcc -O2" compile, then ("ar x libavcodec.a
> 14320 42925 501408
> objdump -r dsputil-nodebug.o | wc
> 1266 3788 41956
dsputil.o"):
-rw-r--r-- 1 root root 1782775 2012-01-01 17:48 dsputil.o
-rw-r--r-- 1 root root 367199 2012-01-01 17:49 dsputil-nodebug.o
objdump -r dsputil.o | wc
68448 205294 2326341
objdump -r dsputil-nodebug.o | wc
2034 6082 67179
strings *.o | grep -i gcc
GCC: (GNU) 4.6.2
Charles Sandmann
Jan 2, 2012, 1:06:29 AM1/2/12
to
> Why not ELF? AISI, ELF is already supported by the
> GNU toolchain and was implemented for DJELF.
The djelf code is available as a user add-on. It is GPL and
> GNU toolchain and was implemented for DJELF.
can be used if desired. It is not copyright compatible with
the DJGPP project and so can't be merged into the CVS
tree without appropriate copyright assignment.
Without a rewrite or assignment it can't be used for
commercial use. Someone could ask Daniel for
permission/assignment.
Alternatively we could look at DJ's suggestion to
extend COFF as was done under the PE format.
Rugxulo
Jan 2, 2012, 4:47:55 PM1/2/12
to
Hi,
On Jan 2, 12:06 am, "Charles Sandmann" <cwsd...@earthlink.net> wrote:
>
> > Why not ELF? AISI, ELF is already supported by the
> > GNU toolchain and was implemented for DJELF.
ELF does have a lot more upstream support, but extending COFF is much
much easier (I presume).
> The djelf code is available as a user add-on. It is GPL and
> can be used if desired. It is not copyright compatible with
> the DJGPP project and so can't be merged into the CVS
> tree without appropriate copyright assignment.
I never heard that and haven't checked. Are you sure? Which parts
aren't compatible? The stub? (I don't have it installed locally [yet],
so I haven't messed with it recently.) ELF can't be too too hard as
even MOSS could handle it back in the day.
> Without a rewrite or assignment it can't be used for
> commercial use. Someone could ask Daniel for
> permission/assignment.
I know D3X was non-commercial, but if DJELF is GPL it should allow it.
Dunno about specific parts, though. Anyways, Borca hasn't been around
in ages, though a quick search shows him available in other places
(ipheth). I guess somebody "could" ask him to relicense, but I'm
highly pessimistic. :-/
Anyways, did DJELF support debugging? unexec? I know fixing GAS + LD
are the only main priorities to building GCC 4.7.0, but other stuff
probably doesn't have enough capable volunteers.
On Jan 2, 12:06 am, "Charles Sandmann" <cwsd...@earthlink.net> wrote:
>
> > Why not ELF? AISI, ELF is already supported by the
> > GNU toolchain and was implemented for DJELF.
much easier (I presume).
> The djelf code is available as a user add-on. It is GPL and
> can be used if desired. It is not copyright compatible with
> the DJGPP project and so can't be merged into the CVS
> tree without appropriate copyright assignment.
aren't compatible? The stub? (I don't have it installed locally [yet],
so I haven't messed with it recently.) ELF can't be too too hard as
even MOSS could handle it back in the day.
> Without a rewrite or assignment it can't be used for
> commercial use. Someone could ask Daniel for
> permission/assignment.
Dunno about specific parts, though. Anyways, Borca hasn't been around
in ages, though a quick search shows him available in other places
(ipheth). I guess somebody "could" ask him to relicense, but I'm
highly pessimistic. :-/
Anyways, did DJELF support debugging? unexec? I know fixing GAS + LD
are the only main priorities to building GCC 4.7.0, but other stuff
probably doesn't have enough capable volunteers.
Hans-Bernhard Bröker
Jan 2, 2012, 6:37:48 PM1/2/12
to
On 02.01.2012 00:34, Rugxulo wrote:
> I unpacked it and cross-compiled (this one file only!) atop PuppyLinux
> with Ozkan's GCC 3.4.6 toolchain (as + ld 2.16.1). I didn't see any
> reloc warnings, so I'm guessing it's something GCC 4.6.2 specific.
Not really. Comparing output from two versions of GCC that far away
> I unpacked it and cross-compiled (this one file only!) atop PuppyLinux
> with Ozkan's GCC 3.4.6 toolchain (as + ld 2.16.1). I didn't see any
> reloc warnings, so I'm guessing it's something GCC 4.6.2 specific.
from each other doesn't make terribly much sense. Flipping a single
option, or updating GCC by a single minor release could _completely_
change the output. After all if it didn't, what would be the point in
making new version of the compiler?
> Granted, it is fairly large output, but definitely not 3.4 MB, only
> 800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
> is more bloated than it used to be with older GCC 3.4.6 ??
compiler switches to build it with) that was fine-tuned to within an
inch of its life to be one thing, and one thing only: _fast_. Change a
single one of those and you'll be comparing apples with tractors.
Hans-Bernhard Bröker
Jan 2, 2012, 6:43:42 PM1/2/12
to
On 02.01.2012 00:34, Rugxulo wrote:
> objdump -r dsputil.o | wc
> 14320 42925 501408
> objdump -r dsputil-nodebug.o | wc
> 1266 3788 41956
>
> Okay, so not exact by any means, but it's as close a reloc count as I
> can guess (being a dummy, doh). Is there a better way without manually
> reading the COFF headers?
objdump -t file.o | grep -1 nreloc
> 14320 42925 501408
> objdump -r dsputil-nodebug.o | wc
> 1266 3788 41956
>
> Okay, so not exact by any means, but it's as close a reloc count as I
> can guess (being a dummy, doh). Is there a better way without manually
> reading the COFF headers?
Rugxulo
Jan 2, 2012, 7:34:19 PM1/2/12
to
Hi,
I don't think that works. That seems to list the reloc sections (sec
1..14 [nx 1], then 1 [nx 0]), not individual relocs. And BTW most of
that is clearly due to debug stuff.
objdump -t dsputil.o | grep -1o 'nreloc [0-9]\+' | awk '{ sum+= $2 }
END { print sum}'
... gives me 68409, which is close to 68448 I had earlier ("objdump -r
| wc -l").
1..14 [nx 1], then 1 [nx 0]), not individual relocs. And BTW most of
that is clearly due to debug stuff.
objdump -t dsputil.o | grep -1o 'nreloc [0-9]\+' | awk '{ sum+= $2 }
END { print sum}'
... gives me 68409, which is close to 68448 I had earlier ("objdump -r
| wc -l").
RayeR
Jan 2, 2012, 8:09:50 PM1/2/12
to
Thanks for clarification. I didn't know there's such limit in COFF. I
expected that this 32bit system hasn't much 'stupid' 16-bit
limitations to care about...
As a mistake I wrote that object file reached about 3,4MB but it
should be size of temp. asm file (L:\WINXP\TEMP/ccOqvtFj.s) which even
growed over 11MB - hard to exactly say I was observing temp directory
and afer it was done temp file disappeared.
So I could take in mind that number of relocations depens on optimize
level and gcc version. I don't want to go back to older version.
Splitting the source file is not practical. So currently I use #pragma
for opt level as quick and easy solution but as Andris said it may not
be possible in future (mentioned gcc 4.7). I don't understand djgpp/
coff internals to make a coff patch but it seems it will be necessary.
Any idea about the waring in libc:
extern unsigned short __dpmi_error;
I don't have libc sources and didn't compiled it but I use updated
version by Ozkan Sezer.
expected that this 32bit system hasn't much 'stupid' 16-bit
limitations to care about...
As a mistake I wrote that object file reached about 3,4MB but it
should be size of temp. asm file (L:\WINXP\TEMP/ccOqvtFj.s) which even
growed over 11MB - hard to exactly say I was observing temp directory
and afer it was done temp file disappeared.
So I could take in mind that number of relocations depens on optimize
level and gcc version. I don't want to go back to older version.
Splitting the source file is not practical. So currently I use #pragma
for opt level as quick and easy solution but as Andris said it may not
be possible in future (mentioned gcc 4.7). I don't understand djgpp/
coff internals to make a coff patch but it seems it will be necessary.
Any idea about the waring in libc:
e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
e:/djgpp/lib/libc.a(d0600.o): warning: multiple common of
`___dpmi_error'
I can found only definition in DPMI.H
e:/djgpp/lib/libc.a(d0600.o): warning: multiple common of
`___dpmi_error'
extern unsigned short __dpmi_error;
I don't have libc sources and didn't compiled it but I use updated
version by Ozkan Sezer.
Charles Sandmann
Jan 2, 2012, 10:06:23 PM1/2/12
to
>> The djelf code is available as a user add-on. It is GPL and
>> can be used if desired. It is not copyright compatible with
>> the DJGPP project and so can't be merged into the CVS
>> tree without appropriate copyright assignment.
>I never heard that and haven't checked. Are you sure? Which parts
>aren't compatible? The stub? (I don't have it installed locally [yet],
>so I haven't messed with it recently.) ELF can't be too too hard as
>even MOSS could handle it back in the day.
Let me be more precise. Some of the new components
>> can be used if desired. It is not copyright compatible with
>> the DJGPP project and so can't be merged into the CVS
>> tree without appropriate copyright assignment.
>I never heard that and haven't checked. Are you sure? Which parts
>aren't compatible? The stub? (I don't have it installed locally [yet],
>so I haven't messed with it recently.) ELF can't be too too hard as
>even MOSS could handle it back in the day.
have GPL copyrights. Many of the components which are
relatively minor modifications of existing files retain the current
copyrights and could be checked in. It might be possible to
support ELF linking without the full package. It might also
be possible that the GPL portions of the code are not needed
or could be segregated into packages away from libc.
>Anyways, did DJELF support debugging? unexec? I know fixing GAS + LD
>are the only main priorities to building GCC 4.7.0, but other stuff
>probably doesn't have enough capable volunteers.
pieces needed to provide support (and support further
development) are there. In particular, some of the really
hard pieces (like the ELF stub / crt0) are working and
retain the original copyrights.
I don't have a personal need for this, but it is interesting
and worth discussing.
Hans-Bernhard Bröker
Jan 3, 2012, 5:03:38 PM1/3/12
to
On 03.01.2012 02:09, RayeR wrote:
> As a mistake I wrote that object file reached about 3,4MB but it
> should be size of temp. asm file (L:\WINXP\TEMP/ccOqvtFj.s) which even
> growed over 11MB - hard to exactly say I was observing temp directory
> and afer it was done temp file disappeared.
If you want a real look, add the -save-temps flag to your compilation
> As a mistake I wrote that object file reached about 3,4MB but it
> should be size of temp. asm file (L:\WINXP\TEMP/ccOqvtFj.s) which even
> growed over 11MB - hard to exactly say I was observing temp directory
> and afer it was done temp file disappeared.
flags. That will preserve all the intermediate files, including the asm
source.
> Any idea about the waring in libc:
> e:/djgpp/lib/libc.a(d0e01.o): warning: previous common is here
> e:/djgpp/lib/libc.a(d0600.o): warning: multiple common of
> `___dpmi_error'
>
> I can found only definition in DPMI.H
> extern unsigned short __dpmi_error;
The message itself is most likely caused by the presence of the
--warn-common flag in the effective linker command line. It's
complaining about multiple not-quite-definitions which, in a C program,
would look like this:
unsigned short __dpmi_error;
In the actual DJGPP libc sources, those are assembly modules, but the
story is essentially the same. "common" definitions are considered
normal in the Unix world, including DJGPP, so it's not a terribly good
idea to activate that linker warning in code meant for a Unix platform.
That said, you can just ignore the warning.
Hans-Bernhard Bröker
Jan 3, 2012, 5:44:19 PM1/3/12
to
On 03.01.2012 01:34, Rugxulo wrote:
>>> Okay, so not exact by any means, but it's as close a reloc count as I
>>> can guess (being a dummy, doh). Is there a better way without manually
>>> reading the COFF headers?
>>
>> objdump -t file.o | grep -1 nreloc
>
> I don't think that works. That seems to list the reloc sections (sec
> 1..14 [nx 1], then 1 [nx 0]), not individual relocs.
Yet you did say you wanted a _count_ of relocs, not all individual ones.
>>> Okay, so not exact by any means, but it's as close a reloc count as I
>>> can guess (being a dummy, doh). Is there a better way without manually
>>> reading the COFF headers?
>>
>> objdump -t file.o | grep -1 nreloc
>
> I don't think that works. That seems to list the reloc sections (sec
> 1..14 [nx 1], then 1 [nx 0]), not individual relocs.
Whatever.
RayeR
Jan 3, 2012, 7:26:43 PM1/3/12
to
> In the actual DJGPP libc sources, those are assembly modules, but the
> story is essentially the same. "common" definitions are considered
> normal in the Unix world, including DJGPP, so it's not a terribly good
> idea to activate that linker warning in code meant for a Unix platform.
> That said, you can just ignore the warning.
Yes there was used -Wl,--warn-common in FFMPEG I don't know why. So OK
> story is essentially the same. "common" definitions are considered
> normal in the Unix world, including DJGPP, so it's not a terribly good
> idea to activate that linker warning in code meant for a Unix platform.
> That said, you can just ignore the warning.
I don't care about it.
RayeR
Jan 8, 2012, 10:15:38 AM1/8/12
to
See post about released binutils 2.22 - this solved my relocations
issue :)
issue :)
Reply all
Reply to author
Forward
0 new messages