On 03/05/2013 12:42 AM, marco atzeri wrote:
On 3/4/2013 11:32 PM, Andrew Dunstan wrote:
Incidentally, there is no need to change the test schedules, and such a
patch would not be accepted. There is an option to restrict the number
of concurrent connections the regression tests will run (d
On 3/4/2013 11:32 PM, Andrew Dunstan wrote:
Incidentally, there is no need to change the test schedules, and such a
patch would not be accepted. There is an option to restrict the number
of concurrent connections the regression tests will run (designed
specifically with Cygwin in mind, in f
On 03/04/2013 04:30 PM, marco atzeri wrote:
On 3/4/2013 9:00 PM, Andrew Dunstan wrote:
I have not heard a word on this in the 5 weeks or so since it was sent.
Are you guys interested in fixing this or not?
yes Andrew,
I am working on it, unfortunately this Makefile spaghetti
is not nice to h
On 03/04/2013 04:30 PM, marco atzeri wrote:
On 3/4/2013 9:00 PM, Andrew Dunstan wrote:
I have not heard a word on this in the 5 weeks or so since it was sent.
Are you guys interested in fixing this or not?
yes Andrew,
I am working on it, unfortunately this Makefile spaghetti
is not nice to h
On 3/4/2013 9:00 PM, Andrew Dunstan wrote:
I have not heard a word on this in the 5 weeks or so since it was sent.
Are you guys interested in fixing this or not?
yes Andrew,
I am working on it, unfortunately this Makefile spaghetti
is not nice to handle
probably 90% is working now, but I just
On 01/30/2013 11:46 AM, Andrew Dunstan wrote:
On 01/29/2013 05:30 PM, Reini Urban wrote:
On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote:
On 1/26/2013 7:32 AM, Reini Urban wrote:
rebase is not to blame. I agree ;-)
Someone else is incorrectly managing the reloc table,
and also objcopy s
On 1/30/2013 5:46 PM, Andrew Dunstan wrote:
Autoconf+Automake will be a much cleaner approach, and will
allow to avoid at all the platform checks.
Yes, I had the same impression but it is unfortunately not realistic.
I worked against dllwrap removal but got stuck somewhere.
When I find my old
On 01/29/2013 05:30 PM, Reini Urban wrote:
On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote:
On 1/26/2013 7:32 AM, Reini Urban wrote:
rebase is not to blame. I agree ;-)
Someone else is incorrectly managing the reloc table,
and also objcopy seems innocent ...
Postgresql dll's are built in
On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote:
> On 1/26/2013 7:32 AM, Reini Urban wrote:
>>> rebase is not to blame. I agree ;-)
>>> Someone else is incorrectly managing the reloc table,
>>> and also objcopy seems innocent ...
>>>
>>> Postgresql dll's are built in this way:
>>
>>
>> My stro
On 1/26/2013 7:32 AM, Reini Urban wrote:
rebase is not to blame. I agree ;-)
Someone else is incorrectly managing the reloc table,
and also objcopy seems innocent ...
Postgresql dll's are built in this way:
My strong guess is dllwrap.
No other packages uses the ancient dllwrap anymore.
I tri
On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote:
> On 1/25/2013 4:00 PM, Corinna Vinschen wrote:
>>
>> On Jan 25 14:19, Kai Tietz wrote:
>>>
>>> 2013/1/25 marco atzeri :
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
> I already explained why: The SEGV happens during relocat
On 1/25/2013 4:00 PM, Corinna Vinschen wrote:
On Jan 25 14:19, Kai Tietz wrote:
2013/1/25 marco atzeri :
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call the
same rebase, it will
On Jan 25 14:19, Kai Tietz wrote:
> 2013/1/25 marco atzeri :
> > On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
> >
> >> I already explained why: The SEGV happens during relocation.
> >> The file header has been changed already. If you call the
> >> same rebase, it will try to rebase the file to
Well, here are my 2-cents about that issue. In general it is a flaw
to have an base-relocation in debug-section, as this means such debug
information can't be moved into a separate debug-file anymore. A
debug-file has no relocation-information.
Nevertheless it would be good, if objcopy gets adjus
2013/1/25 marco atzeri :
> On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
>
>> I already explained why: The SEGV happens during relocation.
>> The file header has been changed already. If you call the
>> same rebase, it will try to rebase the file to the same new
>> address. If current file base
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call the
same rebase, it will try to rebase the file to the same new
address. If current file base address == requested file base
addres
On 1/24/2013 4:56 PM, Christopher Faylor wrote:
On Thu, Jan 24, 2013 at 10:49:35AM +0100, marco atzeri wrote:
The attached patch solves the issue of the short ".gnu_deb"
on binutils cvs
--- src/binutils/objcopy.c 2013-01-07 18:40:59.0 +0100
+++ src_new/binutils/objcopy.c 2013-01-1
On Thu, Jan 24, 2013 at 10:49:35AM +0100, marco atzeri wrote:
>The attached patch solves the issue of the short ".gnu_deb"
>on binutils cvs
>
>--- src/binutils/objcopy.c 2013-01-07 18:40:59.0 +0100
>+++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100
>@@ -3453,6 +3453,7
On Jan 24 13:34, marco atzeri wrote:
> On 1/24/2013 1:08 PM, Corinna Vinschen wrote:
>
> >>I was not clear.
> >>Also rebasing with a different address make no difference
> >
> >It does for me:
> >
> > $ rebase -b 0x4000 dict_snowball.dll
> > Segmentation fault
> > $ rebase -b 0x5000
On 1/24/2013 1:08 PM, Corinna Vinschen wrote:
I was not clear.
Also rebasing with a different address make no difference
It does for me:
$ rebase -b 0x4000 dict_snowball.dll
Segmentation fault
$ rebase -b 0x5000 dict_snowball.dll
Segmentation fault
$ rebase -b 0x400
On Jan 24 11:16, marco atzeri wrote:
> On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
> >On Jan 24 10:49, marco atzeri wrote:
> >>Please note that rebase segfaults on dict_snowball.dll the first time
> >>but any subsequent rebasing, also with different start address,
> >>works without any problem,
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
On Jan 24 10:49, marco atzeri wrote:
On 1/24/2013 10:27 AM, Corinna Vinschen wrote:
On Jan 24 03:01, Yaakov wrote:
On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote:
On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
On Jan 16 08:15, marco atzer
On Jan 24 10:49, marco atzeri wrote:
> On 1/24/2013 10:27 AM, Corinna Vinschen wrote:
> >On Jan 24 03:01, Yaakov wrote:
> >>On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote:
> >>>On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
> On Jan 16 08:15, marco atzeri wrote:
> >On 1/15/2013 11:03
On 1/24/2013 10:27 AM, Corinna Vinschen wrote:
On Jan 24 03:01, Yaakov wrote:
On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote:
On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
On Jan 16 08:15, marco atzeri wrote:
On 1/15/2013 11:03 PM, marco atzeri wrote:
On 1/15/2013 12:24 PM, Corinna V
On Jan 24 03:01, Yaakov wrote:
> On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote:
> > On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
> > > On Jan 16 08:15, marco atzeri wrote:
> > >> On 1/15/2013 11:03 PM, marco atzeri wrote:
> > >>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
> > > This i
On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote:
> On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
> > On Jan 16 08:15, marco atzeri wrote:
> >> On 1/15/2013 11:03 PM, marco atzeri wrote:
> >>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
> > This is a serious bug in objcopy in the current b
On Jan 19 09:56, marco atzeri wrote:
> On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
>
> >This is a serious bug in objcopy in the current binutils. Given that
> >cygport creates the debug info automatically, we might end up with
> >spuriously broken DLLs in the distro.
> >
> >I checked with objco
On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
This is a serious bug in objcopy in the current binutils. Given that
cygport creates the debug info automatically, we might end up with
spuriously broken DLLs in the distro.
I checked with objcopy from the older binutils 2.51.53-2, and the
problem
On Fri, Jan 18, 2013 at 04:34:25PM +0100, marco atzeri wrote:
>On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
>>
>> As far as I can tell it's an objcopy bug.
>>
>> The stripped version of the DLL has a normal relocation information
>> which at one point ends in a NULL IMAGE_BASE_RELOCATION record, a
On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
As far as I can tell it's an objcopy bug.
The stripped version of the DLL has a normal relocation information
which at one point ends in a NULL IMAGE_BASE_RELOCATION record, as
expected. After calling `objcopy --add-gnu-debuglink', the relocation
i
On Jan 16 16:12, marco atzeri wrote:
> On 1/16/2013 3:42 PM, Corinna Vinschen wrote:
>
> >
> >I forgot to mention, the --long-section-names enable option was
> >never default, apparently. This would have to be fixed in cygport,
> >I guess.
>
> The default seems to keep previous value, but
> as "
On 1/16/2013 3:42 PM, Corinna Vinschen wrote:
I forgot to mention, the --long-section-names enable option was
never default, apparently. This would have to be fixed in cygport,
I guess.
The default seems to keep previous value, but
as ".gnu_debuglink" is a long name at list in that
case shou
On Jan 16 14:38, marco atzeri wrote:
> On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
> >On Jan 16 08:15, marco atzeri wrote:
> >>On 1/15/2013 11:03 PM, marco atzeri wrote:
> >>>On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
> On Jan 15 11:36, marco atzeri wrote:
> >On 1/15/2013 11:07 AM, Co
On 1/16/2013 1:35 PM, Corinna Vinschen wrote:
On Jan 16 08:15, marco atzeri wrote:
On 1/15/2013 11:03 PM, marco atzeri wrote:
On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
On Jan 15 11:36, marco atzeri wrote:
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
This is a serious bug in objcopy
as soon as one
> >>>>entry translates into a memory address which is beyond the committed
> >>>>area of the file memory map.
> >>>>[...]
> [...]
> it seems only a symptom, also using that, I have still one
> rebase segfault more crazy than b
ence on a stripped ltree.dll
it seems only a symptom, also using that, I have still one
rebase segfault more crazy than before.
(ltree.dll is fine now)
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off A
On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
On Jan 15 11:36, marco atzeri wrote:
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
On Jan 15 09:43, marco atzeri wrote:
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org
On Jan 15 11:36, marco atzeri wrote:
> On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
> >On Jan 15 09:43, marco atzeri wrote:
> >>rebase is segfaulting on two dlls of new package
> >>
> >>postgresql-contrib-9.2.2-1
> >>
> >>Full packages here
> >>http://matzeri.altervista.org/cygwin-1.7/postgresql/
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
On Jan 15 09:43, marco atzeri wrote:
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org/cygwin-1.7/postgresql/
Just the two dll's here:
http://matzeri.altervista.org/works/
On Jan 15 09:43, marco atzeri wrote:
> rebase is segfaulting on two dlls of new package
>
> postgresql-contrib-9.2.2-1
>
> Full packages here
> http://matzeri.altervista.org/cygwin-1.7/postgresql/
>
> Just the two dll's here:
> http://matzeri.altervista.org/works/rebase/
>
> for i in *.dll; do
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org/cygwin-1.7/postgresql/
Just the two dll's here:
http://matzeri.altervista.org/works/rebase/
for i in *.dll; do echo $i ; rebase -O $i ; done
dict_snowball.dll
Segmenta
41 matches
Mail list logo
