 |
|
| Linux Forum Index » Linux Development - Applications » Statically linking to a library that's also... |
|
Page 1 of 1 |
|
| Author |
Message |
| fia_wrc_fanatic... |
 Posted: Tue Aug 18, 2009 4:21 am |
|
|
|
Guest
|
I've run into a problem with a couple of libraries that my (Linux) app
relies on. My application links to a shared-library version of
Ghostscript. But another part of my application needs to link to
jpeglib (Independent JPEG Group) which I am building as a static
library.
The problem is that Ghostscript builds its _own_ copy of jpeglib which
is statically linked into the Ghostscript shared library file. Now my
application is calling Ghostscript's copy of jpeglib at run-time and
NOT the version that I separately built as a static library resulting
in (as best as I can understand) a memory corruption leading to a
segfault.
How can I solve this problem?
Is there any way to modify the Ghostscript build process so that its
"embedded" copy of jpeglib is not exported?
The platform is CentOS 5.3 with gcc-4.1.2 and glibc-2.5.
The link command line for my app specifies "-ljpeg" before "-lgs" so
that I try and link to my copy of jpeglib first and then to
Ghostscript.
Any help or advice on this situation is appreciated.
Thanks! |
|
|
| Back to top |
|
|
|
| Thomas Zimmermann... |
| Posted: Tue Aug 18, 2009 4:57 am |
|
|
|
Guest
|
Hi
Quote: How can I solve this problem?
Why don't you rely on Ghostscript's version of libjpeg in the first
place?
Quote: Is there any way to modify the Ghostscript build process so that its
"embedded" copy of jpeglib is not exported?
You should ask this one the Ghostscript ML.
As a more general note, with GCC 4 it is possible to have functions with
are not exported from a shared library. So in theory there should be a
way.
Quote: Any help or advice on this situation is appreciated.
I've found the following text passage in Ghostscript's install manual [1]
The unix*.mak files explicitly compile and link the JPEG, PNG, and zlib
libraries into the executable. If your Unix system already includes the
PNG and zlib libraries -- probably in /usr/lib/libpng.{a,so} and /usr/
lib/libz.{a,so} -- and you would rather use those copies, change the
definition of SHARE_LIBPNG and SHARE_ZLIB from 0 to 1 in the relevant
unix*.mak file before compiling. Note that if you do this, you will get
non-debug versions of these libraries even if you selected DEBUG in the
makefile. At the insistence of some users, we have also provided the
ability to do this with the JPEG library (SHARE_JPEG), but should not
use it: in order to be compatible with Adobe interpreters (which do not
follow the JPEG standard exactly), Ghostscript has to compile the IJG
code with the non-standard definition
#define D_MAX_BLOCKS_IN_MCU 64
and since shared versions of this library will not have been compiled
this way, you awill get errors on some valid PostScript and PDF input
files.
So simply exchanging the JPEG library doesn't look like a good idea. If
the Ghostscript library does the same as the Ghostscript binary, then
drop the library, fork and exec the binary, and pipe your commands to the
child process.
Thomas
[1] http://pages.cs.wisc.edu/~ghost/doc/AFPL/5.50/Make.htm#Unix_build |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Wed Aug 19, 2009 2:34 am |
|
|
|
Guest
|
On Aug 18, 7:21 am, fia_wrc_fanatic <fia_wrc_fana... at (no spam) yahoo.com> wrote:
Quote: I've run into a problem with a couple of libraries that my (Linux) app
relies on. My application links to a shared-library version of
Ghostscript. But another part of my application needs to link to
jpeglib (Independent JPEG Group) which I am building as a static
library.
There's a technology specifically designed to solve this problem. It's
called 'dynamic linking'. You might want to look into it. If for some
reason you absolutely can't do that, quarantine the problem libraries
with wrapper processes.
DS |
|
|
| Back to top |
|
|
|
| fia_wrc_fanatic... |
| Posted: Wed Aug 19, 2009 5:07 am |
|
|
|
Guest
|
On Aug 19, 8:34 am, David Schwartz <dav... at (no spam) webmaster.com> wrote:
Quote:
There's a technology specifically designed to solve this problem. It's
called 'dynamic linking'. You might want to look into it. If for some
reason you absolutely can't do that, quarantine the problem libraries
with wrapper processes.
If you are referring to building (my own copy of) libjpeg as a shared
library (.so), I've already tried that but the problem persists. |
|
|
| Back to top |
|
|
|
| Joe Pfeiffer... |
| Posted: Wed Aug 19, 2009 9:23 am |
|
|
|
Guest
|
fia_wrc_fanatic <fia_wrc_fanatic at (no spam) yahoo.com> writes:
Quote: I've run into a problem with a couple of libraries that my (Linux) app
relies on. My application links to a shared-library version of
Ghostscript. But another part of my application needs to link to
jpeglib (Independent JPEG Group) which I am building as a static
library.
The problem is that Ghostscript builds its _own_ copy of jpeglib which
is statically linked into the Ghostscript shared library file. Now my
application is calling Ghostscript's copy of jpeglib at run-time and
NOT the version that I separately built as a static library resulting
in (as best as I can understand) a memory corruption leading to a
segfault.
After reading several later posts in the thread, this just sounds very
unlikely to me. I don't, off the top of my head, see a reason why
calling ghostscript's version of libjpeg will cause the memory
corruption and segfault you're seeing (absent a bug in either
ghostscript or libjpeg, of course). I'd put that on a back burner
and look elsewhere for the problem for a while.
--
Klingon programs don't have parameters. They have arguments and win
them (Walter Bushell) |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Wed Aug 19, 2009 2:31 pm |
|
|
|
Guest
|
On Aug 19, 8:07 am, fia_wrc_fanatic <fia_wrc_fana... at (no spam) yahoo.com> wrote:
Quote: On Aug 19, 8:34 am, David Schwartz <dav... at (no spam) webmaster.com> wrote:
There's a technology specifically designed to solve this problem. It's
called 'dynamic linking'. You might want to look into it. If for some
reason you absolutely can't do that, quarantine the problem libraries
with wrapper processes.
If you are referring to building (my own copy of) libjpeg as a shared
library (.so), I've already tried that but the problem persists.
Then give us details about that case. That's the case where there
should be no problem. (Did you make sure GS uses dynamic linking too?)
DS |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Thu Aug 20, 2009 6:38 am |
|
|
|
Guest
|
Quote: |The problem is that Ghostscript builds its _own_ copy of jpeglib which
|is statically linked into the Ghostscript shared library file. Now my
|application is calling Ghostscript's copy of jpeglib at run-time and
|NOT the version that I separately built as a static library resulting
|in (as best as I can understand) a memory corruption leading to a
|segfault.
So, if I'm reading his description accurately, he wants to use jpeglib
for his jpeg manipulation, and GS has a copy of jpeglib. If he and GS
are really using jpeglib in both cases, it isn't at all clear why he
wants his own copy in the first place, nor how using GS's version
instead of his own in all places (again, that's how he seems to be
describing it) would cause the problem.
Huh? This is a common cause of corruption. It's quite clear how this
would cause a problem.
For example, suppose his code is:
some_struct=JPG_alloc(...);
// some code
JPG_free(some_struct);
Now, imagine if 'JPG_free' is a macro that translates to 'free
(some_struct)' because that's appropriate for the libjpeg he compiled
against. But suppose the JPG_alloc calls the JPG_alloc in the library
GS was compiled with -- one which does not allocate a JPG structure
with one big call to malloc.
Boom.
That's just one obvious example. Mismatch of header files and library
binaries is a common cause of crashes, memory corruption, and the
like.
DS |
|
|
| Back to top |
|
|
|
| Joe Pfeiffer... |
| Posted: Thu Aug 20, 2009 12:19 pm |
|
|
|
Guest
|
David Schwartz <davids at (no spam) webmaster.com> writes:
Quote: |The problem is that Ghostscript builds its _own_ copy of jpeglib which
|is statically linked into the Ghostscript shared library file. Now my
|application is calling Ghostscript's copy of jpeglib at run-time and
|NOT the version that I separately built as a static library resulting
|in (as best as I can understand) a memory corruption leading to a
|segfault.
So, if I'm reading his description accurately, he wants to use jpeglib
for his jpeg manipulation, and GS has a copy of jpeglib. If he and GS
are really using jpeglib in both cases, it isn't at all clear why he
wants his own copy in the first place, nor how using GS's version
instead of his own in all places (again, that's how he seems to be
describing it) would cause the problem.
Huh? This is a common cause of corruption. It's quite clear how this
would cause a problem.
For example, suppose his code is:
some_struct=JPG_alloc(...);
// some code
JPG_free(some_struct);
Now, imagine if 'JPG_free' is a macro that translates to 'free
(some_struct)' because that's appropriate for the libjpeg he compiled
against. But suppose the JPG_alloc calls the JPG_alloc in the library
GS was compiled with -- one which does not allocate a JPG structure
with one big call to malloc.
Boom.
That's just one obvious example. Mismatch of header files and library
binaries is a common cause of crashes, memory corruption, and the
like.
All true -- assuming that when he describes GS's jpeglib and his
jpeglib, they aren't the same jpeglib code. What I get from his
description is that it's simply two copies of the same code.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin) |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Thu Aug 20, 2009 6:51 pm |
|
|
|
Guest
|
On Aug 20, 11:19 am, Joe Pfeiffer <pfeif... at (no spam) cs.nmsu.edu> wrote:
Quote: All true -- assuming that when he describes GS's jpeglib and his
jpeglib, they aren't the same jpeglib code. What I get from his
description is that it's simply two copies of the same code.
Although it's much less likely, even two copies of the exact same code
can get you into trouble.
For example, suppose the library supports two types of JPGs and has a
structure that contains pointers to the serialization function, so if
it's a type 1 JPG, then jpg->serialize is a pointer to the
serialize_jpg1 function and if it's a type 2 JPG, then jpg->serialize
is a pointer to the serialize_jpg2 function.
What happens if he gets a type 1 JPG from GS and passes it to a
library function that does this:
void do_stuff(JPG *jpg)
{
if(jpg->serialize==serialize_jpg1)
{
/* this is a type 1 JPG */
...
Now there are two pointers to two copies of the 'serialize_jpg1'
function, and this test may return false when it should return true.
However, this is getting progressively less likely.
DS |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Mon Dec 14, 2009 10:03 pm
|
|