OSDev.org

Hi
I have a elf386 gcc in cygwin(not cygwin built-int gcc). I have an error while compile, please help



thanks
from Peter ([email protected])

mcheung63 wrote:I have a elf386 gcc in cygwin(not cygwin built-int gcc)

No you haven't, or at least, you are not using it.

Hmmm... I remember having a similar problem... will look it up, stand by.

Can't really point a finger at it, but it has something to do with the order of the options on the command line. Try shuffling around the input file, -lmean, and the -o dynamically_linked. And yes, Cygwin GCC is (for some reason) touchy about this.

Hi,

I had a similar problem a while ago with ld. This was resolved by using the --start-group and --end-group flags around the library options. I realise that this is only meant to make LD search libraries multiple times (and can therefore slow linking), but it fixed a very similar problem to yours. It may simply be that this rearranged the command line options in to a way that the linker liked (as per Solar's suggestion).

This may not be relevant because you are getting gcc to link for you and I'm unsure if it accepts these parameters, but just in case...

Cheers,
Adam

I found it again. The error message was a different one, but here's the story (for completeness' sake):

It was a prototype app I wrote that used libcrypto (from the OpenSSL package). This line:
Worked beautifully under Linux, gave a bunch of undefined references on Cygwin.
Worked under both Linux and Cygwin.

That's why I remembered "Cygwin GCC is touchy about parameter ordering". As I said, not quite like your case, but perhaps reordering helps you, too.

uhm, I don't see undefined references, in the screenshot it claims it can't find the library itself...

I know; but my case makes me suspect that shuffling around the command line parameters might actually help in this case too.

My guess is that there is no libmean.a in the standard library directories.

Hobbes wrote:My guess is that there is no libmean.a in the standard library directories.

mcheung63 wrote:-L.

I don't think the location of -o should matter, as I never knowingly had problems with that. The rest is in the expected order so...

What concerns me more is that he is using cygwin's gcc, thinking it's a elf crosscompiler, and then trying to link .so's with it, which is definately not what it was intended to do...:

not cygwin built-int gcc
(...)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld

You see the contradiction?

Combuster wrote:I don't think the location of -o should matter, as I never knowingly had problems with that. The rest is in the expected order so...

That's why I mentioned that instance where options in the expected order didn't work for me on Cygwin once before.

You see the contradiction?

I see it, but that shouldn't matter either. The linker can't see libmean.a...

Wait. You're right, of course!

Cygwin 'ld' links against .a files, which provide the "handles" for DLLs if necessary. In any case, the Cygwin 'ld' (which you are using) doesn't know about .so files AFAIK.

Yes, libmean.so is not libmean.a.

If I have libmean.a , the -lmean work
i found that I can compile my file like this in cygwin

gcc mysource.c libmean.so