b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called

b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called

[Stas Maximov]

Description:

If parity error INPCK & !IGNPAR and parity error happens on serial port
(replugged cables on the fly, while app holds the port's descriptor),
all further read/write calls fail with EACCES.

Explanation:

fhandler_serial::tcsetattr sets Win32 DCB::fAbortOnError that means that
any error condition on the port (and parity is one of them) will abort
IO operation ReadFile/WriteFile with ERROR_OPERATION_ABORTED(995) and
all further IO operations will fail with the same error till
ClearCommError is called.

fhandler_serial::tcsetattr sets DCB::fAbortOnError, but never calls
ClearCommError to clear the error condition.

Another thing is that fhandler_serial::open does not set
DCB::fAbortOnError, so the behavior is different when you use default
settings and try to set the default settings using tcsetattr.

Solution:

1. Make fhandler_serial::open to be consistent with
fhandler_serial::tcsetattr, i.e. both of them will set
DCB::fAbortOnError.

2. Modify fhandler_serial::raw_read/raw_write that will basically use
fhandler_base::raw_read/raw_write, but in case ERROR_OPERATION_ABORTED
happens, they will proceed according to termios settings on the device.

3. Add termios as a member to fhandler_serial. Check if fhandle_union is
still fhsndle_console after that!

Question:

I am willing to fix it. Do I have to subscribe to cygwin-developers
list?

Stas.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

ld or gcc failing?

[Emmanuel STAPF]

Hi,

I have the following problem:

I compiled many C modules, and I'm using `ld' to build a '.a' library file
and it fails with the following error:
<<
rm -f Dobj3.a
ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
st254d.o tu221d.o io205d.o fi
227d.o di257d.o ar237d.o do242d.o in244d.o ra228d.o re246d.o id278d.o
ra223d.o co238d.o ch248d.o bo2
50d.o di201d.o se255d.o po252d.o un218d.o cu236d.o ha239d.o co225d.o
fi222d.o ha241d.o fi258d.o bo21
9d.o pr229d.o ci240d.o pl224d.o st206d.o pa256d.o me200d.o we207d.o we281d.o
we230d.o we232d.o h2290
d.o we210d.o we217d.o we284d.o we270d.o we211d.o we292d.o we209d.o we287d.o
we212d.o we298d.o we261d
.o we213d.o we233d.o we262d.o we299d.o we295d.o we296d.o we214d.o we273d.o
we276d.o we279d.o we274d.
o we283d.o we202d.o we234d.o we297d.o we293d.o we235d.o we288d.o we263d.o
we203d.o we259d.o we216d.o
 we294d.o we264d.o we282d.o we269d.o we220d.o we280d.o we204d.o we291d.o
we289d.o we285d.o we272d.o
we265d.o we231d.o we260d.o we277d.o we208d.o we275d.o we266d.o we267d.o
we286d.o we226d.o we268d.o w
e271d.o we215d.o
ld: Dobj3.a: reloc overflow: 0x1808d > 0xffff
Dobj3.a: final close failed: File truncated
make: *** [Dobj3.a] Error 1
>>

Then I tried to concatenate all my small C modules into one `BIG.c' file and
then compile it, it fails with:
<<
bash-2.02$ make
gcc -D_WIN32_IE=0x0400 -mno-cygwin  -DWORKBENCH -c BIG.c
//d/apps/Cygnus/cygwin-B20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/..
/../../../i586-cygwin32/
bin/as.exe: BIG.o: reloc overflow: 0x1808d > 0xffff
BIG.o: File truncated
C:\TEMP/ccAIcaaa.s: Assembler messages:
C:\TEMP/ccAIcaaa.s:142442: FATAL: Can't close BIG.o
: File truncated
make: *** [BIG.o] Error 1
>>

Here is the version I'm using:
bash-2.02$ gcc -v
Reading specs from
//d/apps/Cygnus/cygwin-B20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/sp
ecs
gcc version 2.95 19990728 (release)
bash-2.02$ ld -v
GNU ld version 2.9.4 (with BFD 2.9.4)


Do you have an idea of what could be wrong?
Thanks in advance
Regards,
Manu


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Michael K. Elwood]

> I have the following problem:
>
> I compiled many C modules, and I'm using `ld' to build a '.a' library file
> and it fails with the following error:
> <<
> rm -f Dobj3.a
> ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
etc. etc.

ar is the correct tool for creating libraries (archives). ld won't do what
you want here. Don't forget to run ranlib on your library when you are done
creating it (if you want it to be indexed.) Hope this helps.

Best regards,

MKE




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Mumit Khan]

"Michael K. Elwood" <mkelwood@qsicorp.com> writes:
> > I have the following problem:
> >
> > I compiled many C modules, and I'm using `ld' to build a '.a' library file
> > and it fails with the following error:
> > <<
> > rm -f Dobj3.a
> > ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
> etc. etc.
> 
> ar is the correct tool for creating libraries (archives). ld won't do what
> you want here. Don't forget to run ranlib on your library when you are done
> creating it (if you want it to be indexed.) Hope this helps.
> 

You missed the '-r' in Emmanuel's bug report. He's trying to build a 
relocatable output, which is quite different from an archive that ar
builds.

The problem here, and Emmanuel has already filed a bug report on this,
is that GNU as/ld on x86-win32 can only handle 16-bit relocations, and 
some machine-generated code can fail at link time thanks to that. MSVC
gets around it with some magic (I haven't looked at how the newer versions
of MSVC handle this, but presumably it's cleaner than it used to be). 
If I remember correctly, MSVC notices what needs to be relocated and 
what does not, and that's why it can handle larger number of relocs in 
a single object file.

Unless someone fixes it, it'll remain a bug.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: ld or gcc failing?

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@nanotech.wisc.EDU> wrote:

>> > ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
>> etc. etc.

MK> The problem here, and Emmanuel has already filed a bug report on this,
MK> is that GNU as/ld on x86-win32 can only handle 16-bit relocations, and

    Is reloc overflow the only problem with incremental linking? I was
unable to use it at all. Never tried for trivial example, but using it
when it is really needed, e.g. when linking megabytes of C++ code
gives nonsense. From quick look, following wrong things are being done:

      Groupping of subsections is performed. This is bad idea because
different subsections can have different attributes.

      Anything except .text,.data,.dtor,.ctor,.bss seem to be
discarded (.drectve, mainly).

      For example, look what nonsense gives linking 6 objects of total
size 300k and full of .text$ comdats for dllexported inlines and
.data$ comdats for virtual tables:
---
a.o(180k):     file format pe-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000145f8  00000000  00000000  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE, LINK_ONCE_DISCARD
  1 .data         00000a00  000145f8  00000000  000146d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA, LINK_ONCE_DISCARD
  2 .dtor         0000000c  00014ff8  00000000  000150d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  3 .ctor         00000010  00015004  00000000  000150e0  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  4 .bss          00000020  00015014  00000000  00000000  2**2
                  ALLOC
---

   So, I would like to ask is this a bug in pe/coff handling or ld
just cannot catch up with g++ ?

MK> Unless someone fixes it, it'll remain a bug.

MK> Regards,
MK> Mumit


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: ld or gcc failing?

[Mumit Khan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:
> 
>     Is reloc overflow the only problem with incremental linking? I was
> unable to use it at all. Never tried for trivial example, but using it
> when it is really needed, e.g. when linking megabytes of C++ code
> gives nonsense. From quick look, following wrong things are being done:

Paul,

Reloc overflow is a problem with all linking, but I don't know off hand
if reloc overflow is the only problem with incremental linking. I fear
there are others as well, and since incr linking is never quite as well
tested as "regular" linking, the bugs come out slowly over time.

>       Groupping of subsections is performed. This is bad idea because
> different subsections can have different attributes.
> 
>       Anything except .text,.data,.dtor,.ctor,.bss seem to be
> discarded (.drectve, mainly).

I believe this is fixed in the snapshots, but I need to make sure.

>       For example, look what nonsense gives linking 6 objects of total
> size 300k and full of .text$ comdats for dllexported inlines and
> .data$ comdats for virtual tables:

Ah, the joys of "interesting" comdat issues in the current binutils. 
There's work on going, so please have patience. I'm sure Ian is still 
chugging through the large set of patches from Donn Terry ...

>    So, I would like to ask is this a bug in pe/coff handling or ld
> just cannot catch up with g++ ?

The issue is really comdat handling more than having to catch up to
g++. Once comdats are handled correctly, g++ support will implicitly
work.

What binutils snapshot did you try these with?  

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[4]: ld or gcc failing?

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@nanotech.wisc.EDU> wrote:

[]

MK> Ah, the joys of "interesting" comdat issues in the current binutils.
MK> There's work on going, so please have patience. I'm sure Ian is still
MK> chugging through the large set of patches from Donn Terry ...

>>    So, I would like to ask is this a bug in pe/coff handling or ld
>> just cannot catch up with g++ ?

MK> The issue is really comdat handling more than having to catch up to
MK> g++. Once comdats are handled correctly, g++ support will implicitly
MK> work.

MK> What binutils snapshot did you try these with?

    Still with locally hacked versions of binutils from b20.1. Just
waiting when dll-DATA patches make their way to CVS to not reapply
them again ;-)

MK> Regards,
MK> Mumit


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[4]: ld or gcc failing?

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@nanotech.wisc.EDU> wrote:

[]

MK> Ah, the joys of "interesting" comdat issues in the current binutils.
MK> There's work on going, so please have patience. I'm sure Ian is still
MK> chugging through the large set of patches from Donn Terry ...

>>    So, I would like to ask is this a bug in pe/coff handling or ld
>> just cannot catch up with g++ ?

MK> The issue is really comdat handling more than having to catch up to
MK> g++. Once comdats are handled correctly, g++ support will implicitly
MK> work.

MK> What binutils snapshot did you try these with?

    Still with locally hacked versions of binutils from b20.1. Just
waiting when dll-DATA patches make their way to CVS to not reapply
them again ;-)

MK> Regards,
MK> Mumit


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: ld or gcc failing?

[Mumit Khan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:
> 
>     Is reloc overflow the only problem with incremental linking? I was
> unable to use it at all. Never tried for trivial example, but using it
> when it is really needed, e.g. when linking megabytes of C++ code
> gives nonsense. From quick look, following wrong things are being done:

Paul,

Reloc overflow is a problem with all linking, but I don't know off hand
if reloc overflow is the only problem with incremental linking. I fear
there are others as well, and since incr linking is never quite as well
tested as "regular" linking, the bugs come out slowly over time.

>       Groupping of subsections is performed. This is bad idea because
> different subsections can have different attributes.
> 
>       Anything except .text,.data,.dtor,.ctor,.bss seem to be
> discarded (.drectve, mainly).

I believe this is fixed in the snapshots, but I need to make sure.

>       For example, look what nonsense gives linking 6 objects of total
> size 300k and full of .text$ comdats for dllexported inlines and
> .data$ comdats for virtual tables:

Ah, the joys of "interesting" comdat issues in the current binutils. 
There's work on going, so please have patience. I'm sure Ian is still 
chugging through the large set of patches from Donn Terry ...

>    So, I would like to ask is this a bug in pe/coff handling or ld
> just cannot catch up with g++ ?

The issue is really comdat handling more than having to catch up to
g++. Once comdats are handled correctly, g++ support will implicitly
work.

What binutils snapshot did you try these with?  

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: ld or gcc failing?

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@nanotech.wisc.EDU> wrote:

>> > ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
>> etc. etc.

MK> The problem here, and Emmanuel has already filed a bug report on this,
MK> is that GNU as/ld on x86-win32 can only handle 16-bit relocations, and

    Is reloc overflow the only problem with incremental linking? I was
unable to use it at all. Never tried for trivial example, but using it
when it is really needed, e.g. when linking megabytes of C++ code
gives nonsense. From quick look, following wrong things are being done:

      Groupping of subsections is performed. This is bad idea because
different subsections can have different attributes.

      Anything except .text,.data,.dtor,.ctor,.bss seem to be
discarded (.drectve, mainly).

      For example, look what nonsense gives linking 6 objects of total
size 300k and full of .text$ comdats for dllexported inlines and
.data$ comdats for virtual tables:
---
a.o(180k):     file format pe-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000145f8  00000000  00000000  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE, LINK_ONCE_DISCARD
  1 .data         00000a00  000145f8  00000000  000146d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA, LINK_ONCE_DISCARD
  2 .dtor         0000000c  00014ff8  00000000  000150d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  3 .ctor         00000010  00015004  00000000  000150e0  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  4 .bss          00000020  00015014  00000000  00000000  2**2
                  ALLOC
---

   So, I would like to ask is this a bug in pe/coff handling or ld
just cannot catch up with g++ ?

MK> Unless someone fixes it, it'll remain a bug.

MK> Regards,
MK> Mumit


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Richard]

> You missed the '-r' in Emmanuel's bug report. He's trying to build a
> relocatable output, which is quite different from an archive that ar
> builds.

I must ask: what is relocatable output actually for (that can't be provided by
archives)?
(sorry: this is now off topic).


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Mumit Khan]

Richard <hicklinr@mcd.alcatel.be> writes:
> I must ask: what is relocatable output actually for (that can't be provided b
> y
> archives)?
> (sorry: this is now off topic).

Incremental linking allows you to "partially" linked a set of object 
modules and then use that as the source to further linking. Even though 
it may seem to the same as a static archive of object files, it is however 
quite different than archives (which is what "ar" creates).

Here's a short snippet from linker docs:

`-r'
`--relocateable'
     Generate relocatable output--i.e., generate an output file that
     can in turn serve as input to `ld'.  This is often called "partial
     linking".  As a side effect, in environments that support standard
     Unix magic numbers, this option also sets the output file's magic
     number to `OMAGIC'.  If this option is not specified, an absolute
     file is produced.  When linking C++ programs, this option *will
     not* resolve references to constructors; to do that, use `-Ur'.

Essentially -r creates an executable of sorts that contains the relocation
information so that you can use it in subsequent linking. It also does not
lay out the common symbols, and does not complain if there are undefined
symbols during this relocatable link.

More confused yet ;-?

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Richard]

> Richard <hicklinr@mcd.alcatel.be> writes:
> > I must ask: what is relocatable output actually for (that can't be provided by
> > archives)?
> > (sorry: this is now off topic).
> Essentially -r creates an executable of sorts that contains the relocation
> information so that you can use it in subsequent linking. It also does not
> lay out the common symbols, and does not complain if there are undefined
> symbols during this relocatable link.
> More confused yet ;-?

I certainly am!  What could be the purpose of this?

I'm particularly interested because I came across the 16-bit 'file truncated'
problem, and thought I'd solved it by using archives.  But then the software didn't
work: modules (it was CHILL) that were to be swapped into context were just not
there - though 'objdump' showed their entry points.  I tried this on Solaris SPARC
too (where there was no relocatable size problem) - and had the same problem.  It
was necessary to link relocatably for some reason.  I have not had the time to
learn enough about the product - or CHILL - to attempt to analyse this.  The
quickest solution for me is not to let the relocatables get too large (but too many
files and I have a line-length problem) and not to waste time wondering what is
actually going on.  It must have something to do with a CHILL peculiarity, but I
have no idea what.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: ld or gcc failing?

[Paul Sokolovsky]

Hello Richard,

Richard <hicklinr@mcd.alcatel.be> wrote:

>> Richard <hicklinr@mcd.alcatel.be> writes:
>> > I must ask: what is relocatable output actually for (that can't be provided by
>> > archives)?
[]
>> More confused yet ;-?

R> I certainly am!  What could be the purpose of this?

   Let me explain how it might be helping me. I experience real burden
*linking* large C++ dll with gnuwin32 ld. Exactly that - linking!
Whole thing (280 files/3.5m) compiles within half an hour, but linking
it, say on 24M RAM box takes more than 2 hours! The cause is that all objects
produced with g++ 2.95 includes all the inline functions and virtual
tables ever were parsed (not even referenced), in separate comdat
section for each. In result, avarage size of object is 300k (cf. 15k for
static). It's hard to blame such method - without it it's impossible to build
generally usable C++ at all. But even on 64mb it takes several minutes
to link - and that's every time something changes! Moreover, this
linking seems to be hi-order problem - adding several objects makes it
trash the swap within half-hour even on those 64m (I now have got
acess to 128m box and there, finally, I can feel comfortably, but RAM became
very expensive now).

     But if partial linking of comdats were supported, it would ease
things a lot - I could link all project in two steps (ten, if needed)
- first, say, 300 objects to 10 and than 10 to dll. If I change
one source, I have to relink only one big chunk and dll. That would be
much faster, I'm sure.




Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: ld or gcc failing?

[Paul Sokolovsky]

Hello Richard,

Richard <hicklinr@mcd.alcatel.be> wrote:

>> Richard <hicklinr@mcd.alcatel.be> writes:
>> > I must ask: what is relocatable output actually for (that can't be provided by
>> > archives)?
[]
>> More confused yet ;-?

R> I certainly am!  What could be the purpose of this?

   Let me explain how it might be helping me. I experience real burden
*linking* large C++ dll with gnuwin32 ld. Exactly that - linking!
Whole thing (280 files/3.5m) compiles within half an hour, but linking
it, say on 24M RAM box takes more than 2 hours! The cause is that all objects
produced with g++ 2.95 includes all the inline functions and virtual
tables ever were parsed (not even referenced), in separate comdat
section for each. In result, avarage size of object is 300k (cf. 15k for
static). It's hard to blame such method - without it it's impossible to build
generally usable C++ at all. But even on 64mb it takes several minutes
to link - and that's every time something changes! Moreover, this
linking seems to be hi-order problem - adding several objects makes it
trash the swap within half-hour even on those 64m (I now have got
acess to 128m box and there, finally, I can feel comfortably, but RAM became
very expensive now).

     But if partial linking of comdats were supported, it would ease
things a lot - I could link all project in two steps (ten, if needed)
- first, say, 300 objects to 10 and than 10 to dll. If I change
one source, I have to relink only one big chunk and dll. That would be
much faster, I'm sure.




Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Richard]

> Richard <hicklinr@mcd.alcatel.be> writes:
> > I must ask: what is relocatable output actually for (that can't be provided by
> > archives)?
> > (sorry: this is now off topic).
> Essentially -r creates an executable of sorts that contains the relocation
> information so that you can use it in subsequent linking. It also does not
> lay out the common symbols, and does not complain if there are undefined
> symbols during this relocatable link.
> More confused yet ;-?

I certainly am!  What could be the purpose of this?

I'm particularly interested because I came across the 16-bit 'file truncated'
problem, and thought I'd solved it by using archives.  But then the software didn't
work: modules (it was CHILL) that were to be swapped into context were just not
there - though 'objdump' showed their entry points.  I tried this on Solaris SPARC
too (where there was no relocatable size problem) - and had the same problem.  It
was necessary to link relocatably for some reason.  I have not had the time to
learn enough about the product - or CHILL - to attempt to analyse this.  The
quickest solution for me is not to let the relocatables get too large (but too many
files and I have a line-length problem) and not to waste time wondering what is
actually going on.  It must have something to do with a CHILL peculiarity, but I
have no idea what.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Mumit Khan]

Richard <hicklinr@mcd.alcatel.be> writes:
> I must ask: what is relocatable output actually for (that can't be provided b
> y
> archives)?
> (sorry: this is now off topic).

Incremental linking allows you to "partially" linked a set of object 
modules and then use that as the source to further linking. Even though 
it may seem to the same as a static archive of object files, it is however 
quite different than archives (which is what "ar" creates).

Here's a short snippet from linker docs:

`-r'
`--relocateable'
     Generate relocatable output--i.e., generate an output file that
     can in turn serve as input to `ld'.  This is often called "partial
     linking".  As a side effect, in environments that support standard
     Unix magic numbers, this option also sets the output file's magic
     number to `OMAGIC'.  If this option is not specified, an absolute
     file is produced.  When linking C++ programs, this option *will
     not* resolve references to constructors; to do that, use `-Ur'.

Essentially -r creates an executable of sorts that contains the relocation
information so that you can use it in subsequent linking. It also does not
lay out the common symbols, and does not complain if there are undefined
symbols during this relocatable link.

More confused yet ;-?

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Richard]

> You missed the '-r' in Emmanuel's bug report. He's trying to build a
> relocatable output, which is quite different from an archive that ar
> builds.

I must ask: what is relocatable output actually for (that can't be provided by
archives)?
(sorry: this is now off topic).


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Mumit Khan]

"Michael K. Elwood" <mkelwood@qsicorp.com> writes:
> > I have the following problem:
> >
> > I compiled many C modules, and I'm using `ld' to build a '.a' library file
> > and it fails with the following error:
> > <<
> > rm -f Dobj3.a
> > ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
> etc. etc.
> 
> ar is the correct tool for creating libraries (archives). ld won't do what
> you want here. Don't forget to run ranlib on your library when you are done
> creating it (if you want it to be indexed.) Hope this helps.
> 

You missed the '-r' in Emmanuel's bug report. He's trying to build a 
relocatable output, which is quite different from an archive that ar
builds.

The problem here, and Emmanuel has already filed a bug report on this,
is that GNU as/ld on x86-win32 can only handle 16-bit relocations, and 
some machine-generated code can fail at link time thanks to that. MSVC
gets around it with some magic (I haven't looked at how the newer versions
of MSVC handle this, but presumably it's cleaner than it used to be). 
If I remember correctly, MSVC notices what needs to be relocated and 
what does not, and that's why it can handle larger number of relocs in 
a single object file.

Unless someone fixes it, it'll remain a bug.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ld or gcc failing?

[Michael K. Elwood]

> I have the following problem:
>
> I compiled many C modules, and I'm using `ld' to build a '.a' library file
> and it fails with the following error:
> <<
> rm -f Dobj3.a
> ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
etc. etc.

ar is the correct tool for creating libraries (archives). ld won't do what
you want here. Don't forget to run ranlib on your library when you are done
creating it (if you want it to be indexed.) Hope this helps.

Best regards,

MKE




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

ld or gcc failing?

[Emmanuel STAPF]

Hi,

I have the following problem:

I compiled many C modules, and I'm using `ld' to build a '.a' library file
and it fails with the following error:
<<
rm -f Dobj3.a
ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
st254d.o tu221d.o io205d.o fi
227d.o di257d.o ar237d.o do242d.o in244d.o ra228d.o re246d.o id278d.o
ra223d.o co238d.o ch248d.o bo2
50d.o di201d.o se255d.o po252d.o un218d.o cu236d.o ha239d.o co225d.o
fi222d.o ha241d.o fi258d.o bo21
9d.o pr229d.o ci240d.o pl224d.o st206d.o pa256d.o me200d.o we207d.o we281d.o
we230d.o we232d.o h2290
d.o we210d.o we217d.o we284d.o we270d.o we211d.o we292d.o we209d.o we287d.o
we212d.o we298d.o we261d
.o we213d.o we233d.o we262d.o we299d.o we295d.o we296d.o we214d.o we273d.o
we276d.o we279d.o we274d.
o we283d.o we202d.o we234d.o we297d.o we293d.o we235d.o we288d.o we263d.o
we203d.o we259d.o we216d.o
 we294d.o we264d.o we282d.o we269d.o we220d.o we280d.o we204d.o we291d.o
we289d.o we285d.o we272d.o
we265d.o we231d.o we260d.o we277d.o we208d.o we275d.o we266d.o we267d.o
we286d.o we226d.o we268d.o w
e271d.o we215d.o
ld: Dobj3.a: reloc overflow: 0x1808d > 0xffff
Dobj3.a: final close failed: File truncated
make: *** [Dobj3.a] Error 1
>>

Then I tried to concatenate all my small C modules into one `BIG.c' file and
then compile it, it fails with:
<<
bash-2.02$ make
gcc -D_WIN32_IE=0x0400 -mno-cygwin  -DWORKBENCH -c BIG.c
//d/apps/Cygnus/cygwin-B20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/..
/../../../i586-cygwin32/
bin/as.exe: BIG.o: reloc overflow: 0x1808d > 0xffff
BIG.o: File truncated
C:\TEMP/ccAIcaaa.s: Assembler messages:
C:\TEMP/ccAIcaaa.s:142442: FATAL: Can't close BIG.o
: File truncated
make: *** [BIG.o] Error 1
>>

Here is the version I'm using:
bash-2.02$ gcc -v
Reading specs from
//d/apps/Cygnus/cygwin-B20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/sp
ecs
gcc version 2.95 19990728 (release)
bash-2.02$ ld -v
GNU ld version 2.9.4 (with BFD 2.9.4)


Do you have an idea of what could be wrong?
Thanks in advance
Regards,
Manu


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called

[Chris Faylor]

On Fri, Sep 24, 1999 at 11:56:52AM -0700, Stas Maximov wrote:
>Description:
>
>If parity error INPCK & !IGNPAR and parity error happens on serial port
>(replugged cables on the fly, while app holds the port's descriptor),
>all further read/write calls fail with EACCES.
>
>Explanation:
>
>fhandler_serial::tcsetattr sets Win32 DCB::fAbortOnError that means that
>any error condition on the port (and parity is one of them) will abort
>IO operation ReadFile/WriteFile with ERROR_OPERATION_ABORTED(995) and
>all further IO operations will fail with the same error till
>ClearCommError is called.
>
>fhandler_serial::tcsetattr sets DCB::fAbortOnError, but never calls
>ClearCommError to clear the error condition.
>
>Another thing is that fhandler_serial::open does not set
>DCB::fAbortOnError, so the behavior is different when you use default
>settings and try to set the default settings using tcsetattr.
>
>Solution:
>
>1. Make fhandler_serial::open to be consistent with
>fhandler_serial::tcsetattr, i.e. both of them will set
>DCB::fAbortOnError.
>
>2. Modify fhandler_serial::raw_read/raw_write that will basically use
>fhandler_base::raw_read/raw_write, but in case ERROR_OPERATION_ABORTED
>happens, they will proceed according to termios settings on the device.
>
>3. Add termios as a member to fhandler_serial. Check if fhandle_union is
>still fhsndle_console after that!
>
>Question:
>
>I am willing to fix it. Do I have to subscribe to cygwin-developers
>list?

Take a look at some recent snapshots.  The serial code is different now.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

VC++ compiled DLL don't work properly with cygnus

[pakko2]

I have one problem.
I have some C++ source that I compiled in VC++ and built DLL.
But this DLL dont work in when I include it to my cygnus project.
As i can see parameters dont deliver correctly into function.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: VC++ compiled DLL don't work properly with cygnus

[Mumit Khan]

pakko2 <pakko@inbox.ru> writes:
> I have one problem.
> I have some C++ source that I compiled in VC++ and built DLL.
> But this DLL dont work in when I include it to my cygnus project.
> As i can see parameters dont deliver correctly into function.

Unless you can come up a (hopefully simple) testcase that shows the
problem, chances of anyone looking into this is rather slim.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: VC++ compiled DLL don't work properly with cygnus

[Mumit Khan]

pakko2 <pakko@inbox.ru> writes:
> I have one problem.
> I have some C++ source that I compiled in VC++ and built DLL.
> But this DLL dont work in when I include it to my cygnus project.
> As i can see parameters dont deliver correctly into function.

Unless you can come up a (hopefully simple) testcase that shows the
problem, chances of anyone looking into this is rather slim.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

VC++ compiled DLL don't work properly with cygnus

[pakko2]

I have one problem.
I have some C++ source that I compiled in VC++ and built DLL.
But this DLL dont work in when I include it to my cygnus project.
As i can see parameters dont deliver correctly into function.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called

[Chris Faylor]

On Fri, Sep 24, 1999 at 11:56:52AM -0700, Stas Maximov wrote:
>Description:
>
>If parity error INPCK & !IGNPAR and parity error happens on serial port
>(replugged cables on the fly, while app holds the port's descriptor),
>all further read/write calls fail with EACCES.
>
>Explanation:
>
>fhandler_serial::tcsetattr sets Win32 DCB::fAbortOnError that means that
>any error condition on the port (and parity is one of them) will abort
>IO operation ReadFile/WriteFile with ERROR_OPERATION_ABORTED(995) and
>all further IO operations will fail with the same error till
>ClearCommError is called.
>
>fhandler_serial::tcsetattr sets DCB::fAbortOnError, but never calls
>ClearCommError to clear the error condition.
>
>Another thing is that fhandler_serial::open does not set
>DCB::fAbortOnError, so the behavior is different when you use default
>settings and try to set the default settings using tcsetattr.
>
>Solution:
>
>1. Make fhandler_serial::open to be consistent with
>fhandler_serial::tcsetattr, i.e. both of them will set
>DCB::fAbortOnError.
>
>2. Modify fhandler_serial::raw_read/raw_write that will basically use
>fhandler_base::raw_read/raw_write, but in case ERROR_OPERATION_ABORTED
>happens, they will proceed according to termios settings on the device.
>
>3. Add termios as a member to fhandler_serial. Check if fhandle_union is
>still fhsndle_console after that!
>
>Question:
>
>I am willing to fix it. Do I have to subscribe to cygwin-developers
>list?

Take a look at some recent snapshots.  The serial code is different now.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called

[Stas Maximov]

Description:

If parity error INPCK & !IGNPAR and parity error happens on serial port
(replugged cables on the fly, while app holds the port's descriptor),
all further read/write calls fail with EACCES.

Explanation:

fhandler_serial::tcsetattr sets Win32 DCB::fAbortOnError that means that
any error condition on the port (and parity is one of them) will abort
IO operation ReadFile/WriteFile with ERROR_OPERATION_ABORTED(995) and
all further IO operations will fail with the same error till
ClearCommError is called.

fhandler_serial::tcsetattr sets DCB::fAbortOnError, but never calls
ClearCommError to clear the error condition.

Another thing is that fhandler_serial::open does not set
DCB::fAbortOnError, so the behavior is different when you use default
settings and try to set the default settings using tcsetattr.

Solution:

1. Make fhandler_serial::open to be consistent with
fhandler_serial::tcsetattr, i.e. both of them will set
DCB::fAbortOnError.

2. Modify fhandler_serial::raw_read/raw_write that will basically use
fhandler_base::raw_read/raw_write, but in case ERROR_OPERATION_ABORTED
happens, they will proceed according to termios settings on the device.

3. Add termios as a member to fhandler_serial. Check if fhandle_union is
still fhsndle_console after that!

Question:

I am willing to fix it. Do I have to subscribe to cygwin-developers
list?

Stas.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com