Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install libfdt.so #333

Closed
wants to merge 1 commit into from
Closed

Install libfdt.so #333

wants to merge 1 commit into from

Conversation

ggardet
Copy link

@ggardet ggardet commented Sep 9, 2016

Install libfdt.so as it is needed by libdtovl.so.

@popcornmix
Copy link
Contributor

@pelwell does this look sensible?

@clivem
Copy link

clivem commented Sep 9, 2016

I hope to hell he says, "no". ;) At least not installing it as .so.

@clivem
Copy link

clivem commented Sep 9, 2016

Perhaps whatever libfdt package is installed from Raspbian is too old for what Phil needs......
Installing an unversioned .so runtime (which is also going to be used by linker) and then making sure it trumps anything in system lib directory with the ld.so.conf.d config....... Hmmm. Wouldn't this private copy of libfdt be better built as a static lib?

@pelwell
Copy link
Contributor

pelwell commented Sep 9, 2016

First of all, the commit message is wrong - this causes libfdt.a to be installed, not libfdt.so.

Secondly, libfdt.a is statically linked into libdtovl.so, so why would you want to install it as well? If you run nm over all of the shared libraries you will find that none of the libfdt functions are undefined.

Clive is right that this version of libfdt is newer and slightly tweaked compared to the standard Raspbian version, but I'm optimistic that most of the content of libdtovl will disappear once an overlay-capable libfdt is finally upstreamed.

@clivem
Copy link

clivem commented Sep 9, 2016

First of all, the commit message is wrong - this causes libfdt.a to be installed, not libfdt.so.

Excuse my getting hot under the collar then..... It is already a static lib, doesn't need to be installed and never was a .so anyway...... ;)

@ggardet
Copy link
Author

ggardet commented Sep 12, 2016

Without this patch, libdtovl.so requires libfdt.so!
"readelf -d libdtovl.so" returns:
Dynamic section at offset 0x4ef8 contains 29 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libfdt.so]

It may be due to using "-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF" cmake flags?

@clivem
Copy link

clivem commented Sep 12, 2016

It may be due to using "-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF" cmake flags?

I'm confused. Where does that come from? It's you who is modifying the build so that building static libraries is disabled, and the needed code from libfdt is not linked-in to libdtovl at build time?

@ggardet
Copy link
Author

ggardet commented Sep 12, 2016

Yes, I use the %cmake macro from my build service to build the RPM.

@clivem
Copy link

clivem commented Sep 12, 2016

Maybe I'm stupid, but what is the problem you are trying to solve to start with, by not using the default config which results in some libraries being built statically?

@pelwell
Copy link
Contributor

pelwell commented Sep 12, 2016

You are supposed to run the buildme script in the root of the userland repo. If you are using any other build mechanism you should at least make that clear to avoid wasting everyone's time, and then make a case for why we should make changes to support your particular build method.

@Ruffio
Copy link

Ruffio commented Nov 18, 2016

@ggardet please close this PR if there is nothing new...

@ggardet
Copy link
Author

ggardet commented Nov 18, 2016

I switched back to the build script behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants