Re: Libraries not working

Re: Libraries not working

[John Garrison]

What I am creating is a game programming library. I am using the low
level library called SDL. SDL has a demo lib that
loads in images, that lib is call IMGLib. I have compiled IMGLib using
the Makefile provided and the cross-compiler. It
compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
implemented in IMG.c) So I have a compiled library
which had IMG_Load_RW defined and implemented. I installed the IMGLib
library in my cross-compiler's paths (include and
lib)
When I compile my library (which includes code from IMGLib) It compiles
and links fine under the cross-compiler. However,
if I try to build the IMGLib example directly with IMGLib, or one of my
libs examples, which would use IMGLib indirectly,
it brings the error 'undefined reference to IMG_Load_RW'  I have
included IMG.h, which declares IMG_Load_RW and I have
included -lIMG which is the libIMG.a file that implements IMG_Load_RW.
As I said everything compiles fine under GCC and IMG_Load_RW being the
only function from IMGLib it can't find confuses me,
if it were a linker error then it would complain about all of the
functions being passed from IMGLib wouldn't it?
Although the problem only exists when trying to compile a binary, so it
only makes since that it is in the linker, but if
it can find all the other functions why can't it find IMG_Load_RW?
I've asked Sam Lantinga (the guy that created SDL) the only suggestion
he had was that I was using an older version of his
library which I am not. (and that would make little difference anyway
because I compiled IMGLib with the same libSDL.a as I
am trying to compile and link my examples with) Yes I am using a windows
version of SDL.
What really baffles me is that even the Makefile for the show.c IMGLib
examples gives the error, if I were leaving out
something it would make since, but the Makefile wouldn't leave something
out.
And yes I am also included -lSDL because other parts of the program need
it.
The language is C by the way.
Here is the gcc command I am giving (actually I am using a Makefile, but
here is the result of what make is giving)

(CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf
-I/usr/win32/include

I have tried changing the position of -lIMG to the middle and the back I
have try putting -I before the -l's and after the
-l's, I just can't figure out why it would work fine on Linux GCC and
not Win32 GCC.
Is this enough info? I am trying to keep it relatively short.



Mumit Khan wrote:

> On Mon, 5 Jul 1999, John Garrison wrote:
>
> >
> > I am sorry about responding to your help via personal email, the
other
> > lists I have been on sent the message to the list when you reply.
Maybe
> > you emailed to me instead of the list and I didn't bother to look,
> > sorry. Anyhow here is my reply to those in the list who might be
able to
> >
> > help.  By the way I am using a Linux version of the compiler, but it
is
> > a cross-compiler so It outputs Windows executables.
> >
> > > > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > > > `IMG_Load_RW'
> > > >
> >
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):

> >
> > > > undefined reference to `WinMain@16'
> > > > collect2: ld returned 1 exit status
> > > >
> > > > IMG_Load_RW is clearly defined in IMG.h which is included in the

> > show.c
> > > > source code.
> > >
> > > I guess that it is only declared, not defined
> > >
> >
> > IMG_Load_RW is a function, it can't help but be defined. Well, I
guess
> > it is possible to not define a function, but this is
> > is defined. Besides it compiles fine for Linux.
>
> This is your second post, but still no details. Without any details on

> what you're doing, how you're linking, what options you're passing to
GCC
> and the linker, what files are being linked in, what language (C,
C++),
> how are we supposed to know what's wrong???
>
> > >
> > > > Also I have a main function and the FAQ says that if you
> > > > get the undefined reference to `WinMain@16' to include a blank
main
> > > > statement, well, I am not building a library I already HAVE a
main
> > > > statement.
> > >
> > > One solution: link with WinMain.o
> > > The other was explained by Mumit Khan in a posting May 13
> > >
>
> This is incorrect. There is no WinMain.o.
>
> >
> > WinMain.o?  Is that part of the distribution or do I have to create
an
> > empty WinMain()  source file? By the way, does anybody know why
Windows
> > decided to completely screw up portabilty with this WinMain function
in
> > the first place? What is wrong with the main() statement we have
been
> > using since like 1972 when the language was invented?
>
> WinMain() becomes the "entry" for GUI executables in Windows. As for
how
> the language has been changed under you on Windows, feel free to ask
> Microsoft ;-) Of course, I hope folks have switched from the language
> from 1972 to a much newer ANSI C, and soon to be C9x!
>
> Regards,
> Mumit
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com




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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> What I am creating is a game programming library. I am using the low
> level library called SDL. SDL has a demo lib that
> loads in images, that lib is call IMGLib. I have compiled IMGLib using
> the Makefile provided and the cross-compiler. 

I'm with you so far. We have two libraries -- SDL and IMGLib. We have to
of course keep in mind the dependencies when linking against these two
libraries. Remember that Unix linkers are single pass (uni-directional),
and processes left-to-right. There are times it's necessary to supply
the same library multiple times on the link command line to resolve
inter-dependencies between archives (it usually points to bad design
decision, but that's not relevant here).

> It
> compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
> implemented in IMG.c) So I have a compiled library
> which had IMG_Load_RW defined and implemented. I installed the IMGLib
> library in my cross-compiler's paths (include and
> lib)
> When I compile my library (which includes code from IMGLib) It compiles
> and links fine under the cross-compiler. 

Sidebar: in the C language, `defined' has a very specific meaning; 
functions and variables are declared and defined, not defined and 
implemented. C++ added a few more tweaks to this to handle the case
of template instantiations, but still essentially the same. I was
confused when I saw your message the first about a function being 
defined in the header file (which can happen, but not very usual).

How can you "link" a library? I'm assuming you mean that you could build
the archive libIMG.a correctly.
  
  $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW

(or, i386-mingw32-nm if you're using Mingw cross-compiler).

shows what?

> However,
> if I try to build the IMGLib example directly with IMGLib, or one of my
> libs examples, which would use IMGLib indirectly,
> it brings the error 'undefined reference to IMG_Load_RW'  I have
> included IMG.h, which declares IMG_Load_RW and I have
> included -lIMG which is the libIMG.a file that implements IMG_Load_RW.
> As I said everything compiles fine under GCC and IMG_Load_RW being the
> only function from IMGLib it can't find confuses me,
> if it were a linker error then it would complain about all of the
> functions being passed from IMGLib wouldn't it?
> Although the problem only exists when trying to compile a binary, so it
> only makes since that it is in the linker, but if
> it can find all the other functions why can't it find IMG_Load_RW?
> I've asked Sam Lantinga (the guy that created SDL) the only suggestion
> he had was that I was using an older version of his
> library which I am not. (and that would make little difference anyway
> because I compiled IMGLib with the same libSDL.a as I
> am trying to compile and link my examples with) Yes I am using a windows
> version of SDL.
> What really baffles me is that even the Makefile for the show.c IMGLib
> examples gives the error, if I were leaving out
> something it would make since, but the Makefile wouldn't leave something
> out.
> And yes I am also included -lSDL because other parts of the program need
> it.
> The language is C by the way.
> Here is the gcc command I am giving (actually I am using a Makefile, but
> here is the result of what make is giving)
> 
> (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -I/usr/win32/include

Have you tried:

(CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]?

Where is the module that gets the undefined reference? In ex1.c, libPD.a,
libSDL.a or libttf.a? That is a crucial piece of information.

> 
> I have tried changing the position of -lIMG to the middle and the back I
> have try putting -I before the -l's and after the
> -l's, I just can't figure out why it would work fine on Linux GCC and
> not Win32 GCC.

Because Linux and Windows32 are two different OSs, use different shared
library mechanisms, and there are bugs in GCC/binutils on both (albeit
more under Windows32 than on Linux) ... Impossible to guess from the 
information at hand; however, if you're building shared libraries for 
Linux, then it makes perfect sense since ELF shared libraries don't 
need to have all symbols resolved at link time.

> Is this enough info? I am trying to keep it relatively short.

More is always better than not enough in my book.

At this point, without taking a look at the code and the way it's being 
built, I'm afraid I can't be of any more help.

Regards,
Mumit


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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

>
> I'm with you so far. We have two libraries -- SDL and IMGLib. We have to
> of course keep in mind the dependencies when linking against these two
> libraries. Remember that Unix linkers are single pass (uni-directional),
> and processes left-to-right. There are times it's necessary to supply
> the same library multiple times on the link command line to resolve
> inter-dependencies between archives (it usually points to bad design
> decision, but that's not relevant here).
>
> > It
> > compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
> > implemented in IMG.c) So I have a compiled library
> > which had IMG_Load_RW defined and implemented. I installed the IMGLib
> > library in my cross-compiler's paths (include and
> > lib)
> > When I compile my library (which includes code from IMGLib) It compiles
> > and links fine under the cross-compiler.
>
> Sidebar: in the C language, `defined' has a very specific meaning;
> functions and variables are declared and defined, not defined and
> implemented. C++ added a few more tweaks to this to handle the case
> of template instantiations, but still essentially the same. I was
> confused when I saw your message the first about a function being
> defined in the header file (which can happen, but not very usual).
>
> How can you "link" a library? I'm assuming you mean that you could build
> the archive libIMG.a correctly.
>

You're right that was a typo, as you read earlier I said it could be a linker
problem becuase it only happens when building executables :)

>
>   $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW
>
> (or, i386-mingw32-nm if you're using Mingw cross-compiler).
>
> shows what?
>

[bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
./i586-mingw32-nm: IMG.c: File format not recognized
./i586-mingw32-nm: IMG_tif.c: File format not recognized
./i586-mingw32-nm: IMG_xxx.c: File format not recognized
./i586-mingw32-nm: IMG_bmp.c: File format not recognized

What does it mean file format not recognized? it's  C code, compiled for windows
with mingw32. I would say maybe there were some Linux object files in the
directory that wouldn't have gotten recompiled, but that isn't likely, it would
be all the objects or nothing, make clean wipes out all .o files and make
creates all .o files.

> Have you tried:
>
> (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]?
>

Yes I have, makes no difference.

>
> Where is the module that gets the undefined reference? In ex1.c, libPD.a,
> libSDL.a or libttf.a? That is a crucial piece of information.
>

When compiling ex1.c as the above example shows the problem is in libPD.a
When compiling show.c (the example for IMGLib) the problem is in show.c


>
> >
> > I have tried changing the position of -lIMG to the middle and the back I
> > have try putting -I before the -l's and after the
> > -l's, I just can't figure out why it would work fine on Linux GCC and
> > not Win32 GCC.
>
> Because Linux and Windows32 are two different OSs, use different shared
> library mechanisms, and there are bugs in GCC/binutils on both (albeit
> more under Windows32 than on Linux) ... Impossible to guess from the
> information at hand; however, if you're building shared libraries for
> Linux, then it makes perfect sense since ELF shared libraries don't
> need to have all symbols resolved at link time.
>
> > Is this enough info? I am trying to keep it relatively short.
>
> More is always better than not enough in my book.
>
> At this point, without taking a look at the code and the way it's being
> built, I'm afraid I can't be of any more help.
>

I have no problem sending code, but I'd need to know how much of it you'd need
to see. The problem is with IMGLib so I could send that directory tree, or
I could just send show.c and the command I'm using to compile it.

>
> Regards,
> Mumit


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> >
> >   $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW
> >
> > (or, i386-mingw32-nm if you're using Mingw cross-compiler).
> >
> > shows what?
> >
> 
> [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> ./i586-mingw32-nm: IMG.c: File format not recognized
> ./i586-mingw32-nm: IMG_tif.c: File format not recognized
> ./i586-mingw32-nm: IMG_xxx.c: File format not recognized
> ./i586-mingw32-nm: IMG_bmp.c: File format not recognized
> 
> What does it mean file format not recognized? it's  C code, compiled for wind
> ows
> with mingw32. I would say maybe there were some Linux object files in the
> directory that wouldn't have gotten recompiled, but that isn't likely, it wou
> ld
> be all the objects or nothing, make clean wipes out all .o files and make
> creates all .o files.

That means that libIMG.a was NOT compiled for windows32 target, but 
possibly for your host (``nm libIMG.a'' then would show the symbols 
instead).

libIMG.a cannot be a host library, but rather has to be a target 
library. Until that is fixed, nothing else will work. Same goes for 
*all* the object files and archives on the command line you're using.

Make sure you're using the cross-compiler to build the libIMG.a, and
make sure the cross-compiler is using the cross assembler, and that
you're using cross-tools (ix86-mingw32-ar, ix86-mingw32-ranlib) to
build the archive. This is fundamental to building anything in a
cross-development environment.

Regards,
Mumit


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> What I am creating is a game programming library. I am using the low
> level library called SDL. SDL has a demo lib that
> loads in images, that lib is call IMGLib. I have compiled IMGLib using
> the Makefile provided and the cross-compiler. 

I'm with you so far. We have two libraries -- SDL and IMGLib. We have to
of course keep in mind the dependencies when linking against these two
libraries. Remember that Unix linkers are single pass (uni-directional),
and processes left-to-right. There are times it's necessary to supply
the same library multiple times on the link command line to resolve
inter-dependencies between archives (it usually points to bad design
decision, but that's not relevant here).

> It
> compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
> implemented in IMG.c) So I have a compiled library
> which had IMG_Load_RW defined and implemented. I installed the IMGLib
> library in my cross-compiler's paths (include and
> lib)
> When I compile my library (which includes code from IMGLib) It compiles
> and links fine under the cross-compiler. 

Sidebar: in the C language, `defined' has a very specific meaning; 
functions and variables are declared and defined, not defined and 
implemented. C++ added a few more tweaks to this to handle the case
of template instantiations, but still essentially the same. I was
confused when I saw your message the first about a function being 
defined in the header file (which can happen, but not very usual).

How can you "link" a library? I'm assuming you mean that you could build
the archive libIMG.a correctly.
  
  $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW

(or, i386-mingw32-nm if you're using Mingw cross-compiler).

shows what?

> However,
> if I try to build the IMGLib example directly with IMGLib, or one of my
> libs examples, which would use IMGLib indirectly,
> it brings the error 'undefined reference to IMG_Load_RW'  I have
> included IMG.h, which declares IMG_Load_RW and I have
> included -lIMG which is the libIMG.a file that implements IMG_Load_RW.
> As I said everything compiles fine under GCC and IMG_Load_RW being the
> only function from IMGLib it can't find confuses me,
> if it were a linker error then it would complain about all of the
> functions being passed from IMGLib wouldn't it?
> Although the problem only exists when trying to compile a binary, so it
> only makes since that it is in the linker, but if
> it can find all the other functions why can't it find IMG_Load_RW?
> I've asked Sam Lantinga (the guy that created SDL) the only suggestion
> he had was that I was using an older version of his
> library which I am not. (and that would make little difference anyway
> because I compiled IMGLib with the same libSDL.a as I
> am trying to compile and link my examples with) Yes I am using a windows
> version of SDL.
> What really baffles me is that even the Makefile for the show.c IMGLib
> examples gives the error, if I were leaving out
> something it would make since, but the Makefile wouldn't leave something
> out.
> And yes I am also included -lSDL because other parts of the program need
> it.
> The language is C by the way.
> Here is the gcc command I am giving (actually I am using a Makefile, but
> here is the result of what make is giving)
> 
> (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -I/usr/win32/include

Have you tried:

(CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]?

Where is the module that gets the undefined reference? In ex1.c, libPD.a,
libSDL.a or libttf.a? That is a crucial piece of information.

> 
> I have tried changing the position of -lIMG to the middle and the back I
> have try putting -I before the -l's and after the
> -l's, I just can't figure out why it would work fine on Linux GCC and
> not Win32 GCC.

Because Linux and Windows32 are two different OSs, use different shared
library mechanisms, and there are bugs in GCC/binutils on both (albeit
more under Windows32 than on Linux) ... Impossible to guess from the 
information at hand; however, if you're building shared libraries for 
Linux, then it makes perfect sense since ELF shared libraries don't 
need to have all symbols resolved at link time.

> Is this enough info? I am trying to keep it relatively short.

More is always better than not enough in my book.

At this point, without taking a look at the code and the way it's being 
built, I'm afraid I can't be of any more help.

Regards,
Mumit


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> >
> >   $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW
> >
> > (or, i386-mingw32-nm if you're using Mingw cross-compiler).
> >
> > shows what?
> >
> 
> [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> ./i586-mingw32-nm: IMG.c: File format not recognized
> ./i586-mingw32-nm: IMG_tif.c: File format not recognized
> ./i586-mingw32-nm: IMG_xxx.c: File format not recognized
> ./i586-mingw32-nm: IMG_bmp.c: File format not recognized
> 
> What does it mean file format not recognized? it's  C code, compiled for wind
> ows
> with mingw32. I would say maybe there were some Linux object files in the
> directory that wouldn't have gotten recompiled, but that isn't likely, it wou
> ld
> be all the objects or nothing, make clean wipes out all .o files and make
> creates all .o files.

That means that libIMG.a was NOT compiled for windows32 target, but 
possibly for your host (``nm libIMG.a'' then would show the symbols 
instead).

libIMG.a cannot be a host library, but rather has to be a target 
library. Until that is fixed, nothing else will work. Same goes for 
*all* the object files and archives on the command line you're using.

Make sure you're using the cross-compiler to build the libIMG.a, and
make sure the cross-compiler is using the cross assembler, and that
you're using cross-tools (ix86-mingw32-ar, ix86-mingw32-ranlib) to
build the archive. This is fundamental to building anything in a
cross-development environment.

Regards,
Mumit


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

Re: Libraries not working

[John Garrison]

What I am creating is a game programming library. I am using the low
level library called SDL. SDL has a demo lib that
loads in images, that lib is call IMGLib. I have compiled IMGLib using
the Makefile provided and the cross-compiler. It
compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
implemented in IMG.c) So I have a compiled library
which had IMG_Load_RW defined and implemented. I installed the IMGLib
library in my cross-compiler's paths (include and
lib)
When I compile my library (which includes code from IMGLib) It compiles
and links fine under the cross-compiler. However,
if I try to build the IMGLib example directly with IMGLib, or one of my
libs examples, which would use IMGLib indirectly,
it brings the error 'undefined reference to IMG_Load_RW'  I have
included IMG.h, which declares IMG_Load_RW and I have
included -lIMG which is the libIMG.a file that implements IMG_Load_RW.
As I said everything compiles fine under GCC and IMG_Load_RW being the
only function from IMGLib it can't find confuses me,
if it were a linker error then it would complain about all of the
functions being passed from IMGLib wouldn't it?
Although the problem only exists when trying to compile a binary, so it
only makes since that it is in the linker, but if
it can find all the other functions why can't it find IMG_Load_RW?
I've asked Sam Lantinga (the guy that created SDL) the only suggestion
he had was that I was using an older version of his
library which I am not. (and that would make little difference anyway
because I compiled IMGLib with the same libSDL.a as I
am trying to compile and link my examples with) Yes I am using a windows
version of SDL.
What really baffles me is that even the Makefile for the show.c IMGLib
examples gives the error, if I were leaving out
something it would make since, but the Makefile wouldn't leave something
out.
And yes I am also included -lSDL because other parts of the program need
it.
The language is C by the way.
Here is the gcc command I am giving (actually I am using a Makefile, but
here is the result of what make is giving)

(CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf
-I/usr/win32/include

I have tried changing the position of -lIMG to the middle and the back I
have try putting -I before the -l's and after the
-l's, I just can't figure out why it would work fine on Linux GCC and
not Win32 GCC.
Is this enough info? I am trying to keep it relatively short.



Mumit Khan wrote:

> On Mon, 5 Jul 1999, John Garrison wrote:
>
> >
> > I am sorry about responding to your help via personal email, the
other
> > lists I have been on sent the message to the list when you reply.
Maybe
> > you emailed to me instead of the list and I didn't bother to look,
> > sorry. Anyhow here is my reply to those in the list who might be
able to
> >
> > help.  By the way I am using a Linux version of the compiler, but it
is
> > a cross-compiler so It outputs Windows executables.
> >
> > > > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > > > `IMG_Load_RW'
> > > >
> >
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):

> >
> > > > undefined reference to `WinMain@16'
> > > > collect2: ld returned 1 exit status
> > > >
> > > > IMG_Load_RW is clearly defined in IMG.h which is included in the

> > show.c
> > > > source code.
> > >
> > > I guess that it is only declared, not defined
> > >
> >
> > IMG_Load_RW is a function, it can't help but be defined. Well, I
guess
> > it is possible to not define a function, but this is
> > is defined. Besides it compiles fine for Linux.
>
> This is your second post, but still no details. Without any details on

> what you're doing, how you're linking, what options you're passing to
GCC
> and the linker, what files are being linked in, what language (C,
C++),
> how are we supposed to know what's wrong???
>
> > >
> > > > Also I have a main function and the FAQ says that if you
> > > > get the undefined reference to `WinMain@16' to include a blank
main
> > > > statement, well, I am not building a library I already HAVE a
main
> > > > statement.
> > >
> > > One solution: link with WinMain.o
> > > The other was explained by Mumit Khan in a posting May 13
> > >
>
> This is incorrect. There is no WinMain.o.
>
> >
> > WinMain.o?  Is that part of the distribution or do I have to create
an
> > empty WinMain()  source file? By the way, does anybody know why
Windows
> > decided to completely screw up portabilty with this WinMain function
in
> > the first place? What is wrong with the main() statement we have
been
> > using since like 1972 when the language was invented?
>
> WinMain() becomes the "entry" for GUI executables in Windows. As for
how
> the language has been changed under you on Windows, feel free to ask
> Microsoft ;-) Of course, I hope folks have switched from the language
> from 1972 to a much newer ANSI C, and soon to be C9x!
>
> Regards,
> Mumit
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com




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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

>
> I'm with you so far. We have two libraries -- SDL and IMGLib. We have to
> of course keep in mind the dependencies when linking against these two
> libraries. Remember that Unix linkers are single pass (uni-directional),
> and processes left-to-right. There are times it's necessary to supply
> the same library multiple times on the link command line to resolve
> inter-dependencies between archives (it usually points to bad design
> decision, but that's not relevant here).
>
> > It
> > compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is
> > implemented in IMG.c) So I have a compiled library
> > which had IMG_Load_RW defined and implemented. I installed the IMGLib
> > library in my cross-compiler's paths (include and
> > lib)
> > When I compile my library (which includes code from IMGLib) It compiles
> > and links fine under the cross-compiler.
>
> Sidebar: in the C language, `defined' has a very specific meaning;
> functions and variables are declared and defined, not defined and
> implemented. C++ added a few more tweaks to this to handle the case
> of template instantiations, but still essentially the same. I was
> confused when I saw your message the first about a function being
> defined in the header file (which can happen, but not very usual).
>
> How can you "link" a library? I'm assuming you mean that you could build
> the archive libIMG.a correctly.
>

You're right that was a typo, as you read earlier I said it could be a linker
problem becuase it only happens when building executables :)

>
>   $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW
>
> (or, i386-mingw32-nm if you're using Mingw cross-compiler).
>
> shows what?
>

[bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
./i586-mingw32-nm: IMG.c: File format not recognized
./i586-mingw32-nm: IMG_tif.c: File format not recognized
./i586-mingw32-nm: IMG_xxx.c: File format not recognized
./i586-mingw32-nm: IMG_bmp.c: File format not recognized

What does it mean file format not recognized? it's  C code, compiled for windows
with mingw32. I would say maybe there were some Linux object files in the
directory that wouldn't have gotten recompiled, but that isn't likely, it would
be all the objects or nothing, make clean wipes out all .o files and make
creates all .o files.

> Have you tried:
>
> (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]?
>

Yes I have, makes no difference.

>
> Where is the module that gets the undefined reference? In ex1.c, libPD.a,
> libSDL.a or libttf.a? That is a crucial piece of information.
>

When compiling ex1.c as the above example shows the problem is in libPD.a
When compiling show.c (the example for IMGLib) the problem is in show.c


>
> >
> > I have tried changing the position of -lIMG to the middle and the back I
> > have try putting -I before the -l's and after the
> > -l's, I just can't figure out why it would work fine on Linux GCC and
> > not Win32 GCC.
>
> Because Linux and Windows32 are two different OSs, use different shared
> library mechanisms, and there are bugs in GCC/binutils on both (albeit
> more under Windows32 than on Linux) ... Impossible to guess from the
> information at hand; however, if you're building shared libraries for
> Linux, then it makes perfect sense since ELF shared libraries don't
> need to have all symbols resolved at link time.
>
> > Is this enough info? I am trying to keep it relatively short.
>
> More is always better than not enough in my book.
>
> At this point, without taking a look at the code and the way it's being
> built, I'm afraid I can't be of any more help.
>

I have no problem sending code, but I'd need to know how much of it you'd need
to see. The problem is with IMGLib so I could send that directory tree, or
I could just send show.c and the command I'm using to compile it.

>
> Regards,
> Mumit


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

Re: Libraries not working

[tjoen]

> tjoen@dds.nl writes:
> > 
> > I guess that it is only declared, not defined
> > 
> > > Also I have a main function and the FAQ says that if you
> > > get the undefined reference to `WinMain@16' to include a blank main
> > > statement, well, I am not building a library I already HAVE a main
> > > statement.
> > 
> > One solution: link with WinMain.o
> > The other was explained by Mumit Khan in a posting May 13
> 
> I believe you're referring to the problem that shows up when linking V 
> GUI examples, which puts WinMain in a library. The solution there is to
> use -Wl,-u,_WinMain@16 when linking (in addition to -mwindows).

Yes, just reread that when the problem came along

> I don't have enough information on this particular problem to be able
> to comment. 

That is true. By private e-mail the original poster came with
new details. I was on the wrong track.
I replied to post the problem more clearly on the list.


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

Re: Libraries not working

[DJ Delorie]

> [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> ./i586-mingw32-nm: IMG.c: File format not recognized

One thing to note - you should put *.o in the archives, not *.c

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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

> DJ Delorie <dj@delorie.com> writes:
> >
> > > [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> > > ./i586-mingw32-nm: IMG.c: File format not recognized
> >
> > One thing to note - you should put *.o in the archives, not *.c
>
> Duh, thanks. My brain automatically translated that to .o when I saw
> the .c. That obviously changes everything.
>
> Regards,
> Mumit

Yeah, i feel dumb now :) I had just copy and pasted the c filenames
directory listing into the Makefile. I changed what I thought to be all of
them over to .o.  .c looks alot like .o with the wrong font. Especially
since like Mumit says your brain just automatically translates it to what
it is supposed to be.

Now if I could just find out how to make WinMain be declared without
breaking compatibility with other platforms.  Can I just do somthing like
the following?

WinMain(void)
{
main();
}

I know nothing about windows programming so if this is a stupid question I
apologize.


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> Mumit Khan wrote:
> 
> i586-mingw32-nm didn't show anything at all. But here is the source code belo
> w
> and the command I use to compile it below that.  Note I have to use main()
> instead of int main(), it has something to do with SDL. SDL will complain if
> I use anything else.
> 
> #include "PowerPak/powerdraw.h"
> 
> main(int argc, char *argv[])
> {
>    /* Initialize the library */
>    PD_Init();
> 
>    /* Initialize 640x480x16bpp graphics mode */
>    PD_SetGFXMode(640, 480, 16, PD_DEFAULT);
> 
>    /* Draw a little cylindrical thingie */
>    PD_Ellipse(Screen, 320, 100, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 220, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 220, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 380, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_VLine(Screen, 100, 220, 220, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 100, 220, 420, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 220, 380, 270, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 220, 380, 370, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
> 
>    /* Wait for 5 seconds so you can see it */
>    PD_Wait(5000);
> 
>    /* Cleanup */
>    PD_Quit();
> }
> 
> and here is the command to gcc.
> 
>  /usr/win32/bin/i586-mingw32-gcc ex1.c -lPD -lSDL -lttf -lIMG
> -I/usr/win32/include
> 

I really don't know what's going on, and my time is rather limited. If
you can get me the sources, I'll take a look.

Regards,
Mumit


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

Re: Libraries not working

[Mumit Khan]

tjoen@dds.nl writes:
> > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > `IMG_Load_RW'
> > /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mi
> ngw32/lib/libmingw32.a(main.o)(.text+0x7b):
> > undefined reference to `WinMain@16'
> > collect2: ld returned 1 exit status
> > 
> > IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
> > source code.
> 
> I guess that it is only declared, not defined
> 
> > Also I have a main function and the FAQ says that if you
> > get the undefined reference to `WinMain@16' to include a blank main
> > statement, well, I am not building a library I already HAVE a main
> > statement.
> 
> One solution: link with WinMain.o
> The other was explained by Mumit Khan in a posting May 13

I believe you're referring to the problem that shows up when linking V 
GUI examples, which puts WinMain in a library. The solution there is to
use -Wl,-u,_WinMain@16 when linking (in addition to -mwindows).

I don't have enough information on this particular problem to be able
to comment. 

Regards,
Mumit


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

Libraries not working

[John Garrison]

I have just created a library using ar. I have a program that links to
the library, and have the header file included in the code. Everything
is setup properly ( I know because it compiles fine with gcc) I am using
the cross compiler on Linux version by the way.

The problem is after I try to compile the program I get a:

/tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
`IMG_Load_RW'
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
undefined reference to `WinMain@16'
collect2: ld returned 1 exit status

IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
source code. Also I have a main function and the FAQ says that if you
get the undefined reference to `WinMain@16' to include a blank main
statement, well, I am not building a library I already HAVE a main
statement.

Any ideas why it would complain about not having two things that it does
have?


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

Re: Libraries not working

[tjoen]

> /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> `IMG_Load_RW'
> /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
> undefined reference to `WinMain@16'
> collect2: ld returned 1 exit status
> 
> IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
> source code.

I guess that it is only declared, not defined

> Also I have a main function and the FAQ says that if you
> get the undefined reference to `WinMain@16' to include a blank main
> statement, well, I am not building a library I already HAVE a main
> statement.

One solution: link with WinMain.o
The other was explained by Mumit Khan in a posting May 13


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> 
> Now if I could just find out how to make WinMain be declared without
> breaking compatibility with other platforms.  Can I just do somthing like
> the following?
> 
> WinMain(void)
> {
> main();
> }
> 

You shouldn't need to do anything at all. If this is a windows32 GUI
program, add -mwindows when linking the program; if this is a console
mode (the usual Unix kind), then the linker should pick up main from
one of the object files where main is defined.

If it is console mode, then is main() defined in one of the object
modules? 

  $ i586-mingw32-nm --print-file-name *.o | grep main

do you see a defined symbol for main (there is a ' T ' before the
symbol name if defined).

If main() is in an archive instead, try the following:
  
  $ i586-mingw32-gcc -o foo -Wl,-u,_main [rest of arguments]

and see if that helps.

Regards,
Mumit


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

Re: Libraries not working

[John Garrison]

I am sorry about responding to your help via personal email, the other
lists I have been on sent the message to the list when you reply. Maybe
you emailed to me instead of the list and I didn't bother to look,
sorry. Anyhow here is my reply to those in the list who might be able to

help.  By the way I am using a Linux version of the compiler, but it is
a cross-compiler so It outputs Windows executables.

> > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > `IMG_Load_RW'
> >
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):

> > undefined reference to `WinMain@16'
> > collect2: ld returned 1 exit status
> >
> > IMG_Load_RW is clearly defined in IMG.h which is included in the
show.c
> > source code.
>
> I guess that it is only declared, not defined
>

IMG_Load_RW is a function, it can't help but be defined. Well, I guess
it is possible to not define a function, but this is
is defined. Besides it compiles fine for Linux.

>
> > Also I have a main function and the FAQ says that if you
> > get the undefined reference to `WinMain@16' to include a blank main
> > statement, well, I am not building a library I already HAVE a main
> > statement.
>
> One solution: link with WinMain.o
> The other was explained by Mumit Khan in a posting May 13
>

WinMain.o?  Is that part of the distribution or do I have to create an
empty WinMain()  source file? By the way, does anybody know why Windows
decided to completely screw up portabilty with this WinMain function in
the first place? What is wrong with the main() statement we have been
using since like 1972 when the language was invented?


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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

> John Garrison <jeg@visi.net> writes:
> >
> > Now if I could just find out how to make WinMain be declared without
> > breaking compatibility with other platforms.  Can I just do somthing like
> > the following?
> >
> > WinMain(void)
> > {
> > main();
> > }
> >
>
> You shouldn't need to do anything at all. If this is a windows32 GUI
> program, add -mwindows when linking the program; if this is a console
> mode (the usual Unix kind), then the linker should pick up main from
> one of the object files where main is defined.
>
> If it is console mode, then is main() defined in one of the object
> modules?
>
>   $ i586-mingw32-nm --print-file-name *.o | grep main
>
> do you see a defined symbol for main (there is a ' T ' before the
> symbol name if defined).
>
> If main() is in an archive instead, try the following:
>
>   $ i586-mingw32-gcc -o foo -Wl,-u,_main [rest of arguments]
>
> and see if that helps.
>
> Regards,
> Mumit

i586-mingw32-nm didn't show anything at all. But here is the source code below
and the command I use to compile it below that.  Note I have to use main()
instead of int main(), it has something to do with SDL. SDL will complain if
I use anything else.

#include "PowerPak/powerdraw.h"

main(int argc, char *argv[])
{
   /* Initialize the library */
   PD_Init();

   /* Initialize 640x480x16bpp graphics mode */
   PD_SetGFXMode(640, 480, 16, PD_DEFAULT);

   /* Draw a little cylindrical thingie */
   PD_Ellipse(Screen, 320, 100, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 220, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 220, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 380, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_VLine(Screen, 100, 220, 220, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 100, 220, 420, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 220, 380, 270, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 220, 380, 370, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));

   /* Wait for 5 seconds so you can see it */
   PD_Wait(5000);

   /* Cleanup */
   PD_Quit();
}

and here is the command to gcc.

 /usr/win32/bin/i586-mingw32-gcc ex1.c -lPD -lSDL -lttf -lIMG
-I/usr/win32/include


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

Re: Libraries not working

[Mumit Khan]

On Mon, 5 Jul 1999, John Garrison wrote:

> 
> I am sorry about responding to your help via personal email, the other
> lists I have been on sent the message to the list when you reply. Maybe
> you emailed to me instead of the list and I didn't bother to look,
> sorry. Anyhow here is my reply to those in the list who might be able to
> 
> help.  By the way I am using a Linux version of the compiler, but it is
> a cross-compiler so It outputs Windows executables.
> 
> > > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > > `IMG_Load_RW'
> > >
> /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
> 
> > > undefined reference to `WinMain@16'
> > > collect2: ld returned 1 exit status
> > >
> > > IMG_Load_RW is clearly defined in IMG.h which is included in the
> show.c
> > > source code.
> >
> > I guess that it is only declared, not defined
> >
> 
> IMG_Load_RW is a function, it can't help but be defined. Well, I guess
> it is possible to not define a function, but this is
> is defined. Besides it compiles fine for Linux.

This is your second post, but still no details. Without any details on 
what you're doing, how you're linking, what options you're passing to GCC 
and the linker, what files are being linked in, what language (C, C++), 
how are we supposed to know what's wrong???

> >
> > > Also I have a main function and the FAQ says that if you
> > > get the undefined reference to `WinMain@16' to include a blank main
> > > statement, well, I am not building a library I already HAVE a main
> > > statement.
> >
> > One solution: link with WinMain.o
> > The other was explained by Mumit Khan in a posting May 13
> >

This is incorrect. There is no WinMain.o.

> 
> WinMain.o?  Is that part of the distribution or do I have to create an
> empty WinMain()  source file? By the way, does anybody know why Windows
> decided to completely screw up portabilty with this WinMain function in
> the first place? What is wrong with the main() statement we have been
> using since like 1972 when the language was invented?

WinMain() becomes the "entry" for GUI executables in Windows. As for how
the language has been changed under you on Windows, feel free to ask 
Microsoft ;-) Of course, I hope folks have switched from the language 
from 1972 to a much newer ANSI C, and soon to be C9x!

Regards,
Mumit



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

Re: Libraries not working

[Mumit Khan]

DJ Delorie <dj@delorie.com> writes:
> 
> > [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> > ./i586-mingw32-nm: IMG.c: File format not recognized
> 
> One thing to note - you should put *.o in the archives, not *.c

Duh, thanks. My brain automatically translated that to .o when I saw
the .c. That obviously changes everything.

Regards,
Mumit


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> Mumit Khan wrote:
> 
> i586-mingw32-nm didn't show anything at all. But here is the source code belo
> w
> and the command I use to compile it below that.  Note I have to use main()
> instead of int main(), it has something to do with SDL. SDL will complain if
> I use anything else.
> 
> #include "PowerPak/powerdraw.h"
> 
> main(int argc, char *argv[])
> {
>    /* Initialize the library */
>    PD_Init();
> 
>    /* Initialize 640x480x16bpp graphics mode */
>    PD_SetGFXMode(640, 480, 16, PD_DEFAULT);
> 
>    /* Draw a little cylindrical thingie */
>    PD_Ellipse(Screen, 320, 100, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 220, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 220, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_Ellipse(Screen, 320, 380, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
> 0x00));
>    PD_VLine(Screen, 100, 220, 220, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 100, 220, 420, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 220, 380, 270, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
>    PD_VLine(Screen, 220, 380, 370, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
> 
>    /* Wait for 5 seconds so you can see it */
>    PD_Wait(5000);
> 
>    /* Cleanup */
>    PD_Quit();
> }
> 
> and here is the command to gcc.
> 
>  /usr/win32/bin/i586-mingw32-gcc ex1.c -lPD -lSDL -lttf -lIMG
> -I/usr/win32/include
> 

I really don't know what's going on, and my time is rather limited. If
you can get me the sources, I'll take a look.

Regards,
Mumit


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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

> John Garrison <jeg@visi.net> writes:
> >
> > Now if I could just find out how to make WinMain be declared without
> > breaking compatibility with other platforms.  Can I just do somthing like
> > the following?
> >
> > WinMain(void)
> > {
> > main();
> > }
> >
>
> You shouldn't need to do anything at all. If this is a windows32 GUI
> program, add -mwindows when linking the program; if this is a console
> mode (the usual Unix kind), then the linker should pick up main from
> one of the object files where main is defined.
>
> If it is console mode, then is main() defined in one of the object
> modules?
>
>   $ i586-mingw32-nm --print-file-name *.o | grep main
>
> do you see a defined symbol for main (there is a ' T ' before the
> symbol name if defined).
>
> If main() is in an archive instead, try the following:
>
>   $ i586-mingw32-gcc -o foo -Wl,-u,_main [rest of arguments]
>
> and see if that helps.
>
> Regards,
> Mumit

i586-mingw32-nm didn't show anything at all. But here is the source code below
and the command I use to compile it below that.  Note I have to use main()
instead of int main(), it has something to do with SDL. SDL will complain if
I use anything else.

#include "PowerPak/powerdraw.h"

main(int argc, char *argv[])
{
   /* Initialize the library */
   PD_Init();

   /* Initialize 640x480x16bpp graphics mode */
   PD_SetGFXMode(640, 480, 16, PD_DEFAULT);

   /* Draw a little cylindrical thingie */
   PD_Ellipse(Screen, 320, 100, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 220, 100, 50, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 220, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_Ellipse(Screen, 320, 380, 50, 25, PD_CreateColor(Screen, 0xFF, 0x00,
0x00));
   PD_VLine(Screen, 100, 220, 220, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 100, 220, 420, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 220, 380, 270, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));
   PD_VLine(Screen, 220, 380, 370, PD_CreateColor(Screen, 0xFF, 0x00, 0x00));

   /* Wait for 5 seconds so you can see it */
   PD_Wait(5000);

   /* Cleanup */
   PD_Quit();
}

and here is the command to gcc.

 /usr/win32/bin/i586-mingw32-gcc ex1.c -lPD -lSDL -lttf -lIMG
-I/usr/win32/include


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

Re: Libraries not working

[Mumit Khan]

John Garrison <jeg@visi.net> writes:
> 
> Now if I could just find out how to make WinMain be declared without
> breaking compatibility with other platforms.  Can I just do somthing like
> the following?
> 
> WinMain(void)
> {
> main();
> }
> 

You shouldn't need to do anything at all. If this is a windows32 GUI
program, add -mwindows when linking the program; if this is a console
mode (the usual Unix kind), then the linker should pick up main from
one of the object files where main is defined.

If it is console mode, then is main() defined in one of the object
modules? 

  $ i586-mingw32-nm --print-file-name *.o | grep main

do you see a defined symbol for main (there is a ' T ' before the
symbol name if defined).

If main() is in an archive instead, try the following:
  
  $ i586-mingw32-gcc -o foo -Wl,-u,_main [rest of arguments]

and see if that helps.

Regards,
Mumit


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

Re: Libraries not working

[John Garrison]

Mumit Khan wrote:

> DJ Delorie <dj@delorie.com> writes:
> >
> > > [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> > > ./i586-mingw32-nm: IMG.c: File format not recognized
> >
> > One thing to note - you should put *.o in the archives, not *.c
>
> Duh, thanks. My brain automatically translated that to .o when I saw
> the .c. That obviously changes everything.
>
> Regards,
> Mumit

Yeah, i feel dumb now :) I had just copy and pasted the c filenames
directory listing into the Makefile. I changed what I thought to be all of
them over to .o.  .c looks alot like .o with the wrong font. Especially
since like Mumit says your brain just automatically translates it to what
it is supposed to be.

Now if I could just find out how to make WinMain be declared without
breaking compatibility with other platforms.  Can I just do somthing like
the following?

WinMain(void)
{
main();
}

I know nothing about windows programming so if this is a stupid question I
apologize.


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

Re: Libraries not working

[Mumit Khan]

DJ Delorie <dj@delorie.com> writes:
> 
> > [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> > ./i586-mingw32-nm: IMG.c: File format not recognized
> 
> One thing to note - you should put *.o in the archives, not *.c

Duh, thanks. My brain automatically translated that to .o when I saw
the .c. That obviously changes everything.

Regards,
Mumit


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

Re: Libraries not working

[DJ Delorie]

> [bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
> ./i586-mingw32-nm: IMG.c: File format not recognized

One thing to note - you should put *.o in the archives, not *.c

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

Re: Libraries not working

[Mumit Khan]

On Mon, 5 Jul 1999, John Garrison wrote:

> 
> I am sorry about responding to your help via personal email, the other
> lists I have been on sent the message to the list when you reply. Maybe
> you emailed to me instead of the list and I didn't bother to look,
> sorry. Anyhow here is my reply to those in the list who might be able to
> 
> help.  By the way I am using a Linux version of the compiler, but it is
> a cross-compiler so It outputs Windows executables.
> 
> > > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > > `IMG_Load_RW'
> > >
> /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
> 
> > > undefined reference to `WinMain@16'
> > > collect2: ld returned 1 exit status
> > >
> > > IMG_Load_RW is clearly defined in IMG.h which is included in the
> show.c
> > > source code.
> >
> > I guess that it is only declared, not defined
> >
> 
> IMG_Load_RW is a function, it can't help but be defined. Well, I guess
> it is possible to not define a function, but this is
> is defined. Besides it compiles fine for Linux.

This is your second post, but still no details. Without any details on 
what you're doing, how you're linking, what options you're passing to GCC 
and the linker, what files are being linked in, what language (C, C++), 
how are we supposed to know what's wrong???

> >
> > > Also I have a main function and the FAQ says that if you
> > > get the undefined reference to `WinMain@16' to include a blank main
> > > statement, well, I am not building a library I already HAVE a main
> > > statement.
> >
> > One solution: link with WinMain.o
> > The other was explained by Mumit Khan in a posting May 13
> >

This is incorrect. There is no WinMain.o.

> 
> WinMain.o?  Is that part of the distribution or do I have to create an
> empty WinMain()  source file? By the way, does anybody know why Windows
> decided to completely screw up portabilty with this WinMain function in
> the first place? What is wrong with the main() statement we have been
> using since like 1972 when the language was invented?

WinMain() becomes the "entry" for GUI executables in Windows. As for how
the language has been changed under you on Windows, feel free to ask 
Microsoft ;-) Of course, I hope folks have switched from the language 
from 1972 to a much newer ANSI C, and soon to be C9x!

Regards,
Mumit



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

Re: Libraries not working

[John Garrison]

I am sorry about responding to your help via personal email, the other
lists I have been on sent the message to the list when you reply. Maybe
you emailed to me instead of the list and I didn't bother to look,
sorry. Anyhow here is my reply to those in the list who might be able to

help.  By the way I am using a Linux version of the compiler, but it is
a cross-compiler so It outputs Windows executables.

> > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > `IMG_Load_RW'
> >
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):

> > undefined reference to `WinMain@16'
> > collect2: ld returned 1 exit status
> >
> > IMG_Load_RW is clearly defined in IMG.h which is included in the
show.c
> > source code.
>
> I guess that it is only declared, not defined
>

IMG_Load_RW is a function, it can't help but be defined. Well, I guess
it is possible to not define a function, but this is
is defined. Besides it compiles fine for Linux.

>
> > Also I have a main function and the FAQ says that if you
> > get the undefined reference to `WinMain@16' to include a blank main
> > statement, well, I am not building a library I already HAVE a main
> > statement.
>
> One solution: link with WinMain.o
> The other was explained by Mumit Khan in a posting May 13
>

WinMain.o?  Is that part of the distribution or do I have to create an
empty WinMain()  source file? By the way, does anybody know why Windows
decided to completely screw up portabilty with this WinMain function in
the first place? What is wrong with the main() statement we have been
using since like 1972 when the language was invented?


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

Re: Libraries not working

[tjoen]

> tjoen@dds.nl writes:
> > 
> > I guess that it is only declared, not defined
> > 
> > > Also I have a main function and the FAQ says that if you
> > > get the undefined reference to `WinMain@16' to include a blank main
> > > statement, well, I am not building a library I already HAVE a main
> > > statement.
> > 
> > One solution: link with WinMain.o
> > The other was explained by Mumit Khan in a posting May 13
> 
> I believe you're referring to the problem that shows up when linking V 
> GUI examples, which puts WinMain in a library. The solution there is to
> use -Wl,-u,_WinMain@16 when linking (in addition to -mwindows).

Yes, just reread that when the problem came along

> I don't have enough information on this particular problem to be able
> to comment. 

That is true. By private e-mail the original poster came with
new details. I was on the wrong track.
I replied to post the problem more clearly on the list.


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

Re: Libraries not working

[Mumit Khan]

tjoen@dds.nl writes:
> > /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> > `IMG_Load_RW'
> > /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mi
> ngw32/lib/libmingw32.a(main.o)(.text+0x7b):
> > undefined reference to `WinMain@16'
> > collect2: ld returned 1 exit status
> > 
> > IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
> > source code.
> 
> I guess that it is only declared, not defined
> 
> > Also I have a main function and the FAQ says that if you
> > get the undefined reference to `WinMain@16' to include a blank main
> > statement, well, I am not building a library I already HAVE a main
> > statement.
> 
> One solution: link with WinMain.o
> The other was explained by Mumit Khan in a posting May 13

I believe you're referring to the problem that shows up when linking V 
GUI examples, which puts WinMain in a library. The solution there is to
use -Wl,-u,_WinMain@16 when linking (in addition to -mwindows).

I don't have enough information on this particular problem to be able
to comment. 

Regards,
Mumit


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

Re: Libraries not working

[tjoen]

> /tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
> `IMG_Load_RW'
> /usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
> undefined reference to `WinMain@16'
> collect2: ld returned 1 exit status
> 
> IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
> source code.

I guess that it is only declared, not defined

> Also I have a main function and the FAQ says that if you
> get the undefined reference to `WinMain@16' to include a blank main
> statement, well, I am not building a library I already HAVE a main
> statement.

One solution: link with WinMain.o
The other was explained by Mumit Khan in a posting May 13


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

Libraries not working

[John Garrison]

I have just created a library using ar. I have a program that links to
the library, and have the header file included in the code. Everything
is setup properly ( I know because it compiles fine with gcc) I am using
the cross compiler on Linux version by the way.

The problem is after I try to compile the program I get a:

/tmp/cciFT7S1.o(.text+0x103):show.c: undefined reference to
`IMG_Load_RW'
/usr/win32/bin/../lib/gcc-lib/i586-mingw32/egcs-2.91.57/../../../../i586-mingw32/lib/libmingw32.a(main.o)(.text+0x7b):
undefined reference to `WinMain@16'
collect2: ld returned 1 exit status

IMG_Load_RW is clearly defined in IMG.h which is included in the show.c
source code. Also I have a main function and the FAQ says that if you
get the undefined reference to `WinMain@16' to include a blank main
statement, well, I am not building a library I already HAVE a main
statement.

Any ideas why it would complain about not having two things that it does
have?


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