Re: Links2 in graphics mode in X?
From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 09/28/04
- Next message: Sherman: "Re: customized ip stack over ethernet"
- Previous message: Alan Connor: "Hear Ye, Hear Ye (was Re: MC Alternative? (File Managers))"
- In reply to: Tim: "Re: Links2 in graphics mode in X?"
- Next in thread: Tim: "Re: Links2 in graphics mode in X?"
- Reply: Tim: "Re: Links2 in graphics mode in X?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 28 Sep 2004 20:37:13 +0200
Tim <it2gati@ituniv.se> wrote:
> Checking for inflate in -lz... no
> Checking for png.h... no
> Checking for libpng/png.h... no
> Checking for png_create_info_struct in -lpng... no
> Configure: error: "you need libpng to cmpile Links in graphics mode"
> So I wandered away and ran this command
You do indeed need libping: libping.a or libping.so, as the line
"-lpng" tells one:
(man gcc, for example)
-llibrary
Use the library named library when linking.
The linker searches a standard list of directories
for the library, which is actually a file named
`liblibrary.a'. The linker then uses this file as
if it had been specified precisely by name.
(and in the case of partial linking with an eye to runtime completion of
the linking process with runtime shared libraries, the linker will be
looking for a .so - shared object - file not a .a - archive of objects -
file).
> installpkg /mnt/cdrom/slackware/l/libpng-1.2.5-i486-2.tgz
> This works perfectly and I ran
> locate png.h
> It locates a number of such files so I figure everything is okey.
well, png.h is indeed a good indicator. I would normally expect that if
you have that, then you have the development support required, which
includes libpng.so and libpng.a.
/usr/lib/libpng.a
/usr/lib/libpng.so
/usr/lib/libpng.so.2
/usr/lib/libpng.so.3
> This is the way I have usually done it before and it usually works.
> Unfortunatley this time it didn't and png.h is the only file mentioned in
> the error message so that was the natural file to go look for
Well, it didn't complain about png.h, but about libpng.{a,so}
(designated as "-lpng"). It just accepted matter-of-factly that you
didn't have png.h and went on its way ..
> Not that Ineed it right now since I got the .tgz from a friendly "Stachu
> 'Dozzie' K." but for future reffernce I would still like to know how I am
> supposed to find the relevant files in a case like this.
There is no generic method. Your task is to recreate the development
environment of the developer. Since he doesn't know precisely what bits
of his envirnment are necessary and which are merely nice to have, you
get to do the thinking. That thinking includes examining the data and
looking in the config.log, which will show you the failure linking
with "-lpng", and the code it tried in order to elicit that response.
That's so basic it doesn't require thinking about, btw. It said that
-lpng failed, so you need to go get libpng.a and libpng.so (depending
on whether you configured for static or dynamic linking, or both).
Then if anything else fails in the configure run, you get to go and
debug what configure needs again. Repeat until configure is done.
And THEN starts the process of debugging problems in the compilaton
caused by aspects of the developers environment that the developer was
not aware of and did not write a configure test for. Compiler
differences are very common ones. I spend lots of time normally
de-modernizing C++ codes, or de-ansi99ing C codes.
If, OTOH, you build from a .deb or .srpm source package, I believe the
build dependencies (as known to the author) will be listed, so you can
make sure to get those.
OTOH, it may be that the developers list is waay too conservative, and
you can do without half his list of "necessities", and see if configure
can steer you through to a working configuration. If the compile then
bombs, you can usually hack out of the source whatever abstruse feature
that is dependent on the missing bit. It's usually only a paragraph or
two.
> While writing this message I looked carefully at http://www.slackware.com/pb
> and found that a 7.8mb pckage called aaa_elflibs-9.2.0-i486-1 is supposed to
> install two files
> /usr/lib/libpng12.so.0.1.2.5
> /usr/lib/libpng.so.3.1.2.5
Those are runtime libraries, not compiletime.
> And I guess those are the missing files in this case but I still claim that
They aren't.
> even if I am correct and these are the two missing files it is not obvious
> to a beginner that aaa_elflib must be installed in addition to libpng to get
> libpng to work.
It's obvious to anyone to has ever compiled anything in C or C++. It's
impossible to compile without linking against something, even if it is
only libc.a or libc.so. Therefore everyone who compiles is aware that
they link against .a and .so files.
> Sorry about this rant
It's not a rant. It's like saying "nobody told me the round thing in
the front seat of the car was what I needed to steer with".
Peter
- Next message: Sherman: "Re: customized ip stack over ethernet"
- Previous message: Alan Connor: "Hear Ye, Hear Ye (was Re: MC Alternative? (File Managers))"
- In reply to: Tim: "Re: Links2 in graphics mode in X?"
- Next in thread: Tim: "Re: Links2 in graphics mode in X?"
- Reply: Tim: "Re: Links2 in graphics mode in X?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
