mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Hi Brian

> You mean there's two copies of an identical reloc to the same location? 

Yes, according to pedump and PE Explorer:

Virtual Address: 001E3000  size: 00000110
[...snip...]
  001E3C62 HIGHLOW
[...snip...]
Virtual Address: 001E3000  size: 00000110
[...snip...]
  001E3C62 HIGHLOW

Other addresses are repeated too, it looks like all the base relocation
entries are repeated twice for this DLL.

- Dave

David Daeschler wrote:

> So then I looked at the Relocation entries in the DLL I built, and sure
> enough there are 2 entries for 6E763C62.  Both in .text according to PE
> Explorer Disassembler.

You mean there's two copies of an identical reloc to the same location? 
That definitely sounds like a linker bug.  Try a CVS binutils just to
rule out something that's already been fixed.

> Xerces appears to use dllwrap in its build process.

Yuck.  Dllwrap is old and kind of crufty, the preferred way for creating
a DLL is simply "gcc -shared" like on other platforms.  If this double
reloc thing can be traced to a bug in dllwrap I could certainly see why
it would linger around without being noticed.

Brian

Hi Again Brian,

Once again, I'm back with more information about the Application Failed
to Initialize problem.

It looks like in certain cases, 2 reloc entries are being inserted for
the jmp_msvcrt.dll!malloc entry of some of my DLLs.  

xerces_c happens to be one of the DLLs that is affected, here is a
disassembly (using PE Explorer Disassembler):

 6E763C60   jmp	[msvcrt.dll!malloc]

That is the jmp *ADDRESS that we've been seeing.  Before any fixups are
applied, it matches the address of the msvcrt import table entry
in .idata:

 6E9AB300                           msvcrt.dll!malloc:
 6E9AB300  70B74200                  		dd	??

However, when I load the DLL I get an access violation:

Dump of assembler code for function malloc:
  0x014d3c60 <malloc+0>:  jmp    *0x9448b300

Notice that the DLL has been relocated.  The new base of the DLL is:

                      BASE      SIZE     IMAGE BASE
libxerces-c2_7_0.dll  0x12F0000	0x452000 0x6E580000

That is a difference of:  0x6E580000 - 0x12F0000 = 6D290000



If I Take the address of 6E9AB300 and perform a manual "fixup" on it, I
get:

6E9AB300 - (FIXUP) 6D290000 = 171B300

Hmmm, but the jmp is to *0x9448b300.  Lets do another "fixup":

171B300 - 6D290000 = 0x9448b300

hmmmmmm look familiar?!  

0x014d3c60 <malloc+0>:  jmp    *0x9448b300


So then I looked at the Relocation entries in the DLL I built, and sure
enough there are 2 entries for 6E763C62.  Both in .text according to PE
Explorer Disassembler.

Xerces appears to use dllwrap in its build process.

$ ld -v
GNU ld version 2.17.50 20060824

$ gcc -v
Reading specs from d:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c
++,f77,ada,objc,java --disable-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw special)


Thanks again,
- Dave

Patrick Hartling wrote:

> I am still plugging away with 64-bit MinGW stuff, and I have run into a
> particularly tricky issue. It seems that the 64-bit Visual C++ 8.0 compiler
> does not put a leading underscore on C symbols. The cross-compiler build of
> GCC 4.3.0 that I am using does, and that means that a 64-bit C library built
> using MinGW fails to resolve symbols needed by code compiled by Visual C++
> that is linking against that C library.

If gcc is not following the MS x64 platform ABI, then that's a bug that
needs to be fixed.  The port is ongoing and you should take this up with
Kai and/or the gcc list.  I seem to recall that Kai has been working on
pushing through a patch that allows supporting more than one ABI at a
time in the i386 backend, and that might be a prerequisite for fixing
this.

Brian

I'm slowly making progress on getting the new environment setup for 
building drivers using mingw and msys.

I've run into another glitch that perhaps someone can help with.

I'm using the 6001 ddk and attempting to compile the sample echo driver 
(which is WDF based).

I see that mingw has its own tree of include files, and that wdf.h is not 
there.  It is reasonable to assume that MinGW doesn't support the WDF yet?

If I don't modify the include of <ntddk.h> to <ddk/ntddk.h> then ntddk can 
not be found.  And, if I add the WinDDK include path with -I, i get a lot of
redefined references.

I don't intend to build the entire DDK, I'm just looking to validate that a 
driver built with mingw acts the same as when build with 'build' of the DDK.

thanks in advance for any help.

-- Brian

I am still plugging away with 64-bit MinGW stuff, and I have run into a
particularly tricky issue. It seems that the 64-bit Visual C++ 8.0 compil=
er
does not put a leading underscore on C symbols. The cross-compiler build =
of
GCC 4.3.0 that I am using does, and that means that a 64-bit C library bu=
ilt
using MinGW fails to resolve symbols needed by code compiled by Visual C+=
+
that is linking against that C library.

What behavior should be expected here? I can use -fno-leading-underscore
when I build the C library using GCC 4.3, but then I think I am running t=
he
risk of not being able to have symbols from MinGW libraries be resolved. =
(So
far, this is the case for snprintf() and round() in the case of the libra=
ry
I am working with). If I could generate static libraries (see the "Binuti=
ls
version for 64-bit MinGW" thread), then I could rebuild the MinGW CRT wit=
h
-fno-leading-underscore. Of course, then I expect that I would have to bu=
ild
all 64-bit code on MinGW with -fno-leading-underscore. If I want librarie=
s
MinGW-compiled to be able to be linked with 64-bit code compiled by Visua=
l
C++ 8, I think I have to do it that way.

Are there other ways of dealing with this? Ideally, I would use a #pragma=
 or
something in my code being compiled by Visual C++ before and after includ=
ing
the headers from the C library compiled with GCC. I don't know if such a
thing can actually be done, and it might just end up interfering with C
symbols from the MSVC 8 runtime. Maybe I just need to recompile GCC 4.3
again with some flag that tells is not to put the leading underscore on
function symbols that it generates.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

> I tred to remove myself from the mingw developer/admin group and was
> told:

Could this be a joke or spam?

> Please remove my admin and developer status, Ms/Mr Controller.

Wouldn't Danny direct this to someone (i.e. Kieth?)

> Bye

If this is goodbye,  I am sorry to see you go Danny.  You only made my
view of Kiwi's better with your selfless service to the cause.  And
before anyone gets out of shape I deep down consider myself kiwi after
living there for a year years ago, and have the utmost regard for their
way of life.

Sam

Hi Greg,

> What was that last bug

See:

http://sourceforge.net/mailarchive/forum.php?thread_name=1187200750.8500.38.camel%40devit.rsaisp.com&forum_name=mingw-users

> what problem is solved by maintaining two separate build systems

We moved the code over to Visual Studio Express and it compiles and
runs.  As we are using makefiles/gcc for our Linux/MacOS/MINGW builds
moving everything over to VC was a pain, but I needed to get an updated
release out so I had no choice as I don't know how long it will take me
and/or others to fully track down the bug.

- Dave

Brian Hawley wrote:
[...]

Umm.. The thread "[Mingw-users] free() - how is it
implemented in mingw?" now also contains messages from
no less than *two* completely nonrelated subjects,
thanks to you.

I read my messages using a threaded view.
The threads are determined based on either of the following
reasons:
1) "References" header.
   The message I responded to references message id
   "<435...@tb...>", which, apparently
   by sheer accident, is the id of the first post of
   the aforementioned thread.
2) "Subject" header.

You managed to change the subject, a worthy accomplishment
in itself. However, you did not scrub the reference out of
the message, so now your messages, as well as all the replies
to them, seem to be replies to an unrelated thread.
This not only affects me, but anyone reading the list archives
on the web.

I would appreciate if in future you would get rid of
references to other messages when starting a new thread.
The easiest way to do that is to *not* *reply* to messages,
but write a completely new one instead.
If it is a question along the lines of not being able to
remember the mailing list address, I suggest you either
take a look at the address book functionality of your e-mail
client or familiarize yourself with the art of copy-paste
(possibly using the functionality of your windowing system
 or even pen and paper).


Thank you,
-- 
Tuomo

... There is much Obi-Wan did not tell you

On 2007-08-31 12:58Z, David Daeschler wrote:
> 
> What a terrible loss.  As a small business, having to switch away from
> MINGW for windows would be a huge undertaking that I was hoping we'd
> never have to go through.  Just from the last bug we hit, I now have to
> maintain 2 separate build systems, and it is not easy at all.

What was that last bug, and specifically what problem is solved by
maintaining two separate build systems? I ask because there might
be a better way.

Sisyphus wrote:
> Hi,
> On Windows Vista 64,  MSYS-1.0.11 (making use of Cesar Strauss's patched 
> versions of
> msys-1.0.dll, mount.exe and ps.exe), running "make install"
> (for whichever library I've just built) fails. Here's how trying to install
> GMP-4.2.2 (release candidate) finishes up. I get essentially the same for
> other libraries, too:

[...]

>  /bin/install -c -m 644 './gmp.info' '/usr/local/info/gmp.info'
> /bin/sh: /bin/install: Permission denied


Hi, Sisyphus

Please take a look to the following bug report:

[ 1711379 ] /bin/install and /bin/install-info fail on Vista

http://sourceforge.net/tracker/index.php?func=detail&aid=1711379&group_id=2435&atid=102435

  Vista uses heuristics based, amongst other things, on the executable
  name to detect install programs. Having "install" in the names of
  these executables causes Vista to think they need Administrative
  privileges to run, and so results in a "Permission denied" error when
  they are called without Administrative privileges.

  This can be fixed by including the attached install.exe.manifest and
  install-info.exe.manifest in the /bin/ directory. These files override
  Vista's heuristics and tell it that the corresponding executables
  actually don't need Administrative privileges.

Please try downloading the files found at the bottom of that page and
place them in the /bin directory.

I'm preparing a new coreutils snapshot that will include these files.

Regards,
Cesar

Hi Bob,

> Does anyone know what the current state of mingw/gcc developmenet is?
> Does mingw/gcc have an active maintainer anymore?

I don't know, but I was going through the GCC 3.4.5 sources last night
and the files for mingw/win32 stuff had Danny's name all over them.  It
doesn't appear that just anyone could jump right in and continue where
he left off either.

What a terrible loss.  As a small business, having to switch away from
MINGW for windows would be a huge undertaking that I was hoping we'd
never have to go through.  Just from the last bug we hit, I now have to
maintain 2 separate build systems, and it is not easy at all.

If there's anything I can help with in my 8 hours of spare time a week I
would be happy to try.

- Dave

On Thu, Aug 30, 2007 at 04:38:11PM +0100, Keith Marshall wrote:
> On Thursday 30 August 2007 15:00, Bob Rossi wrote:
> > On Thu, Aug 30, 2007 at 08:29:58PM +1200, Danny Smith wrote:
> > > Bye
> >
> > Is it a coincidence that you are also leaving, after Earnie just
> > left us?
> 
> Earnie hasn't completely abandoned us.  For personal reasons, he has 
> been forced to reduce his day to day involvement, but he is still an 
> active participant on the MinGW-dvlpr list.

That's great news.

Does anyone know what the current state of mingw/gcc developmenet is?
Does mingw/gcc have an active maintainer anymore?

Thanks,
Bob Rossi

Hi,
On Windows Vista 64,  MSYS-1.0.11 (making use of Cesar Strauss's patched 
versions of
msys-1.0.dll, mount.exe and ps.exe), running "make install"
(for whichever library I've just built) fails. Here's how trying to install
GMP-4.2.2 (release candidate) finishes up. I get essentially the same for
other libraries, too:

----------------------------
.
.
test -z "/usr/local/info" || mkdir -p -- . "/usr/local/info"
 /bin/install -c -m 644 './gmp.info' '/usr/local/info/gmp.info'
/bin/sh: /bin/install: Permission denied
 /bin/install -c -m 644 './gmp.info-1' '/usr/local/info/gmp.info-1'
/bin/sh: /bin/install: Permission denied
 /bin/install -c -m 644 './gmp.info-2' '/usr/local/info/gmp.info-2'
/bin/sh: /bin/install: Permission denied
make[3]: Leaving directory `/c/_32/comp/gmp-4.2.2/doc'
make[2]: Leaving directory `/c/_32/comp/gmp-4.2.2/doc'
make[2]: Entering directory `/c/_32/comp/gmp-4.2.2'
make[3]: Entering directory `/c/_32/comp/gmp-4.2.2'
test -z "/usr/local/lib" || mkdir -p -- . "/usr/local/lib"
 /bin/sh ./libtool --mode=install /bin/install -c  'libgmp.la'
'/usr/local/lib/libgmp.la'
/bin/install -c .libs/libgmp.dll.a /usr/local/lib/libgmp.dll.a
./libtool: /bin/install: Permission denied
make[3]: *** [install-libLTLIBRARIES] Error 126
make[3]: Leaving directory `/c/_32/comp/gmp-4.2.2'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/c/_32/comp/gmp-4.2.2'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/c/_32/comp/gmp-4.2.2'
make: *** [install] Error 2
----------------------------

I'm running under a user account that normally can write to these
directories.

Any thoughts on how I might structure things so that "make install" works 
correctly ?

Cheers,
Rob 

I use the downloaded automated installer to download and install mingw
candidate version. The installer always show the error "Error: Failure
reading from tarball.". Why?

http://www.nabble.com/file/p12403496/ScreenHunter_01%2BAug.%2B30%2B17.21.gif 

I had tried to redownload the automated installer many times.

Any ways to solve my problem? Manual install also accepted.

I only want to use the candidate version.
-- 
View this message in context: http://www.nabble.com/Error-when-installing-mingw-candidate-version.-Please-help.-tf4352995.html#a12403496
Sent from the MinGW - User mailing list archive at Nabble.com.

You could d/l an older version of mingw and try again just to be sure.

On 8/30/07, Brian Hawley <bh...@lu...> wrote:
>
> hmmm....i built this same chain with the same file on an older version of
> mingw about 2 years ago.
>
> I don't believe that file is a c++ file.
>
> At 07:28 PM 8/30/2007, Brian Dessent wrote:
> >Brian Hawley wrote:
> >
> > > By removing a .OBJ which is supplied by a third party, the build completes
> > > okay.
> > >
> > > I'm still curious why I can't have the .OBJ as part of the build.
> >
> >gcc and MSVC are compatible at the C ABI level only.  Not C++.  Those
> >are C++ symbols.
> >
> >Brian
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by: Splunk Inc.
> >Still grepping through log files to find problems?  Stop.
> >Now Search log events and configuration files using AJAX and a browser.
> >Download your FREE copy of Splunk now >>  http://get.splunk.com/
> >_______________________________________________
> >MinGW-users mailing list
> >Min...@li...
> >
> >You may change your MinGW Account Options or unsubscribe at:
> >https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

hmmm....i built this same chain with the same file on an older version of 
mingw about 2 years ago.

I don't believe that file is a c++ file.

At 07:28 PM 8/30/2007, Brian Dessent wrote:
>Brian Hawley wrote:
>
> > By removing a .OBJ which is supplied by a third party, the build completes
> > okay.
> >
> > I'm still curious why I can't have the .OBJ as part of the build.
>
>gcc and MSVC are compatible at the C ABI level only.  Not C++.  Those
>are C++ symbols.
>
>Brian
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

Brian Hawley wrote:

> By removing a .OBJ which is supplied by a third party, the build completes
> okay.
> 
> I'm still curious why I can't have the .OBJ as part of the build.

gcc and MSVC are compatible at the C ABI level only.  Not C++.  Those
are C++ symbols.

Brian

By removing a .OBJ which is supplied by a third party, the build completes 
okay.

I'm still curious why I can't have the .OBJ as part of the build.

At 06:51 PM 8/30/2007, Brian Hawley wrote:


>Can anyone shed some light on this?  On an older version of mingw/msys the
>build did not seem to do this.
>
>Warning: .drectve `-defaultlib:OLDNAMES                 ' unrecognized
>Cannot export ??_C@_02DILL@?$CFs?$AA@: symbol not found
>Cannot export ??_C@_08PNBE@?$CFs?5?$CFd?5?$CFd?$AA@: symbol not found
>Cannot export ??_C@_09GECL@ppmon?4exe?$AA@: symbol not found
>Cannot export ??_C@_0BA@JOCO@?2?2?4?2KeyDongle_0?$AA@: symbol not found
>Cannot export ??_C@_0BB@GJGA@Driver?5not?5found?$AA@: symbol not found
>Cannot export ??_C@_0BB@PDPJ@?2?2?4?2PARCLASS?4VXD?$AA@: symbol not found
>Cannot export ??_C@_0O@FBNE@?2?2?4?2PARCLASS0?$AA@: symbol not found
>collect2: ld returned 1 exit status
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

By removing the trailing / from -I../ it finds the headers 
fine.  Interesting that this did not seem to be a problem before.

At 06:26 PM 8/30/2007, Brian Hawley wrote:

>I've just installed the latest mingw and msys 'current' packages.
>
>gcc is actually running in
>
>v:/users/bhawley/.../Libraries/base
>
>in v:/users/bhawley/.../Libraries is a file called project.h
>
>for some reason, gcc is not able to find it even though -I../ is specified
>on the command line.  i checked the permissions and i can access the file.
>
>any suggestions on how to resolve this would be appreciated.
>
>gcc     -DARCH=generic-i386-winxp  -DVERSION_STRING='"base 2.1.0.4 ARCH:
>generic-i386-winxp libs:        wsock32 iberty msvcrt   Built: Thu Aug 30
>18:21:46 PDT 2007 Copyright(C) 2004 Luminex Software, Inc. All Rights
>Reserved."'  -I./  -I../  -I../generic-i386-winxp/
>-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4//include
>-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/
>-I/home/engr/support/site/1.7
>-I/home/engr/support/site/1.7/generic-i386-winxp  -I/usr/local/include
>-I/home/engr/support/generic-i386-winxp/w32compat/pthread/include  -c
>lsirand.c -o
>/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/lsirand.o
>In file included from lsirand.c:75:
>v:/support/site/1.7/site.h:147:21: project.h: No such file or directory
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

Can anyone shed some light on this?  On an older version of mingw/msys the 
build did not seem to do this.

Warning: .drectve `-defaultlib:OLDNAMES                 ' unrecognized
Cannot export ??_C@_02DILL@?$CFs?$AA@: symbol not found
Cannot export ??_C@_08PNBE@?$CFs?5?$CFd?5?$CFd?$AA@: symbol not found
Cannot export ??_C@_09GECL@ppmon?4exe?$AA@: symbol not found
Cannot export ??_C@_0BA@JOCO@?2?2?4?2KeyDongle_0?$AA@: symbol not found
Cannot export ??_C@_0BB@GJGA@Driver?5not?5found?$AA@: symbol not found
Cannot export ??_C@_0BB@PDPJ@?2?2?4?2PARCLASS?4VXD?$AA@: symbol not found
Cannot export ??_C@_0O@FBNE@?2?2?4?2PARCLASS0?$AA@: symbol not found
collect2: ld returned 1 exit status

I've just installed the latest mingw and msys 'current' packages.

gcc is actually running in

v:/users/bhawley/.../Libraries/base

in v:/users/bhawley/.../Libraries is a file called project.h

for some reason, gcc is not able to find it even though -I../ is specified 
on the command line.  i checked the permissions and i can access the file.

any suggestions on how to resolve this would be appreciated.

gcc     -DARCH=generic-i386-winxp  -DVERSION_STRING='"base 2.1.0.4 ARCH: 
generic-i386-winxp libs:        wsock32 iberty msvcrt   Built: Thu Aug 30 
18:21:46 PDT 2007 Copyright(C) 2004 Luminex Software, Inc. All Rights 
Reserved."'  -I./  -I../  -I../generic-i386-winxp/ 
-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4//include 
-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/ 
-I/home/engr/support/site/1.7 
-I/home/engr/support/site/1.7/generic-i386-winxp  -I/usr/local/include 
-I/home/engr/support/generic-i386-winxp/w32compat/pthread/include  -c 
lsirand.c -o 
/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/lsirand.o
In file included from lsirand.c:75:
v:/support/site/1.7/site.h:147:21: project.h: No such file or directory

Patrick Hartling wrote:
> NightStrike wrote:
>> On 8/29/07, Patrick Hartling <pa...@13...> wrote:
>>> I already did all of this. I am just trying to update the binutils pa=
rt of
>>> the toolchain since it is a couple of months out of date.
>> Ah, now I understand.
>>
>>>> For information on building the crt, look here:
>>>> http://sourceforge.net/projects/mingw-w64
>>> I will look into this as I had not come across that project before. I=
 see
>>> that it includes a newer snapshot of the CRT than the MinGW project
>>> downloads on SourceForge.
>>>
>>>> If you want, I can build you a toolchain and tar it up.
>>> That shouldn't be necessary, but I appreciate the offer. I haven't ye=
t felt
>>> confident that my 64-bit toolchain is working, so I may ask again lat=
er. :)
>> Can you build a "Hello, world" yet?
>=20
> Yes, and Dependency Walker shows that it is a 64-bit binary. I should h=
ave
> done that sooner. :)
>=20
> I saw that Binutils 2.18 was released yesterday, and I was able to buil=
t it
> to target x86_64-pc-mingw32 without any troubles. Its ar still generate=
s .a
> files that ranlib and nm do not like, though. This is not too surprisin=
g
> there probably aren't too many differences yet between the CVS HEAD and=
 the
> 2.18 branch. The Visual C++ linker also does not like them, and my real=
 goal
> here is to make a static build of FFmpeg that I can use with other soft=
ware
> that is built with Visual C++.
>=20
>  -Patrick

Well, I am at a loss here. I have built multiple different versions of
binutils from the last two months, and I keep getting bad .a files. I hav=
e
built binutils using GCC 3.4.5 and 4.2.1 from MinGW as well as using vers=
ion
3.4.4 from Cygwin. The last working version that I had was from June 29, =
but
rebuilding those sources does not work either. (If I had been more carefu=
l,
I would have backed up the binutils installation that seemed to be workin=
g,
but that's long gone now.)

My current theory is that GCC is the problem because I see some errors ab=
out
truncated .o files. I just built a GCC cross compiler from today's
Subversion trunk, and I still cannot make working .a files.

I also thought that it might help to update to the latest w64 CRT snapsho=
t,
but I cannot build that either because of the same issues with .a files. =
The
error that I get is the following:

/usr/local/bin/x86_64-pc-mingw32-ar.exe rc libmingw32.a crt0_c.o crt0_w.o=

dll_argv.o  gccmain.o CRT_fp10.o pseudo-reloc.o pseudo-reloc-list.o pesec=
t.o
cinitexe.o natstart.o gs_support.o atonexit.o dllmain.o dllentry.o
wildcard.o merr.o dllargv.o charmax.o xtxtmode.o tlssup.o xncommod.o
_newmode.o xthdloc.o mingw_helpers.o
/usr/local/bin/x86_64-pc-mingw32-ranlib.exe libmingw32.a
C:\msys\1.0\local\bin\x86_64-pc-mingw32-ranlib.exe: libmingw32.a: File
format not recognized

I have been trying to see if I can make simple static libraries but have =
met
with limited success. In one case, I was able to create a 64-bit static
library from two object files, but when I looked at the contents using
x86_64-pc-mingw32-nm, it showed only the symbols from the first. If I try=
 to
add a third object file to the static library, it complains that the firs=
t
=2Eo file in the archive is truncated.

Before I pursue this any further, I should ask this: should I expect to b=
e
able to link a 64-bit library made with MinGW with other 64-bit code
compiled using Visual C++ (version 8.0 in case it makes a difference)? I
have things working really, really well with 32-bit code, but the 64-bit
case seems just beyond my grasp. I understand that the 64-bit MinGW
toolchain and CRT are still in the early testing phases, but I get the
feeling that the source of my troubles is something really simple that I
have done wrong.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

----- Original Message ----=0AFrom: Keith Marshall <kei...@us...=
rceforge.net>=0ATo: min...@li...=0ACc: Danny Smith <da=
nny...@cl...>; min...@li...=0ASent: Thursday,=
 August 30, 2007 9:53:43 AM=0ASubject: Re: [Mingw-users] bye=0A=0A=0A>I'm s=
addened that you feel the need to distance yourself from MinGW, in =0A>this=
 way; indeed, I fear for the future of the project, without you at =0A>the =
helm to look after GCC development.  However, I'm sure that you =0A>have yo=
ur reasons, and I respect them.=0A=0AIs Danny's source checked in anywhere =
in case someone did want to take a look at helping out? There were a few bu=
g fixes he was working on and you'd hate to start over on them.=0A=0AThankd=
,=0ADoug.

On Thursday 30 August 2007 15:00, Bob Rossi wrote:
> On Thu, Aug 30, 2007 at 08:29:58PM +1200, Danny Smith wrote:
> > Bye
>
> Is it a coincidence that you are also leaving, after Earnie just
> left us?

Earnie hasn't completely abandoned us.  For personal reasons, he has 
been forced to reduce his day to day involvement, but he is still an 
active participant on the MinGW-dvlpr list.

If there are any burning issues, for which I feel Earnie's input is 
desirable, then I will forward the enquiry to him.  I do try to keep 
such traffic to a minimum, and to respect his wishes, we would ask
that only I should direct enquiries to him, but he will participate
in any discussion in which I invite his contribution.

Regards,
Keith.