RE: LInking problems

RE: LInking problems

[MR. S.CHANDER]

Hi,
   I am using the snapshot as compiled by mumit. Snapshot 19990715 and
the latest one, both give the same error.
I get the following error when I try to link:
/usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
source/TransformNode.cpp -o  obj/TransformNode.o
ar rc lib/libSGGT.a obj/VRMLVisitor.o obj/SGGTVisitor.o obj/RootNode.o
obj/TransformNode.o obj/GroupNode.o obj/LODNode.o
 obj/MaterialNode.o obj/DirectionalLightNode.o obj/PointLightNode.o
obj/SpotLightNode.o obj/GeometryBoxNode.o obj/Geomet
ryConeNode.o obj/GeometryCylinderNode.o obj/GeometrySphereNode.o
obj/GeometryFileNode.o obj/Vec3.o obj/RotationVec.o
/usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
source/SGGTTester.cpp -o obj/SGGTTester.o
/usr/local/H-i586-cygwin32/bin/g++  obj/SGGTTester.o lib/libSGGT.a -o
bin/SGGTTester
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iostream.o)(.text+0x114):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iostream.o)(.text+0x4d1):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x60):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x8d):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x588):
undefined refere
nce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x5dc):
more undefined r
eferences to `_imp___ctype_' follow
collect2: ld returned 1 exit status
make: *** [bin/SGGTTester] Error 1

Anybody have an idea as to what I'm doing wrong???

Cheers
Satpal Chander

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

Re: LInking problems

[Mumit Khan]

"MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> Hi,
>    I am using the snapshot as compiled by mumit. Snapshot 19990715 and
> the latest one, both give the same error.
> I get the following error when I try to link:
> /usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
> source/TransformNode.cpp -o  obj/TransformNode.o
> ar rc lib/libSGGT.a obj/VRMLVisitor.o obj/SGGTVisitor.o obj/RootNode.o
> obj/TransformNode.o obj/GroupNode.o obj/LODNode.o
>  obj/MaterialNode.o obj/DirectionalLightNode.o obj/PointLightNode.o
> obj/SpotLightNode.o obj/GeometryBoxNode.o obj/Geomet
> ryConeNode.o obj/GeometryCylinderNode.o obj/GeometrySphereNode.o
> obj/GeometryFileNode.o obj/Vec3.o obj/RotationVec.o
> /usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
> source/SGGTTester.cpp -o obj/SGGTTester.o
> /usr/local/H-i586-cygwin32/bin/g++  obj/SGGTTester.o lib/libSGGT.a -o
> bin/SGGTTester
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iostream.o)(.text+0x114):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iostream.o)(.text+0x4d1):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x60):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x8d):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x588):
> undefined refere
> nce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x5dc):
> more undefined r
> eferences to `_imp___ctype_' follow
> collect2: ld returned 1 exit status
> make: *** [bin/SGGTTester] Error 1
> 
> Anybody have an idea as to what I'm doing wrong???

Did you actually read the README file that comes with gcc-2.95 before
installing the compilers?

If not, please do so. It tells you what to do when you're using Cygwin
development snapshots.

Regards,
Mumit



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

Re: LInking problems

[MR. S.CHANDER]

Mumit Khan wrote:

<snip>

> > /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> > iostream.o)(.text+0x114):
> > undefined referen
> > ce to `_imp___ctype_'
> > /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> > iostream.o)(.text+0x4d1):
> > undefined referen
> > Anybody have an idea as to what I'm doing wrong???

<snip>

> Did you actually read the README file that comes with gcc-2.95 before
> installing the compilers?

> If not, please do so. It tells you what to do when you're using Cygwin
> development snapshots.

Actually I hadn't (naughty) but now that I have I still get the same error.
I have added the -I flag and then -L flag and then -mno-cygwin flags
incrementally.

The error only starts on the 199907 snapshot any before work fine and the normal
B20.1
works as well.

Cheers
Satpal Chander





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

Re: LInking problems

[Mumit Khan]

"MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> 
> Actually I hadn't (naughty) but now that I have I still get the same error.
> I have added the -I flag and then -L flag and then -mno-cygwin flags
> incrementally.

And did you read the -mno-cygwin howto before using -mno-cygwin? It's at
my site.

Mumit


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

Re: LInking problems

[MR. S.CHANDER]

Mumit Khan wrote:

> "MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> >
> > Actually I hadn't (naughty) but now that I have I still get the same error.
> > I have added the -I flag and then -L flag and then -mno-cygwin flags
> > incrementally.
>
> And did you read the -mno-cygwin howto before using -mno-cygwin? It's at
> my site.

I have and have now read it again and realised that I don't need to compile
mingw, I think???
All I want to do is compile to a .a library (creating a .so library seems to
complecated at the mo)
and then link to a testing program.
So therefore I don't need to link in the extra mignw stuff. I  think it should
work with normal
cygwin.

I'm sorry I appear to be missing a simple point on this one, and got me confused
!!!


Cheers
Satpal Chander



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

Re: LInking problems

[Mumit Khan]

"MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> 
> Actually I hadn't (naughty) but now that I have I still get the same error.
> I have added the -I flag and then -L flag and then -mno-cygwin flags
> incrementally.

And did you read the -mno-cygwin howto before using -mno-cygwin? It's at
my site.

Mumit


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

Re: LInking problems

[MR. S.CHANDER]

Mumit Khan wrote:

<snip>

> > /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> > iostream.o)(.text+0x114):
> > undefined referen
> > ce to `_imp___ctype_'
> > /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> > iostream.o)(.text+0x4d1):
> > undefined referen
> > Anybody have an idea as to what I'm doing wrong???

<snip>

> Did you actually read the README file that comes with gcc-2.95 before
> installing the compilers?

> If not, please do so. It tells you what to do when you're using Cygwin
> development snapshots.

Actually I hadn't (naughty) but now that I have I still get the same error.
I have added the -I flag and then -L flag and then -mno-cygwin flags
incrementally.

The error only starts on the 199907 snapshot any before work fine and the normal
B20.1
works as well.

Cheers
Satpal Chander





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

Re: LInking problems

[MR. S.CHANDER]

Mumit Khan wrote:

> "MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> >
> > Actually I hadn't (naughty) but now that I have I still get the same error.
> > I have added the -I flag and then -L flag and then -mno-cygwin flags
> > incrementally.
>
> And did you read the -mno-cygwin howto before using -mno-cygwin? It's at
> my site.

I have and have now read it again and realised that I don't need to compile
mingw, I think???
All I want to do is compile to a .a library (creating a .so library seems to
complecated at the mo)
and then link to a testing program.
So therefore I don't need to link in the extra mignw stuff. I  think it should
work with normal
cygwin.

I'm sorry I appear to be missing a simple point on this one, and got me confused
!!!


Cheers
Satpal Chander



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

Re: LInking problems

[Mumit Khan]

"MR. S.CHANDER" <c9502007@hud.ac.uk> writes:
> Hi,
>    I am using the snapshot as compiled by mumit. Snapshot 19990715 and
> the latest one, both give the same error.
> I get the following error when I try to link:
> /usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
> source/TransformNode.cpp -o  obj/TransformNode.o
> ar rc lib/libSGGT.a obj/VRMLVisitor.o obj/SGGTVisitor.o obj/RootNode.o
> obj/TransformNode.o obj/GroupNode.o obj/LODNode.o
>  obj/MaterialNode.o obj/DirectionalLightNode.o obj/PointLightNode.o
> obj/SpotLightNode.o obj/GeometryBoxNode.o obj/Geomet
> ryConeNode.o obj/GeometryCylinderNode.o obj/GeometrySphereNode.o
> obj/GeometryFileNode.o obj/Vec3.o obj/RotationVec.o
> /usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
> source/SGGTTester.cpp -o obj/SGGTTester.o
> /usr/local/H-i586-cygwin32/bin/g++  obj/SGGTTester.o lib/libSGGT.a -o
> bin/SGGTTester
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iostream.o)(.text+0x114):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iostream.o)(.text+0x4d1):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x60):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x8d):
> undefined referen
> ce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x588):
> undefined refere
> nce to `_imp___ctype_'
> /usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(
> iovfscanf.o)(.text+0x5dc):
> more undefined r
> eferences to `_imp___ctype_' follow
> collect2: ld returned 1 exit status
> make: *** [bin/SGGTTester] Error 1
> 
> Anybody have an idea as to what I'm doing wrong???

Did you actually read the README file that comes with gcc-2.95 before
installing the compilers?

If not, please do so. It tells you what to do when you're using Cygwin
development snapshots.

Regards,
Mumit



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

RE: LInking problems

[MR. S.CHANDER]

Hi,
   I am using the snapshot as compiled by mumit. Snapshot 19990715 and
the latest one, both give the same error.
I get the following error when I try to link:
/usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
source/TransformNode.cpp -o  obj/TransformNode.o
ar rc lib/libSGGT.a obj/VRMLVisitor.o obj/SGGTVisitor.o obj/RootNode.o
obj/TransformNode.o obj/GroupNode.o obj/LODNode.o
 obj/MaterialNode.o obj/DirectionalLightNode.o obj/PointLightNode.o
obj/SpotLightNode.o obj/GeometryBoxNode.o obj/Geomet
ryConeNode.o obj/GeometryCylinderNode.o obj/GeometrySphereNode.o
obj/GeometryFileNode.o obj/Vec3.o obj/RotationVec.o
/usr/local/H-i586-cygwin32/bin/g++  -c -DDEBUG=1 -ggdb
source/SGGTTester.cpp -o obj/SGGTTester.o
/usr/local/H-i586-cygwin32/bin/g++  obj/SGGTTester.o lib/libSGGT.a -o
bin/SGGTTester
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iostream.o)(.text+0x114):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iostream.o)(.text+0x4d1):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x60):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x8d):
undefined referen
ce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x588):
undefined refere
nce to `_imp___ctype_'
/usr/local/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95/libstdc++.a(iovfscanf.o)(.text+0x5dc):
more undefined r
eferences to `_imp___ctype_' follow
collect2: ld returned 1 exit status
make: *** [bin/SGGTTester] Error 1

Anybody have an idea as to what I'm doing wrong???

Cheers
Satpal Chander

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

Re: Linking problems

[Larry Hall]

At 07:34 PM 2/1/2004, Sean LeBlanc you wrote:
>On 02-01 18:16, Larry Hall wrote:
>> At 12:40 PM 2/1/2004, Sean LeBlanc you wrote:
>> >Hi all. I'm currently having troubles linking against a lib. The signature
>> >it complains about certainly shows up when I search the lib. I have been
>> >able to build against other libs in the same set (MS' Host Integration
>> >Server API), but not against anything in this lib.
>> >
>> >Are there a set of things to look for when link failures like this happen?
>> >Do some windows libs get exported in different ways that require something
>> >beyond this:
>> >
>> >I'm compiling with both -L<libdir> and -l<libname>.  
>> >
>> >-v doesn't seem to give me any helpful information.
>> 
>> 
>> Please read and follow:
>> 
>> >Problem reports:       http://cygwin.com/problems.html
>> 
>> when contacting the list with an issue you believe to be Cygwin-related.
>> This allows interested parties on the list to evaluate your problem in 
>> the light of some specifics and ask informed follow-up questions.
>> 
>> Thanks,
>
>Well, I guess this is a way of telling me that I didn't include enough info.
>:) 


You're very astute.  I'd give you a gold star for this [this is in no way 
related to CGF's Gold Star program <http://cygwin.com/goldstars/>] but you 
didn't fully digest the content.  I see no output from cygcheck *attached*.
:-(


>I'm not intimating that this is a problem with Cygwin or the gcc (ld)
>port per se, I'm just trying to find out if maybe there is a different way
>that some libs export their methods. Or maybe there is a quirk I'm unaware
>of.  Let me reiterate that I have been able to link against other libs in
>this same api using this same version of gcc on this same version of
>Cygwin...so it's clear that it's possible. 


There's no magic, if that's what you're asking.  You imply that you can
determine that the function you're looking for is in the library.  I'm
not sure how you're doing this but if you can find it via 'nm', then 
you're all set.  


>Anyway, here is a listing of what happens during make when the error occurs.
>Maybe this will be provide more insight:
>
>gcc -v -mno-cygwin -L./lib -Wl,--add-stdcall-alias -shared -o cpic.dll

        ^^^^^^^^^^^^
Ah, so you're using the MinGW version of gcc.  This really takes you out
of the realm of this list and into the MinGW one <http://www.mingw.org/>


>cpic.o -lwcpic32 -lwappc32 -wincsv32
>Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.2/specs
>gcc: unrecognized option `-wincsv32'

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This seems like a problem to me.


>Configured with: /netrel/src/gcc-3.2-3/configure
>--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix
>--with-system-zlib --enable-
>nls --without-included-gettext --enable-interpreter
>--disable-sjlj-exceptions --disable-version-specific-runtime-libs
>--enable-shared --build=i686-pc-
>linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa
>--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
>--includedir=/
>nonexistent/include --libexecdir=/usr/sbin
>Thread model: posix
>gcc version 3.2 20020927 (prerelease)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gcc is out of date.


> /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld.exe
>--shared -Bdynamic -e _DllMainCRTStartup@12 -o cpic.dll /usr/lib/gcc-lib/
>i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib/dllcrt2.o
>/usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtbegin.o -L./lib
>-L/usr/lib/gcc-lib/i686-pc-mingw
>32/3.2
>-L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib
>-L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../.. --add-stdcall-alias cpic
>.o -lwcpic32 -lwappc32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
>-lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc
>-lmoldname -lm
>ingwex -lmsvcrt /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtend.o
>cpic.o(.text+0x6a):cpic.c: undefined reference to `cminit@12'
>
>
>Note that this is a DLL I'm trying to build, but I'm also unable to link
>when just building an executable that uses this same lib. BTW, searching for
>cminit@12 on wcpic32.lib does come back with results.


Ah!  Here's some details.  Well, here's what I get:

nm /Program\ Files/Microsoft\ Visual\ Studio/VC98/Lib/WCPIC32.LIB | grep cminit
00000000 I __imp__cminit@12
00000000 T _cminit@12
00000000 I __imp__cminit_ext@12
00000000 T _cminit_ext@12


This implies to me that you don't have the proper prototype included in 
your program for "cminit()".  I suppose you could try to avoid that by 
specifying "--enable-stdcall-fixup" for gcc but I'm not confident that 
your situation fits the variations that this flag encompasses.


>I hope this provides enough info. 


Better.  But, as I mentioned above, you at least left off the cygcheck 
output, which is real handy when trying to understand your installation
and configuration.  But it looks like you're asking a question which is
off-topic here, since you're not really using the Cygwin compiler (but
rather the MinGW one).  I think I've given you some answers and clues on 
things to pursue or (double) check.  Other than that, I'm not sure how 
much more help I can be, unless you provide a small example and can show
that you have the same problem using gcc with Cygwin as well (which you
probably can).  

Good luck,


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking problems

[Sean LeBlanc]

On 02-01 18:16, Larry Hall wrote:
> At 12:40 PM 2/1/2004, Sean LeBlanc you wrote:
> >Hi all. I'm currently having troubles linking against a lib. The signature
> >it complains about certainly shows up when I search the lib. I have been
> >able to build against other libs in the same set (MS' Host Integration
> >Server API), but not against anything in this lib.
> >
> >Are there a set of things to look for when link failures like this happen?
> >Do some windows libs get exported in different ways that require something
> >beyond this:
> >
> >I'm compiling with both -L<libdir> and -l<libname>.  
> >
> >-v doesn't seem to give me any helpful information.
> 
> 
> Please read and follow:
> 
> >Problem reports:       http://cygwin.com/problems.html
> 
> when contacting the list with an issue you believe to be Cygwin-related.
> This allows interested parties on the list to evaluate your problem in 
> the light of some specifics and ask informed follow-up questions.
> 
> Thanks,

Well, I guess this is a way of telling me that I didn't include enough info.
:) 

I'm not intimating that this is a problem with Cygwin or the gcc (ld)
port per se, I'm just trying to find out if maybe there is a different way
that some libs export their methods. Or maybe there is a quirk I'm unaware
of.  Let me reiterate that I have been able to link against other libs in
this same api using this same version of gcc on this same version of
Cygwin...so it's clear that it's possible. 

Anyway, here is a listing of what happens during make when the error occurs.
Maybe this will be provide more insight:

gcc -v -mno-cygwin -L./lib -Wl,--add-stdcall-alias -shared -o cpic.dll
cpic.o -lwcpic32 -lwappc32 -wincsv32
Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.2/specs
gcc: unrecognized option `-wincsv32'
Configured with: /netrel/src/gcc-3.2-3/configure
--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix
--with-system-zlib --enable-
nls --without-included-gettext --enable-interpreter
--disable-sjlj-exceptions --disable-version-specific-runtime-libs
--enable-shared --build=i686-pc-
linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa
--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--includedir=/
nonexistent/include --libexecdir=/usr/sbin
Thread model: posix
gcc version 3.2 20020927 (prerelease)
 /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld.exe
--shared -Bdynamic -e _DllMainCRTStartup@12 -o cpic.dll /usr/lib/gcc-lib/
i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib/dllcrt2.o
/usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtbegin.o -L./lib
-L/usr/lib/gcc-lib/i686-pc-mingw
32/3.2
-L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib
-L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../.. --add-stdcall-alias cpic
.o -lwcpic32 -lwappc32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
-lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc
-lmoldname -lm
ingwex -lmsvcrt /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtend.o
cpic.o(.text+0x6a):cpic.c: undefined reference to `cminit@12'


Note that this is a DLL I'm trying to build, but I'm also unable to link
when just building an executable that uses this same lib. BTW, searching for
cminit@12 on wcpic32.lib does come back with results.

I hope this provides enough info. 

TIA,

-- 
Sean LeBlanc:seanleblanc@americanisp.net  
http://users.americanisp.net/~seanleblanc/
Get MLAC at: http://sourceforge.net/projects/mlac/
If you don't make things happen then things will happen to you. 
-Lanes Company 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking problems

[Larry Hall]

At 12:40 PM 2/1/2004, Sean LeBlanc you wrote:
>Hi all. I'm currently having troubles linking against a lib. The signature
>it complains about certainly shows up when I search the lib. I have been
>able to build against other libs in the same set (MS' Host Integration
>Server API), but not against anything in this lib.
>
>Are there a set of things to look for when link failures like this happen?
>Do some windows libs get exported in different ways that require something
>beyond this:
>
>I'm compiling with both -L<libdir> and -l<libname>.  
>
>-v doesn't seem to give me any helpful information.


Please read and follow:

>Problem reports:       http://cygwin.com/problems.html

when contacting the list with an issue you believe to be Cygwin-related.
This allows interested parties on the list to evaluate your problem in 
the light of some specifics and ask informed follow-up questions.

Thanks,


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Linking problems

[Sean LeBlanc]

Hi all. I'm currently having troubles linking against a lib. The signature
it complains about certainly shows up when I search the lib. I have been
able to build against other libs in the same set (MS' Host Integration
Server API), but not against anything in this lib.

Are there a set of things to look for when link failures like this happen?
Do some windows libs get exported in different ways that require something
beyond this:

I'm compiling with both -L<libdir> and -l<libname>.  

-v doesn't seem to give me any helpful information.

TIA,

-- 
Sean LeBlanc:seanleblanc@americanisp.net  
http://users.americanisp.net/~seanleblanc/
Get MLAC at: http://sourceforge.net/projects/mlac/
The mark of a good party is that you wake up the next morning wanting to 
change your name and start a new life in different city. 
-Vance Bourjaily, "Esquire" 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Linking problems

[Earnie Boyd]

--- Andre Oliveira da Costa <costa@cade.com.br> wrote:
> > Get a binutils snapshot from Mumit's ftp site or rename collect2
> > so that it's
> > not found and ld is used directly.
> 
> Mmmh... been there, but the snapshots seem to be older than the binutils
> package shipped with gcc-2.95.2:
> 
> (contents of directory /pub/khan/gnu-win32/cygb20/snapshots)
> 
> binutils-19990808/       dlltool/                 gcc-2.95-19990715/
> binutils-19990818/       gcc-2.95-19990609/       libstdc++-v3-19990717/
> binutils-19990911/       gcc-2.95-19990626/       libstdc++-v3-2.90.7/
> 
> I am trying to download binutils-000127.tar.bz2 directly from
> ftp://sourceware.cygnus.com , but I'm not sure I should use one of Mumit's
> snapshots instead. Could you (or Mumit, or anybody ;) ) shed some light
> here? In the meantime, I renamed collect2 to _collect2, and now I got the
> good old message

Can't help on this.  Never tried a binutils build.

> 
> foo.c: undefined reference to xxxx
> 
> back. Odd thing: the linker output message appears slowly on my terminal,
> one char at a time (the rest of the output appears normally). Is this caused
> by the absence of collect2?
> 

Copy ld.exe from the bin directory to the same directory as collect2.  Modify
the specs file and substitute collect2 to ld.



=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

RE: Linking problems

[Andre Oliveira da Costa]

> Get a binutils snapshot from Mumit's ftp site or rename collect2
> so that it's
> not found and ld is used directly.

Mmmh... been there, but the snapshots seem to be older than the binutils
package shipped with gcc-2.95.2:

(contents of directory /pub/khan/gnu-win32/cygb20/snapshots)

binutils-19990808/       dlltool/                 gcc-2.95-19990715/
binutils-19990818/       gcc-2.95-19990609/       libstdc++-v3-19990717/
binutils-19990911/       gcc-2.95-19990626/       libstdc++-v3-2.90.7/

I am trying to download binutils-000127.tar.bz2 directly from
ftp://sourceware.cygnus.com , but I'm not sure I should use one of Mumit's
snapshots instead. Could you (or Mumit, or anybody ;) ) shed some light
here? In the meantime, I renamed collect2 to _collect2, and now I got the
good old message

foo.c: undefined reference to xxxx

back. Odd thing: the linker output message appears slowly on my terminal,
one char at a time (the rest of the output appears normally). Is this caused
by the absence of collect2?

TIA.

Best regards,

Andre


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

RE: Linking problems

[Earnie Boyd]

--- Andre Oliveira da Costa <costa@cade.com.br> wrote:
> Hi Earnie,
> 
> > This is a known bug of your version of collect2.
> 
> Is there any fix available? What should I replace? binutils?
> 

Get a binutils snapshot from Mumit's ftp site or rename collect2 so that it's
not found and ld is used directly.


=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

RE: Linking problems

[Andre Oliveira da Costa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

Hi Earnie,

> This is a known bug of your version of collect2.

Is there any fix available? What should I replace? binutils?

TIA.

Best regards,

Andre
--
André Oliveira da Costa
(costa@cade.com.br)


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

RE: Linking problems

[Earnie Boyd]

--- Andre Oliveira da Costa <costa@cade.com.br> wrote:
> (please refer to previous email for the explanation of the problem)
> 
> Hi,
> 
> making some more tests, I realized that some -L directives for the linker
> were missing, and this obviously explains why the linker was unable to link
> the application. But, the strange thing is: the linker does not spit any
> warning like "cannot find symbol xxx (foo.c)". I'm not sure this is the
> default behavior, but I'm sure I had this kind of output on my Linux box
> (older version of gcc, though).
> 
> Also, I cannot seem to be able to pass parameters directly to the linker via
> the -Xlinker [param] scheme. It doesn't work with -Wl,[parm] either.
> However, if I try to use the linker directly (i.e. "ld -o foo.exe ..."
> instead of "gcc -o foo.exe ..."), I do see some reaction to parameters
> like -M. It looks like gcc is ignoring it... Is anybody else also
> experiencing this?
> 
> (using gcc 2.95.2, ld 2.9.4, uname -a = "CYGWIN_NT-4.0 COSTA
> 22.0(0.16/3/2) 1999-11-23 09:38:16 i586 unknown")
> 

This is a known bug of your version of collect2.

Regards,

=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

RE: Linking problems

[Andre Oliveira da Costa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

(please refer to previous email for the explanation of the problem)

Hi,

making some more tests, I realized that some -L directives for the linker
were missing, and this obviously explains why the linker was unable to link
the application. But, the strange thing is: the linker does not spit any
warning like "cannot find symbol xxx (foo.c)". I'm not sure this is the
default behavior, but I'm sure I had this kind of output on my Linux box
(older version of gcc, though).

Also, I cannot seem to be able to pass parameters directly to the linker via
the -Xlinker [param] scheme. It doesn't work with -Wl,[parm] either.
However, if I try to use the linker directly (i.e. "ld -o foo.exe ..."
instead of "gcc -o foo.exe ..."), I do see some reaction to parameters
like -M. It looks like gcc is ignoring it... Is anybody else also
experiencing this?

(using gcc 2.95.2, ld 2.9.4, uname -a = "CYGWIN_NT-4.0 COSTA
22.0(0.16/3/2) 1999-11-23 09:38:16 i586 unknown")

TIA,

Andre
--
André Oliveira da Costa
(costa@cade.com.br)



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

Linking problems

[Andre Oliveira da Costa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

Hi to all,

I've been experiencing some occasional problems with the linking phase of my
builds, for no apparent reason. It shows up with this message:

collect2: ld returned 1 exit status

First time I remember seeing this was when I tried to compile version 5.4 of
unzip ( ftp://ftp.cdrom.com/infozip/src/unzip540.tar.gz ). Version 5.32
compiles and links successfully. Then I had it again yesterday, compiling
POSLIB 1.1, a POSIX binding for the Lua language
( ftp://ftp3.lmf-di.puc-rio.br/terra/poslib/poslib.tar.gz and
ftp://ftp.tecgraf.puc-rio.br/pub/lua/lua-3.2.tar.gz ). Today, I see a message
from Gunnar Norling [ mailto:Gunnar.Norling@compaq.com ] stating that he's
facing the same problems, with a different application (wget) and a snapshot
more recent than mine.

Is this a knwon bug with gcc/ld? Are there any patches or workarounds
available?

My configuration is:

[ /tmp/poslib ] uname -a
CYGWIN_NT-4.0 COSTA   22.0(0.16/3/2) 1999-11-23 09:38:16 i586 unknown

[ /tmp/poslib ] gcc -v
Reading specs from
/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95.2/specs
gcc version 2.95.2 19991024 (release)

[ /tmp/poslib ] ld -v
GNU ld version 2.9.4 (with BFD 2.9.4)

Any help would be much appreciated.

Best regards,

Andre
--
André Oliveira da Costa
(costa@cade.com.br)


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

Re: Linking problems.

[Mumit Khan]

On Thu, 23 Jul 1998, Aaron Schweiger wrote:

> I am trying to link the mgui graphics library under gnu-win32, however,
> I keep getting linking errors:
> 
> e:\MINGW32\LIB\GCC-LIB\i386-mingw32\egcs-2.90.27\../../..\libmguiw.a(mguiinit.o)(.text+0x2ad):mguiinit.c:
> undefined reference to `MessageBoxA'
> e:\MINGW32\LIB\GCC-LIB\i386-mingw32\egcs-2.90.27\../../..\libmguiw.a(mguiinit.o)(.text+0x904):mguiinit.c:
> undefined reference to `GetModuleFileNameA'
> 
> Quite clearly, the library I am linking is forgetting the @16 needed at
> the end of the function name.  Can I resolve this problem?
> 

Hmmm ... looks like something is redefining STDCALL somewhere, and that's
the root of your problem. In Windows32/ASCIIFunctions.h, MessageBoxA is
declared as the following:
  
  int
  STDCALL
  MessageBoxA (
    /* parameters here
    /* parameters here );

You must be including some header *before* windows.h that's redefining
STDCALL to *nothing* and hence gcc doesn't know that it should append
the @16 to the name of the function and also generate the right code
for pascal-style calling convention required.

Check for messages when compiling and see if there are any messages like:

  ......[file name]: ##: warning: STDCALL redefined.
  ......[ another ]: ##: warning: STDCALL first defined here.

That should get you started. Also, make sure that you've not changed the
GCC specs files.

fyi, STDCALL is defined to __stdcall__((attribute)) in <Windows32/Base.h> 
iff i386 is defined by pre-processor (which is should be in your case).

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linking problems.

[Aaron Schweiger]

I am trying to link the mgui graphics library under gnu-win32, however,
I keep getting linking errors:

e:\MINGW32\LIB\GCC-LIB\i386-mingw32\egcs-2.90.27\../../..\libmguiw.a(mguiinit.o)(.text+0x2ad):mguiinit.c:
undefined reference to `MessageBoxA'
e:\MINGW32\LIB\GCC-LIB\i386-mingw32\egcs-2.90.27\../../..\libmguiw.a(mguiinit.o)(.text+0x904):mguiinit.c:
undefined reference to `GetModuleFileNameA'

Quite clearly, the library I am linking is forgetting the @16 needed at
the end of the function name.  Can I resolve this problem?

Aaron Schweiger

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Linking problems

[Ernest Clayton Cordell, Jr.]

Colin,
	No, I didn't ask the question, but it is a very good answer and I thank 
you.  I was beginning to figure out as much, but it was a long and painful 
process in which I think I must have read a couple of websites.
	I think it is in a FAQ, or readme or some such thing somewhere, but not in 
the present format -- I gleaned much of what you put here from several 
pages, but I don't think a lot of it had sunk in (cognitively) yet.
	There are still quite a few things I need to figure out, but I'm not ready 
to ask the questions yet; I am trying to "assemble my basic toolkit" and 
wait until I hit an obstacle before I trouble anyone with the questions. 
 This is not a comment on approach, this "study style" works best for me 
personally.
	Thanks to all,
Ernie
----------
From: 	Colin Peters
Sent: 	Wednesday, September 17, 1997 11:58 PM
To: 	'Fredrik Eldh'
Cc: 	'GNU-Win32'
Subject: 	RE: Linking problems

Fredrik Eldh[SMTP:lazermasken@hotmail.com] wrote:
>I'm a newbie when it comes to Gnu-Win32 and I'm having trouble when I
>try to link any Win32 program. The linker says I have 'undefined
>references' to all the Win32 API functions. I use the following command
>line to compile and link: "gcc program.c".
>
>Now, please don't tell me to go look this up in an FAQ or something,
>I've already done that and it didn't make me wiser.

It's pretty simple actually, and it should be a FAQ. GNU-Win32 requires
that you explicitly link the import libraries for whatever Win32 API
functions that you are going to use, with the exception of kernel32,
which is linked automatically (because the startup and/or built-in code
uses it). For example, to use graphics functions (GDI) you must link
with gdi32 like this:

  gcc -o foo.exe foo.o bar.o -lgdi32

or (compiling and linking in one step):

  gcc -o foo.exe foo.c bar.c -lgdi32

The regular Cygnus setup allows you to use the option -mwindows on
the command line to include a set of the basic libraries (and also
make your program a GUI program instead of a console program),
including user32, gdi32 and, IIRC, comdlg32.

A few notes:

 - Do not ever include -lkernel32 on your link line (unless you are
   invoking ld directly, in which case I share your pain).

 - Do not include the same import library twice on your link line.

 - Put import libraries last on your link line, or at least after
   all the object files and static libraries that reference them.

The first two are related to problems the linker has currently when
import libraries are referenced twice. Tables get messed up and
programs crash randomly. The last point has to do with the fact that
GCC processes the files listed on the command line in sequence and
will only resolve references to libraries if they are given after
the file that makes the reference.

Anyway, hope that helped.

Colin.

PS. Actually GCC is not being any different from MSVC or other
    Win32 compilers about this. Just open up the build options
    dialog and look for the list of libraries to link. By default
    you'll find a whole mess of import libraries including all
    the ones I mentioned above (at least the last time I looked).

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Linking problems

[Colin Peters]

Fredrik Eldh[SMTP:lazermasken@hotmail.com] wrote:
>I'm a newbie when it comes to Gnu-Win32 and I'm having trouble when I 
>try to link any Win32 program. The linker says I have 'undefined 
>references' to all the Win32 API functions. I use the following command 
>line to compile and link: "gcc program.c".
>
>Now, please don't tell me to go look this up in an FAQ or something, 
>I've already done that and it didn't make me wiser.

It's pretty simple actually, and it should be a FAQ. GNU-Win32 requires
that you explicitly link the import libraries for whatever Win32 API
functions that you are going to use, with the exception of kernel32,
which is linked automatically (because the startup and/or built-in code
uses it). For example, to use graphics functions (GDI) you must link
with gdi32 like this:

  gcc -o foo.exe foo.o bar.o -lgdi32

or (compiling and linking in one step):

  gcc -o foo.exe foo.c bar.c -lgdi32

The regular Cygnus setup allows you to use the option -mwindows on
the command line to include a set of the basic libraries (and also
make your program a GUI program instead of a console program),
including user32, gdi32 and, IIRC, comdlg32.

A few notes:

 - Do not ever include -lkernel32 on your link line (unless you are
   invoking ld directly, in which case I share your pain).

 - Do not include the same import library twice on your link line.

 - Put import libraries last on your link line, or at least after
   all the object files and static libraries that reference them.

The first two are related to problems the linker has currently when
import libraries are referenced twice. Tables get messed up and
programs crash randomly. The last point has to do with the fact that
GCC processes the files listed on the command line in sequence and
will only resolve references to libraries if they are given after
the file that makes the reference.

Anyway, hope that helped.

Colin.

PS. Actually GCC is not being any different from MSVC or other
    Win32 compilers about this. Just open up the build options
    dialog and look for the list of libraries to link. By default
    you'll find a whole mess of import libraries including all
    the ones I mentioned above (at least the last time I looked).

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linking problems

[Mikey]

try

gcc -mwindows -o myprog.o myprog.c
gcc -mwindows -o myprog.exe myrpog.o

although -mwindows is a poor choice for
a gcc option, since it confilcts with the
-mARCH options, so it is useless as an
option to the preprocessor. Not Cygnus's
fault it came from the FSF winNT port.

.On Wed, 17 Sep 1997 04:34:17 PDT, you wrote:

>I'm a newbie when it comes to Gnu-Win32 and I'm having trouble when I 
>try to link any Win32 program. The linker says I have 'undefined 
>references' to all the Win32 API functions. I use the following command 
>line to compile and link: "gcc program.c".
>
>Now, please don't tell me to go look this up in an FAQ or something, 
>I've already done that and it didn't make me wiser.
>
>Thanks for any help,
>Fredrik Eldh
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linking problems

[Fredrik Eldh]

I'm a newbie when it comes to Gnu-Win32 and I'm having trouble when I 
try to link any Win32 program. The linker says I have 'undefined 
references' to all the Win32 API functions. I use the following command 
line to compile and link: "gcc program.c".

Now, please don't tell me to go look this up in an FAQ or something, 
I've already done that and it didn't make me wiser.

Thanks for any help,
Fredrik Eldh

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linking problems

[Jon Thackray]

Jon Thackray writes:
 > 
 > I am still having problem using ld to produce working dlls. I have
 > converted the .lib files I wish to link against into .a files using
 > dlltool (and using nm to create the .def file). However, when I try to
 > link to produce another dll, I find the dll I get is missing its
 > .rdata, .idata and .reloc sections. It also doesn't seem to work very
 > well. I append the linker script and ld command line I used. Here's
 > what objdump thinks of the result, which was produced without error by
 > ld.

Further to this, I have changed the approach as I suspect I'm not
doing the right thing with the link command. I have removed the -r and
added -dy and -shared. After this, I got a load of undefined symbol
references for the __imp symbols. It appears that dlltool generates
these as ___imp, whereas the compiler generating my object files
generates these as __imp. This all works using link. Is there a
version of dlltool about that doesn't prepend this extra _ (it's being
done because it think that is the right thing to do on a 386,
according to the source of dlltool).

 > C:\dyl>objdump --headers threads.dll
 > 
 > threads.dll:     file format pei-i386
 > 
 > Sections:
 > Idx Name          Size      VMA       LMA       File off  Algn
 >   0 .text         00000200  00401000  000000fd  000002b8  2**2
 >                   CONTENTS, ALLOC, LOAD, RELOC, CODE
 >   1 .dyvar        00000200  00402000  00000004  000004b8  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 >   2 .dyfix        00000200  00403000  0000000b  000006b8  2**2
 >                   CONTENTS, ALLOC, LOAD, RELOC, DATA
 > 
 > And here's what I think objdump should have produced, or something
 > like it (this was produced by link).
 > 
 > C:\dyl>objdump --headers j:/releases\pentium-kan/install\x86-win32\bin\threads.dll
 > 
 > j:/releases\pentium-kan/install\x86-win32\bin\threads.dll:     file format pei-i386
 > 
 > Sections:
 > Idx Name          Size      VMA       LMA       File off  Algn
 >   0 .text         00000200  10001000  00000154  00000400  2**2
 >                   CONTENTS, ALLOC, LOAD, CODE
 >   1 .rdata        00000200  10002000  00000126  00000600  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 >   2 .idata        00000400  10003000  000002c8  00000800  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 >   3 .dyvar        00000200  10004000  00000004  00000c00  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 >   4 .dyfix        00000200  10005000  0000000b  00000e00  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 >   5 .reloc        00000200  10006000  00000074  00001000  2**2
 >                   CONTENTS, ALLOC, LOAD, DATA
 > 
 > Finally, here's the link command and script.
 > 
 > 
 > ld -T i386pe.scr -r -E -e _DylanDllEntry@12 -o threads.dll --traditional-format -L. -ldylan j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj j:/releases/pentium-kan/build/x86-win32/threads/threads-library.obj j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj
 > 
 > OUTPUT_FORMAT(pei-i386)
 > TARGET(pe-i386)
 > SECTIONS
 > {
 >   .text  __image_base__ + __section_alignment__  : 
 >   {
 >      *(.init)
 >     *(.text)
 >      ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; 
 > 			LONG (-1); *(.ctors); *(.ctor); LONG (0); 
 >      ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; 
 > 			LONG (-1); *(.dtors); *(.dtor);  LONG (0); 
 >      *(.fini)
 >     /* ??? Why is .gcc_exc here?  */
 >      *(.gcc_exc)
 >      etext = .;
 >     /* Grouped section support currently must be explicitly provided for
 > 	in the linker script.  */
 >     *(.text$)
 >   }
 >   .bss BLOCK(__section_alignment__)  :
 >   {
 >     __bss_start__ = . ;
 >     *(.bss)
 >     *(COMMON)
 >     __bss_end__ = . ;
 >   }
 >   .data BLOCK(__section_alignment__) : 
 >   {
 >     __data_start__ = . ; 
 >     *(.data)
 >     *(.data2)
 >     __data_end__ = . ; 
 >     /* Grouped section support currently must be explicitly provided for
 > 	in the linker script.  */
 >     *(.data$)
 >   }
 >   .rdata BLOCK(__section_alignment__) :
 >   {
 >     *(.rdata)
 >     /* Grouped section support currently must be explicitly provided for
 > 	in the linker script.  */
 >     *(.rdata$)
 >   }
 >   .edata BLOCK(__section_alignment__) :
 >   {
 >     *(.edata)
 >   }
 >   .dydat BLOCK(0x1000) :
 >   {
 >     *(.dydat$a)
 >     *(.dydat$m)
 >     *(.dydat$z)
 >   }
 >   .dyobj BLOCK(0x1000) :
 >   {
 >     *(.dyobj$a)
 >     *(.dyobj$m)
 >     *(.dyobj$z)
 >   }
 >   .dyvar BLOCK(0x1000) :
 >   {
 >     *(.dyvar$a)
 >     *(.dyvar$m)
 >     *(.dyvar$z)
 >   }
 >   .dyfix BLOCK(0x1000) :
 >   {
 >     *(.dyfix$a)
 >     *(.dyfix$m)
 >     *(.dyfix$z)
 >   }
 >   /DISCARD/ :
 >   {
 >     *(.debug$S)
 >     *(.debug$T)
 >     *(.debug$F)
 >     *(.drectve)
 >   }
 >   .idata BLOCK(__section_alignment__) :
 >   {
 >     /* This cannot currently be handled with grouped sections.
 > 	See pe.em:sort_sections.  */
 >     *(.idata$2)
 >     *(.idata$3)
 >     *(.idata$4)
 >     *(.idata$5)
 >     *(.idata$6)
 >     *(.idata$7)
 >   }
 >   .CRT BLOCK(__section_alignment__) :
 >   { 					
 >     /* Grouped sections are used to handle .CRT$foo.  */
 >     *(.CRT$)
 >   }
 >   .tls BLOCK(__section_alignment__) :
 >   { 					
 >     *(.tls$)
 >     ;
 >   }
 >   .rsrc BLOCK(__section_alignment__) :
 >   { 					
 >     /* Grouped sections are used to handle .rsrc$0[12].  */
 >     *(.rsrc$)
 >   }
 >   .endjunk BLOCK(__section_alignment__) :
 >   {
 >     /* end is deprecated, don't use it */
 >      end = .;
 >      __end__ = .;
 >   }
 >   .stab BLOCK(__section_alignment__)  (NOLOAD) : 
 >   {
 >     [ .stab ]
 >   }
 >   .stabstr BLOCK(__section_alignment__) (NOLOAD) :
 >   {
 >     [ .stabstr ]
 >   }
 >   .reloc BLOCK(__section_alignment__) :
 >   { 					
 >     *(.reloc)
 >   }
 > }
 > ------- end -------
 > -
 > For help on using this list (especially unsubscribing), send a message to
 > "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linking problems

[Jon Thackray]

I am still having problem using ld to produce working dlls. I have
converted the .lib files I wish to link against into .a files using
dlltool (and using nm to create the .def file). However, when I try to
link to produce another dll, I find the dll I get is missing its
.rdata, .idata and .reloc sections. It also doesn't seem to work very
well. I append the linker script and ld command line I used. Here's
what objdump thinks of the result, which was produced without error by
ld.

C:\dyl>objdump --headers threads.dll

threads.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000200  00401000  000000fd  000002b8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .dyvar        00000200  00402000  00000004  000004b8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .dyfix        00000200  00403000  0000000b  000006b8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

And here's what I think objdump should have produced, or something
like it (this was produced by link).

C:\dyl>objdump --headers j:/releases\pentium-kan/install\x86-win32\bin\threads.dll

j:/releases\pentium-kan/install\x86-win32\bin\threads.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000200  10001000  00000154  00000400  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  1 .rdata        00000200  10002000  00000126  00000600  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .idata        00000400  10003000  000002c8  00000800  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .dyvar        00000200  10004000  00000004  00000c00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .dyfix        00000200  10005000  0000000b  00000e00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .reloc        00000200  10006000  00000074  00001000  2**2
                  CONTENTS, ALLOC, LOAD, DATA

Finally, here's the link command and script.


ld -T i386pe.scr -r -E -e _DylanDllEntry@12 -o threads.dll --traditional-format -L. -ldylan j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj j:/releases/pentium-kan/build/x86-win32/threads/threads-library.obj j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj

OUTPUT_FORMAT(pei-i386)
TARGET(pe-i386)
SECTIONS
{
  .text  __image_base__ + __section_alignment__  : 
  {
     *(.init)
    *(.text)
     ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; 
			LONG (-1); *(.ctors); *(.ctor); LONG (0); 
     ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; 
			LONG (-1); *(.dtors); *(.dtor);  LONG (0); 
     *(.fini)
    /* ??? Why is .gcc_exc here?  */
     *(.gcc_exc)
     etext = .;
    /* Grouped section support currently must be explicitly provided for
	in the linker script.  */
    *(.text$)
  }
  .bss BLOCK(__section_alignment__)  :
  {
    __bss_start__ = . ;
    *(.bss)
    *(COMMON)
    __bss_end__ = . ;
  }
  .data BLOCK(__section_alignment__) : 
  {
    __data_start__ = . ; 
    *(.data)
    *(.data2)
    __data_end__ = . ; 
    /* Grouped section support currently must be explicitly provided for
	in the linker script.  */
    *(.data$)
  }
  .rdata BLOCK(__section_alignment__) :
  {
    *(.rdata)
    /* Grouped section support currently must be explicitly provided for
	in the linker script.  */
    *(.rdata$)
  }
  .edata BLOCK(__section_alignment__) :
  {
    *(.edata)
  }
  .dydat BLOCK(0x1000) :
  {
    *(.dydat$a)
    *(.dydat$m)
    *(.dydat$z)
  }
  .dyobj BLOCK(0x1000) :
  {
    *(.dyobj$a)
    *(.dyobj$m)
    *(.dyobj$z)
  }
  .dyvar BLOCK(0x1000) :
  {
    *(.dyvar$a)
    *(.dyvar$m)
    *(.dyvar$z)
  }
  .dyfix BLOCK(0x1000) :
  {
    *(.dyfix$a)
    *(.dyfix$m)
    *(.dyfix$z)
  }
  /DISCARD/ :
  {
    *(.debug$S)
    *(.debug$T)
    *(.debug$F)
    *(.drectve)
  }
  .idata BLOCK(__section_alignment__) :
  {
    /* This cannot currently be handled with grouped sections.
	See pe.em:sort_sections.  */
    *(.idata$2)
    *(.idata$3)
    *(.idata$4)
    *(.idata$5)
    *(.idata$6)
    *(.idata$7)
  }
  .CRT BLOCK(__section_alignment__) :
  { 					
    /* Grouped sections are used to handle .CRT$foo.  */
    *(.CRT$)
  }
  .tls BLOCK(__section_alignment__) :
  { 					
    *(.tls$)
    ;
  }
  .rsrc BLOCK(__section_alignment__) :
  { 					
    /* Grouped sections are used to handle .rsrc$0[12].  */
    *(.rsrc$)
  }
  .endjunk BLOCK(__section_alignment__) :
  {
    /* end is deprecated, don't use it */
     end = .;
     __end__ = .;
  }
  .stab BLOCK(__section_alignment__)  (NOLOAD) : 
  {
    [ .stab ]
  }
  .stabstr BLOCK(__section_alignment__) (NOLOAD) :
  {
    [ .stabstr ]
  }
  .reloc BLOCK(__section_alignment__) :
  { 					
    *(.reloc)
  }
}
------- end -------
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: linking problems

[Wei Ku]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6026 bytes --]

>    g++ -lm -o Projet 
($Objects) -lg++

Could it be possible that you include 
'-lg++' in the command line ? The g++ library is included by default if g++ is 
used instead of gcc.

Sincerely,
Wei Ku

***************************************
Department of Physics and Astronomy
The University of Tennessee
1408 Circle Drive
Knoxville, Tennessee 37996-1200
weiku@utkux.utcc.utk.edu
---------------------------------------
Solid State Division
Oak Ridge National Laboratory
P.O.Box 2008
Oak Ridge, TN 37831-6032
Phone: (423) 574-5795
Fax: (423) 574-4143
weiku@solid.ssd.ornl.gov
***************************************



 ----
From: Berenice LOPEZ <Berenice.Lopez@gamsau.archi.fr>
To: gnu mailing list <gnu-win32@cygnus.com>
Date: Friday, June 27, 1997 11:34 AM
Subject: linking problems


    Hi!
    I've been trying to get my software compiling under Windows 
NT 4.0 with gnu-win32. It has been a hard war between me and the linker... I've 
read all the mails in this list (since I have found) and I haven't saw something 
like this.
    This is the message I got everytime I link usig:

    (in the makefile I have this command to link after 
successfully compiling)

    g++ -lm -o Projet ($Objects) -lg++

    (and the answer....)

  g++ -lm -o Paros test.o ego.o droite.o cercle.o plan.o cylindre.o
aplomb.o ada3d.o entite.o base.o fut.o chapito.o architra.o  frise.o  
corniche.o
 fronton.o podium.o  mur.o baie.o couverture.o franchissement.o 
attribut.o matri
ce.o message.o point.o primit.o polyedres.o referent.o support.o deltaz.o 
reseau
.o str.o icop_y_t.o icop_l.o demarc_l.o demarc_y.o -lg++
icop_l.o(.data+0x0):icop_l.cc: multiple definition of `D_matrice'
test.o(.data+0x0):test.cc: first defined here
icop_l.o(.data+0xc):icop_l.cc: multiple definition of `D_idtest'
test.o(.data+0xc):test.cc: first defined here
icop_l.o(.data+0x24):icop_l.cc: multiple definition of `D_idtest_nondecl'
test.o(.data+0x24):test.cc: first defined here
icop_l.o(.data+0x3c):icop_l.cc: multiple definition of `D_idtest_num'
test.o(.data+0x3c):test.cc: first defined here
icop_l.o(.data+0x5dfc):icop_l.cc: multiple definition of `D_listeIdent'
test.o(.data+0x5dfc):test.cc: first defined here
icop_l.o(.data+0xbbbc):icop_l.cc: multiple definition of `D_nbIdent'
test.o(.data+0xbbbc):test.cc: first defined here
icop_l.o(.text+0x1e90):icop_l.cc: multiple definition of `global destructors 
key
ed to D_matrice'
test.o(.text+0x6d8):test.cc: first defined here
icop_l.o(.text+0x2068):icop_l.cc: multiple definition of `global constructors 
ke
yed to D_matrice'
test.o(.text+0x94c):test.cc: first defined here
icop_l.o(.data+0xbbc0):icop_l.cc: multiple definition of `D_nbIdent_instruction'

test.o(.data+0xd474):test.cc: first defined here
icop_l.o(.data+0xbbc4):icop_l.cc: multiple definition of `D_typeEntiteLu'
test.o(.data+0xd478):test.cc: first defined here
icop_l.o(.data+0xbbc8):icop_l.cc: multiple definition of `D_typeReseauLu'
test.o(.data+0xd47c):test.cc: first defined here
icop_l.o(.data+0xbbcc):icop_l.cc: multiple definition of `result_expr_facul'
test.o(.data+0xd480):test.cc: first defined here
icop_l.o(.data+0xbbd4):icop_l.cc: multiple definition of `reseauL'
test.o(.data+0xd488):test.cc: first defined here
icop_l.o(.data+0xbbd8):icop_l.cc: multiple definition of `module_a_sauver'
test.o(.data+0xd48c):test.cc: first defined here
demarc_y.o(.data+0x0):demarc_y.cc: multiple definition of `D_matrice'
test.o(.data+0x0):test.cc: first defined here
demarc_y.o(.data+0xc):demarc_y.cc: multiple definition of `D_idtest'
test.o(.data+0xc):test.cc: first defined here
demarc_y.o(.data+0x24):demarc_y.cc: multiple definition of 
`D_idtest_nondecl'
test.o(.data+0x24):test.cc: first defined here
demarc_y.o(.data+0x3c):demarc_y.cc: multiple definition of `D_idtest_num'
test.o(.data+0x3c):test.cc: first defined here
demarc_y.o(.data+0x5dfc):demarc_y.cc: multiple definition of `D_listeIdent'
test.o(.data+0x5dfc):test.cc: first defined here
demarc_y.o(.data+0xbbbc):demarc_y.cc: multiple definition of `D_nbIdent'
test.o(.data+0xbbbc):test.cc: first defined here
demarc_y.o(.data+0xbbd8):demarc_y.cc: multiple definition of 
`module_a_sauver'
test.o(.data+0xd48c):test.cc: first defined here
demarc_y.o(.data+0xbbd4):demarc_y.cc: multiple definition of `reseauL'
test.o(.data+0xd488):test.cc: first defined here
demarc_y.o(.data+0xbbc0):demarc_y.cc: multiple definition of 
`D_nbIdent_instruct
ion'
test.o(.data+0xd474):test.cc: first defined here
demarc_y.o(.data+0xbbcc):demarc_y.cc: multiple definition of `result_expr_facul'

test.o(.data+0xd480):test.cc: first defined here
demarc_y.o(.data+0xbbc4):demarc_y.cc: multiple definition of 
`D_typeEntiteLu'
test.o(.data+0xd478):test.cc: first defined here
demarc_y.o(.text+0x1626c):demarc_y.cc: multiple definition of `global 
destructor
s keyed to D_matrice'
test.o(.text+0x6d8):test.cc: first defined here
demarc_y.o(.text+0x16448):demarc_y.cc: multiple definition of `global 
constructo
rs keyed to D_matrice'
test.o(.text+0x94c):test.cc: first defined here
demarc_y.o(.data+0xbbc8):demarc_y.cc: multiple definition of 
`D_typeReseauLu'
test.o(.data+0xd47c):test.cc: first defined here
g++: Internal compiler error: program ld got fatal signal 1
make: *** [Paros] Error 1

    This program is succesfully linked in SOLARIS and 
SGI....
    Also I would like to know if malloc.h is 
available ou how can I use the malloc()?
    Can anyone help me?


                                                
Thanks a lot!



                                                                        
Berenice LOPEZ

linking problems

[Berenice LOPEZ]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5206 bytes --]

    Hi!
    I've been trying to get my software compiling under
Windows NT 4.0 with gnu-win32. It has been a hard war between me and the
linker... I've read all the mails in this list (since I have found) and
I haven't saw something like this.
    This is the message I got everytime I link usig:

    (in the makefile I have this command to link after
successfully compiling)

    g++ -lm -o Projet ($Objects) -lg++

    (and the answer....)

  g++ -lm -o Paros test.o ego.o droite.o cercle.o plan.o cylindre.o
aplomb.o ada3d.o entite.o base.o fut.o chapito.o architra.o  frise.o 
corniche.o
 fronton.o podium.o  mur.o baie.o couverture.o franchissement.o
attribut.o matri
ce.o message.o point.o primit.o polyedres.o referent.o support.o deltaz.o
reseau
.o str.o icop_y_t.o icop_l.o demarc_l.o demarc_y.o -lg++
icop_l.o(.data+0x0):icop_l.cc: multiple definition of `D_matrice'
test.o(.data+0x0):test.cc: first defined here
icop_l.o(.data+0xc):icop_l.cc: multiple definition of `D_idtest'
test.o(.data+0xc):test.cc: first defined here
icop_l.o(.data+0x24):icop_l.cc: multiple definition of `D_idtest_nondecl'
test.o(.data+0x24):test.cc: first defined here
icop_l.o(.data+0x3c):icop_l.cc: multiple definition of `D_idtest_num'
test.o(.data+0x3c):test.cc: first defined here
icop_l.o(.data+0x5dfc):icop_l.cc: multiple definition of `D_listeIdent'
test.o(.data+0x5dfc):test.cc: first defined here
icop_l.o(.data+0xbbbc):icop_l.cc: multiple definition of `D_nbIdent'
test.o(.data+0xbbbc):test.cc: first defined here
icop_l.o(.text+0x1e90):icop_l.cc: multiple definition of `global destructors
key
ed to D_matrice'
test.o(.text+0x6d8):test.cc: first defined here
icop_l.o(.text+0x2068):icop_l.cc: multiple definition of `global constructors
ke
yed to D_matrice'
test.o(.text+0x94c):test.cc: first defined here
icop_l.o(.data+0xbbc0):icop_l.cc: multiple definition of `D_nbIdent_instruction'

test.o(.data+0xd474):test.cc: first defined here
icop_l.o(.data+0xbbc4):icop_l.cc: multiple definition of `D_typeEntiteLu'
test.o(.data+0xd478):test.cc: first defined here
icop_l.o(.data+0xbbc8):icop_l.cc: multiple definition of `D_typeReseauLu'
test.o(.data+0xd47c):test.cc: first defined here
icop_l.o(.data+0xbbcc):icop_l.cc: multiple definition of `result_expr_facul'
test.o(.data+0xd480):test.cc: first defined here
icop_l.o(.data+0xbbd4):icop_l.cc: multiple definition of `reseauL'
test.o(.data+0xd488):test.cc: first defined here
icop_l.o(.data+0xbbd8):icop_l.cc: multiple definition of `module_a_sauver'
test.o(.data+0xd48c):test.cc: first defined here
demarc_y.o(.data+0x0):demarc_y.cc: multiple definition of `D_matrice'
test.o(.data+0x0):test.cc: first defined here
demarc_y.o(.data+0xc):demarc_y.cc: multiple definition of `D_idtest'
test.o(.data+0xc):test.cc: first defined here
demarc_y.o(.data+0x24):demarc_y.cc: multiple definition of `D_idtest_nondecl'
test.o(.data+0x24):test.cc: first defined here
demarc_y.o(.data+0x3c):demarc_y.cc: multiple definition of `D_idtest_num'
test.o(.data+0x3c):test.cc: first defined here
demarc_y.o(.data+0x5dfc):demarc_y.cc: multiple definition of `D_listeIdent'
test.o(.data+0x5dfc):test.cc: first defined here
demarc_y.o(.data+0xbbbc):demarc_y.cc: multiple definition of `D_nbIdent'
test.o(.data+0xbbbc):test.cc: first defined here
demarc_y.o(.data+0xbbd8):demarc_y.cc: multiple definition of `module_a_sauver'
test.o(.data+0xd48c):test.cc: first defined here
demarc_y.o(.data+0xbbd4):demarc_y.cc: multiple definition of `reseauL'
test.o(.data+0xd488):test.cc: first defined here
demarc_y.o(.data+0xbbc0):demarc_y.cc: multiple definition of `D_nbIdent_instruct
ion'
test.o(.data+0xd474):test.cc: first defined here
demarc_y.o(.data+0xbbcc):demarc_y.cc: multiple definition of `result_expr_facul'

test.o(.data+0xd480):test.cc: first defined here
demarc_y.o(.data+0xbbc4):demarc_y.cc: multiple definition of `D_typeEntiteLu'
test.o(.data+0xd478):test.cc: first defined here
demarc_y.o(.text+0x1626c):demarc_y.cc: multiple definition of `global
destructor
s keyed to D_matrice'
test.o(.text+0x6d8):test.cc: first defined here
demarc_y.o(.text+0x16448):demarc_y.cc: multiple definition of `global
constructo
rs keyed to D_matrice'
test.o(.text+0x94c):test.cc: first defined here
demarc_y.o(.data+0xbbc8):demarc_y.cc: multiple definition of `D_typeReseauLu'
test.o(.data+0xd47c):test.cc: first defined here
g++: Internal compiler error: program ld got fatal signal 1
make: *** [Paros] Error 1

    This program is succesfully linked in SOLARIS and
SGI....
    Also I would like to know if malloc.h
is available ou how can I use the malloc()?
    Can anyone help me?


                                               
Thanks a lot!



                                                                       
Berenice LOPEZ

Linking problems

[Manmathan Muthukumarapillai]

Hello,

Is it not possible to do relocation linking?


I tried to do:
	ld --verbose

What does this mean?


    /* Grouped section support currently must be explicitly   provided
for
        in the linker script.  */

I also tried to do:

	ld -r -X -o run.pe.o nti.o run.0 --verbose
then I got...
...
...
attempt to open nti.o succeeded
nti.o
attempt to open run.0 succeeded
C/betarun.pe
ld: C/betarun.pe: bad reloc address 0x4 in section `.text'


Why do I get this message??

Please help!!


-- 
+++++++++++++++++++++++++++++++++++++++++
 Manmathan Kumar, Spobjergvej 149, nr. 4
 DK-8220 Brabrand, Denmark.
 Tel.: (+45) 89449509

 Email: mannan@daimi.aau.dk
 WWW  : http://www.daimi.aau.dk/~mannan/
+++++++++++++++++++++++++++++++++++++++++
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".