problem with AS from binutils 2.21.1

29 views
Skip to first unread message

RayeR

unread,
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'.

RayeR

unread,
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?

RayeR

unread,
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?!

RayeR

unread,
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 ...

Hans-Bernhard Bröker

unread,
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
first error message you got:

e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff

The problem is that this file just has too many relocations (i.e.
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

unread,
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/

Hans-Bernhard Bröker

unread,
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
COFF, it's a general limitation of all 32-bit COFF formats.

Andris Pavenis

unread,
Dec 29, 2011, 4:43:52 PM12/29/11
to dj...@delorie.com
Well. I'm also afraid that the same limitation will "kill" DJGPP port of
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

unread,
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.

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.

Rugxulo

unread,
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

DJ Delorie

unread,
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

unread,
Dec 30, 2011, 1:37:07 PM12/30/11
to
"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?

AISI, ELF is already supported by the GNU toolchain and was implemented for
DJELF.


Rod Pemberton



Eli Zaretskii

unread,
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
>
> "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
by DJGPP work around the 64K limitation using the same technique as in
the PE format.

Rod Pemberton

unread,
Dec 31, 2011, 2:40:44 AM12/31/11
to
"Eli Zaretskii" <el...@gnu.org> wrote in message
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)
[...]"

> 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



Eli Zaretskii

unread,
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
>
> > 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

"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

unread,
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)
> [...]"

Please don't cut out the important parts when quoting me. 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..."

It would be unreasonable to think I meant "wants to port Cygwin to
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.

Please use common sense when listening to what people say. Everyone
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.

How do you NOT get "Cygwin has a fix" from "There is a way around this
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

unread,
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
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..."
>
> [...] 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".
>

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.

The "side-comment" directly clarifies what the "a way around this" means,
otherwise it wouldn't be needed, or it'd be another sentence.

> Please use common sense when listening to what people say.

Accept what others have to say. Please write what you mean.

> Everyone else interpreted my comment right.

Eli constitutes "everyone" now?

I guess it's truly time to unsubscribe. DJGPP is clearly dead.


Rod Pemberton



DJ Delorie

unread,
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

Yes.

> which is to use a coff-derived PE format,

No.

Rugxulo

unread,
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
>
> btw dsputil.o is quite large (3,4MB) file, compiling taken some
> 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?!

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

unread,
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?
>
> 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 ??
>
> 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
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

unread,
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
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

unread,
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.

Hans-Bernhard Bröker

unread,
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
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 ??

"Bloated" doesn't have anything to do with it. This is code (and
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

unread,
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

Rugxulo

unread,
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").

RayeR

unread,
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:
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;
I don't have libc sources and didn't compiled it but I use updated
version by Ozkan Sezer.

Charles Sandmann

unread,
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
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.

There are several things that are not supported, but the core
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

unread,
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
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;

Actually, that's not a definition you found. It's a declaration.

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

unread,
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.
Whatever.

RayeR

unread,
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
I don't care about it.

RayeR

unread,
Jan 8, 2012, 10:15:38 AM1/8/12
to
See post about released binutils 2.22 - this solved my relocations
issue :)
Reply all
Reply to author
Forward
0 new messages