[SOLVED] circular dependencies, please explain

a4z · 12-17-2016, 01:29 PM

just fixed an issue in sbbdep, on Slackware 14.2 we seem to have circular dependencies, now I detect them and this is interesting.

for example
/usr/lib64/libfreetype.so.6.12.3
/usr/lib64/libharfbuzz.so.0.10200.7
they need each other
I think this is broken by and in design , but I can understand this somehow.

but, what I can not understand is

Code:

readelf -d /usr/lib64/libfreetype.so

Dynamic section at offset 0x9b4c0 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libbz2.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpng16.so.16]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libfreetype.so.6]
 .....

you see?

libfreetype.so.6 needs libfreetype.so.6
so it needs itself.
why?
am I wrong when I think this is wrong?

Richard Cranium · 12-17-2016, 02:17 PM

It is absolutely allowed for a library to reference itself.

kikinovak · 12-17-2016, 02:20 PM

Circular dependencies are a rare beast, but they do happen sometimes. I was just confronted to one with ffmpeg and opencv. What I did to resolve it:

Build opencv without ffmpeg ;
Build ffmpeg against opencv ;
Rebuild opencv against ffmpeg.

Cheers,

Niki

atelszewski · 12-17-2016, 02:44 PM

Hi,

Quote:

Originally Posted by Richard Cranium

It is absolutely allowed for a library to reference itself.

Do you have some info on when this could be useful or necessary?

@kikinovak That is a bit different story (opencv/ffmpeg). There are two libraries needing each other, not single library needing itself.

--
Best regards,
Andrzej Telszewski

Richard Cranium · 12-17-2016, 06:01 PM

Quote:

Originally Posted by atelszewski

Do you have some info on when this could be useful or necessary?

Any time that you need a relocatable symbol somewhere else in the same library.

atelszewski · 12-17-2016, 06:42 PM

Hi,

Can you suggest something to read?

I don't get why library would need itself for the library's code to be position independent.
(I assume this is what it is all about).

--
Best regards,
Andrzej Telszewski

Richard Cranium · 12-17-2016, 07:01 PM

I'm afraid not. I haven't done C/C++ in any serious way for years.

I'd have to look at how the runtime linker operates, but it wouldn't surprise me if the lookup tables were keyed by library soname.

montagdude · 12-17-2016, 07:18 PM

I'd like to know what the deal is with this too. I'm not really sure how this would even happen. Did it get built twice and linked against the original copy the second time?

atelszewski · 12-17-2016, 07:58 PM

Hi,

Quote:

Originally Posted by montagdude

I'd like to know what the deal is with this too. I'm not really sure how this would even happen. Did it get built twice and linked against the original copy the second time?

Even better than that.
You can't build freetype without freetype being installed.

--
Best regards,
Andrzej Telszewski

a4z · 12-18-2016, 01:31 AM

Quote:

Originally Posted by Richard Cranium

It is absolutely allowed for a library to reference itself.

The linker will happily write in every nonsense I tell it to write in as long as it can find a coresponding elf in the search path. (like an old version of itself, dirty build environment!)
The runtime linker has a dummy firewall against cyclic dependencies, nothing can load more than once, and a library itself will be ignored.

If you define 'absolutely allowed' as 'not absolutely forbidden' than you are, of course, somehow right.

Quote:

Originally Posted by kikinovak

Circular dependencies are a rare beast, but they do happen sometimes. I was just confronted to one with ffmpeg and opencv. What I did to resolve it:

Build opencv without ffmpeg ;
Build ffmpeg against opencv ;
Rebuild opencv against ffmpeg.

Cheers,

Niki

nice story, but has nothing to do with my question.
as written, this is something I can somehow understand, even if this is a clear sing of bad design.

Let me rephrase the questions:
1)
someone is building freetype and tells it to add a -lfreetype to the linker,
What is obviously useless but works by accident because it is, in an older version, already in the search path.
But how does it come there?
How is /usr/lib64/libfreetype.la generated that it puts itself as a dependency in the dependency list?
This looks more like an accident than a well thought solution.

2)
what is the advantage of having freetype as a dependency of harfbuzz?
other distros seem to ship without that cycle, and in open embedded it is explicit disabled for good reasons

3)
so does Slackware really want that, or did it just happen?

hazel · 12-18-2016, 03:05 AM

Here's how Linux from Scratch resolves this particular dependency loop:

FreeType2 Dependencies
Recommended

HarfBuzz-1.3.0 (first, install without it, after it is installed, reinstall FreeType-2.6.5), libpng-1.6.24, and Which-2.21

As you can see from this, it is possible to build and install freetype without harfbuzz. It just doesn't work as well.

Richard Cranium · 12-18-2016, 03:31 AM

Looking at the build scripts, there appears to be a bit of functionality that is in freetype that harfbuzz wants to use. (Otherwise, why would harfbuzz want to use anything out of freetype in the first place?) To fix the circular dependency, you'd have to pull out that bit and put it into a third project that both harfbuzz and freetype can use.

That would require the harfbuzz and freetype teams to communicate with each other.

atelszewski · 12-18-2016, 03:32 AM

Hi,

When trying to build freetype-2.6.3 on system with freetype uninstalled:

Code:

[...]
/usr/bin/grep: /usr/lib64/libfreetype.la: No such file or directory
/usr/bin/sed: can't read /usr/lib64/libfreetype.la: No such file or directory
libtool:   error: '/usr/lib64/libfreetype.la' is not a valid libtool archive
config.mk:55: recipe for target '/tmp/freetype-2.6.3/objs/libfreetype.la' failed
make: *** [/tmp/freetype-2.6.3/objs/libfreetype.la] Error 1
[...]

The same thing happens when trying to build version 2.6.5 from -current.
(I tried building those on 14.2).

EDIT:
Version 2.7 fails exactly the same way.

--
Best regards,
Andrzej Telszewski

phenixia2003 · 12-18-2016, 04:49 AM

Hello,

Quote:

Originally Posted by atelszewski

Hi,

When trying to build freetype-2.6.3 on system with freetype uninstalled:

Code:

[...]
/usr/bin/grep: /usr/lib64/libfreetype.la: No such file or directory
/usr/bin/sed: can't read /usr/lib64/libfreetype.la: No such file or directory
libtool:   error: '/usr/lib64/libfreetype.la' is not a valid libtool archive
config.mk:55: recipe for target '/tmp/freetype-2.6.3/objs/libfreetype.la' failed
make: *** [/tmp/freetype-2.6.3/objs/libfreetype.la] Error 1
[...]

To build freetype with freetype uninstalled, you need to uninstall harfbuzz, or add --with-harfbuzz=no (this option can be set to yes|no|auto, auto being the default) into freetype.SlackBuild, as below :

Code:

CFLAGS="$SLKCFLAGS" make setup CFG="--with-harfbuzz=no --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --build=$ARCH-slackware-linux"

The best would be to add a variable WITH_HARFBUZZ into the slackbuild, like in example below :

Code:

WITH_HARFBUZZ=${WITH_HARFBUZZ:-auto}

CFLAGS="$SLKCFLAGS" make setup CFG="--with-harfbuzz=${WITH_HARFBUZZ} --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --build=$ARCH-slackware-linux"

--
SeB

SCerovec · 12-18-2016, 04:31 PM

Quote:

Originally Posted by Richard Cranium

Looking at the build scripts, there appears to be a bit of functionality that is in freetype that harfbuzz wants to use. (Otherwise, why would harfbuzz want to use anything out of freetype in the first place?) To fix the circular dependency, you'd have to pull out that bit and put it into a third project that both harfbuzz and freetype can use.

That would require the harfbuzz and freetype teams to communicate with each other.

^this

We fail miserably to make our lives easier in the obvious way.

We alone rise the price of good life, usually for no reason (="stupidity").

@phenixia2003: bullseye as usual