.lib

[asit]

I am gooc in C and can handle thread, socket programming.
My compiler has no native support for FTP,HTTP, etc.

So I am dependent upon curl and ftplib for FTP implementation in my
application.
I am ignorant about external library and also make file.(becoz in
addtion to .c,.cpp,.h there is also a file called .lib file)

what should be my next step ???

 

[Richard Bos]

I am gooc in C

This has proved to be debatable.

what should be my next step ???

Find a newsgroup which handles your compiler specifically, not one which
handles Standard C. If you're as good at C as you think, your problems
are not with C, but with using your compiler suite.

Richard

 

[asit]

This has proved to be debatable.


Find a newsgroup which handles your compiler specifically, not one which
handles Standard C. If you're as good at C as you think, your problems
are not with C, but with using your compiler suite.

Richard

If some one gives me a link, I will be grateful....

 

[Richard Bos]

If some one gives me a link, I will be grateful....

*sigh* As has already been explained several times, it depends on
_which_ compiler you use.

Richard

 

[Antoninus Twink]

So I am dependent upon curl and ftplib for FTP implementation in my
application.
I am ignorant about external library and also make file.(becoz in
addtion to .c,.cpp,.h there is also a file called .lib file)

Are you sure? There might be a lib/ directory.

On *nix, static libraries are typically called *.a and shared libraries
are typically called *.so. On Windows, shared libraries are called
*.dll, and I don't believe that static libraries exist.

So once you have installed a library - for example, let's say you've
installed libcurl.so in /usr/local/lib - then you need to tell your
linker that your program depends on this library (e.g. by passing -lcurl
as a command-line argument, or by using a "linker options" menu item in
an IDE), and where to find it (e.g. by passing -L/usr/local/lib as an
argument, or naming the directory in the IDE).

As I said before, if you want specific instructions you should state
which operating system, IDE (if applicable) and compiler you're using.

 

[Flash Gordon]

Antoninus Twink wrote, On 09/10/08 20:59:

Are you sure? There might be a lib/ directory.

On *nix, static libraries are typically called *.a and shared libraries
are typically called *.so.

Apart from on big-name Unix implementations where they typicalally are not.

On Windows, shared libraries are called
*.dll, and I don't believe that static libraries exist.

OK, so we've established something else you don't know about. I really
don't know why you keep posting about things you obviously don't know.

So once you have installed a library - for example, let's say you've
installed libcurl.so in /usr/local/lib - then you need to tell your

<snip poor advice>

There are *far* better and more robust ways to use a lot of libraries
the details of which are off topic. They start by reading the
documentation for the library, which in the case of curl *definitely*
tells you how to do it (well, they told me how to do it in a far more
robust manner).

As I said before, if you want specific instructions you should state
which operating system, IDE (if applicable) and compiler you're using.

Actually, as usual when you ask people to post more, the OP should ask
implementation specific questions in an implementation specific group or
mailing list. People on the curl mailing lists will be able to explain
anything about how to use curl the OP does not understand and people on
the implementation specific groups will be able to tell the OP how to
use the tools of that implementation.

 

[Antoninus Twink]

Antoninus Twink wrote, On 09/10/08 20:59:

OK, so we've established something else you don't know about. I really
don't know why you keep posting about things you obviously don't know.

It's clear from the words I used that I wasn't claiming to know for sure
that static libraries don't exist on Windows. Really my statement was an
invitation for a Windows expert to enlighten me, and inform other
readers at the same time.

It's a shame that instead of passing on your knowledge, you instead
chose to throw mud.

There are *far* better and more robust ways to use a lot of libraries
the details of which are off topic. They start by reading the
documentation for the library, which in the case of curl *definitely*
tells you how to do it (well, they told me how to do it in a far more
robust manner).

Personally, I use the autotools for substantial projects, and
hand-crafted makefiles for little toy programs. I find both of those
"robust" enough for my needs, whatever on earth "robust" means in this
context.

The OP seems to be using Windows, and so is likely to be trying to do
things using IDEs, menus and the like. As he hasn't told us exactly what
platform he's using, I don't see how anyone could possibly provide
better help than generic advice to look for a "linker options" menu item
or something similar.

 

[Ian Collins]

It's clear from the words I used that I wasn't claiming to know for sure
that static libraries don't exist on Windows. Really my statement was an
invitation for a Windows expert to enlighten me, and inform other
readers at the same time.

Then do what the more intelligent accidental posters here do when
redirected and ask on a windows group.

I know you troll here just to piss of the regulars, but providing
misleading or bad advice to the innocent is just plain nasty.

 

[Antoninus Twink]

I know you troll here just to piss of the regulars,

Nonsense. I post here because I think it's important to contribute to a
frank forum where all C questions can be discussed. I couldn't care less
what those of the "regulars" with nothing useful to say and no
willingness to help people think or do, and as I understand it most of
them have "killfiled" me anyway.

but providing misleading or bad advice to the innocent is just plain
nasty.

I made it very clear that I wasn't sure that what I said was right, and
only a fool would have interpreted my words as gospel.

Anyway, this issue of static libraries on Windows seems to be an
interesting one.

<quote from Wikipedia>
Depending on how they are compiled, *.LIB files can be either static
libraries or representations of dynamically linkable libraries needed
only during compilation, known as "Import Libraries". Unlike in the UNIX
world, where different file extensions are used, when linking against
..LIB file in Windows one must first know if it is a regular static
library or an import library.
</quote>

That sounds very odd to me - what exactly is a "representation of a
dynamically linkable library needed only during compilation"? Why is it
useful?

 

[Flash Gordon]

Antoninus Twink wrote, On 09/10/08 23:14:

Anyway, this issue of static libraries on Windows seems to be an
interesting one.

It's not interesting.

<quote from Wikipedia>
Depending on how they are compiled, *.LIB files can be either static
libraries or representations of dynamically linkable libraries needed
only during compilation, known as "Import Libraries".

It's not accurate. At best it is a subset of the options used.

Unlike in the UNIX
world, where different file extensions are used,

It's far from accurate.

when linking against
.LIB file in Windows one must first know if it is a regular static
library or an import library.
</quote>

That sounds very odd to me - what exactly is a "representation of a
dynamically linkable library needed only during compilation"? Why is it
useful?

Ask in a Windows group and people might give you the entire horrible
story. It's nothing to do with C and everything to do with Windows.

 

[Richard]

Nonsense. I post here because I think it's important to contribute to a
frank forum where all C questions can be discussed. I couldn't care less
what those of the "regulars" with nothing useful to say and no
willingness to help people think or do, and as I understand it most of
them have "killfiled" me anyway.

The petty minded fools who try to over regulate this group remind me of
civil servants in various countries. Rather than stamp the form there and
then and save a lot of trouble, time and money they send you off to
repeat yourself over and over again to another department. It's the
ministry of "not my problem" in comp.lang.c.

 

[Nick Keighley]

The petty minded fools who try to over regulate this group remind me of
civil servants in various countries. Rather than stamp the form there and
then and save a lot of trouble, time and money they send you off to
repeat yourself over and over again to another department. It's the
ministry of "not my problem" in comp.lang.c.

ah! This is an excellent analogy. One of my friends works for
the Inland Revenue (IRS) (I'm just not picky am I?). During the
BSE (Mad Cow) crisis[1] his site was very busy. Vets (Vetinarians),
scientists, soldiers all sorts. Now if someone had walked into
his office and asked him the correct procedure for disposing of
the body of an infected BSE cow[2] should he:

(a) guess based on a conversation he'd had with a vet by the
coffee machine

or (b) point out this his site was shared between the Ministry of
Agriculture and The Inland Revenue. And though he would like to help
he was not, in fact, trained in vetinary medicine or in slaughtering
procedures.


[1] cattle in Britain were infected by a disease that caused their
brains
to rot away.

[2] my fiend does exist and his work site was busy during the BSE
"event".
But no one asked him how to get rid of a dead cow.

 

[Smurff]

The petty minded fools who try to over regulate this group remind me of
civil servants in various countries. Rather than stamp the form there and
then and save a lot of trouble, time and money they send you off to
repeat yourself over and over again to another department. It's the
ministry of "not my problem" in comp.lang.c.

I couldnt agree more. The time it took to write "your sh*t and know
nothing" they could have helped. Its a typical arrogance of people who
should get out more.

E.g. "Cry up anc blow away. Gooc-bye." Give the man a few links for
god sake.

 

[s0suk3]

If you have a question about Unix programming, where would it make most
sense to ask? comp.lang.c, or comp.unix.programmer?

UNIX is closely related to C (C was developed for and in that
environment), so if it has to do with both UNIX and C, I believe it to
be useful and harmless to discuss it in both comp.lang.c and
comp.unix.programmer.

If you have a question about Perl, where would it make most sense to ask?
comp.lang.c, or comp.lang.perl.misc?

Perl is closely related to C (Perl is written in C), so if it has to
do with an aspect of Perl relevant to C, I believe it to be useful and
harmless to discuss it in both comp.lang.c and comp.lang.perl.misc.

If you have a question about Windows programming (such as the OP's
question), where would it make most sense to ask? comp.lang.c, or
comp.os.ms-windows.programmer.win32?

Windows is closely related to C (a large part of Windows is written in
C), so if it has to do with an aspect of Windows relating to C, I
believe it to be useful and harmless to discuss it in both comp.lang.c
and comp.os.ms-windows.programmer.win32.

The thing is that those topics have their own specialized newsgroups,
so yes, it's probably best to discuss them there. However I see no
reason not to talk about them here, too (since they do relate to C),
and I see no need to tell someone asking about it to "Cry up anc blow
away. Gooc-bye."

Sebastian

 

[Chris Dollin]

UNIX is closely related to C (C was developed for and in that
environment),

That's not a close enough relationship to make UNIX discussions
topical in C, just as sheep-raising isn't generally topical in
a knitting forum.

Perl is closely related to C (Perl is written in C),

That's not a close relationship, that's an accidental relationship.
There are many languages with implementations in C -- I have, for
example, an implementation of my language Spice written in C;
but that doesn't make Spice topical here, which is just as well,
since what it has in common with C [1] is common to many many languages,
and what it doesn't have in common [2] is the greater part.

Windows is closely related to C (a large part of Windows is written in
C),

Ditto.

[1] statements, procedures, variables, expressions, sequences ...

[2] dynamic types, optional static typing, automatic store management,
multi-methods, multiple values (for expressions, statements, argument
lists, return values), full lexical scoping, lambda-expressions,
classes, packages, no goto, no break, no continue, no return, but
a baroque for-loop.

 

[vippstar]

UNIX is closely related to C (C was developed for and in that
environment), so if it has to do with both UNIX and C, I believe it to
be useful and harmless to discuss it in both comp.lang.c and
comp.unix.programmer.


Perl is closely related to C (Perl is written in C), so if it has to
do with an aspect of Perl relevant to C, I believe it to be useful and
harmless to discuss it in both comp.lang.c and comp.lang.perl.misc.


Windows is closely related to C (a large part of Windows is written in
C), so if it has to do with an aspect of Windows relating to C, I
believe it to be useful and harmless to discuss it in both comp.lang.c
and comp.os.ms-windows.programmer.win32.

Well, I have written an implementation for every single programming
language out there, in C.
That makes every programming language topical here in comp.lang.c
I believe it to be useful and harmless to discuss it in both
comp.lang.c and their dedicated group.

Also, since C is turing complete, every and any algorithm is topical
here in comp.lang.c
I believe it to be useful and harmless to discuss all algorithms in
both comp.lang.c and their dedicated group.

ISO is closely related to C; (A large part of C is actually written by
ISO), so yeah, all published standards by ISO are topical here.

A friend of a friend is a friend, so comp.lang.c is pretty much a
forum for everything and anything.
No harm in that. Useful, I believe.