Skip to content

/etc/ld.so.cache regeneration #5217

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

Closed
cnd opened this issue Mar 4, 2013 · 9 comments
Closed

/etc/ld.so.cache regeneration #5217

cnd opened this issue Mar 4, 2013 · 9 comments

Comments

@cnd
Copy link
Contributor

cnd commented Mar 4, 2013

With source based package manager I do run regenerating /etc/ld.so.cache everytime I compile new package to system.

After make & make install rust I'm getting below messages there:

/sbin/ldconfig: File /usr/local/lib/librusti.so is empty, not checked.

same about librustc.so , librust.so and other

To be honest I don't like it but what does it mean? How can I resolve this?

by the way I'm not sure if local is correct place for installed by package manager package so maybe I need to move package manually after make install?

@brson
Copy link
Contributor

brson commented Mar 5, 2013

The problem is that librusti.so is just a 0-byte placeholder file used by the build system to manage dependencies. Rust libraries have names like librusti-[hex]-[vers].so, and the hex string in the middle is not a stable identifier, so we use the names without all the gunk just so make can identify the dependencies.

We should not be installing these files. One thing we could do to solve this easily might be to name these something like librusti.so.dummy (this is what servo does).

These files have caused confusion before.

@cnd
Copy link
Contributor Author

cnd commented Mar 5, 2013

User confusion is better then my build system confusion though. Maybe it's really better to not install those files?

And what about installing to local ?

@brson
Copy link
Contributor

brson commented Mar 6, 2013

Yes, I agree they should not be installed (see #4486 for a little more on this subject).

Your package probably shouldn't install to /usr/local and instead install to /usr (I imagine, depends on your package manager). To do this you'll want to use the --prefix=/usr flag to configure, and not just copy the files. There are some behaviors related to library loading that base their paths on the configured prefix, so things could break in subtle ways if you simply copy the installed files to a different location.

@cnd
Copy link
Contributor Author

cnd commented Mar 6, 2013

Thank you. May I rename them myself to *.dummy ?

@brson
Copy link
Contributor

brson commented Mar 6, 2013

Yes, absolutely you may, though I'm not sure exactly what you intend. I think the proper way to do this is to modify this bit of the makefiles that controls library naming. That CFG_LIB_NAME macro produces the name of a library as appropriate for the target architecture, e.g. librust.so. Adding .dummy to those definitions (except for CFG_RUNTIME and CFG_RUSTLLVM, which are native libraries, not Rust crates) will probably do what we want. Additionally the rules for make clean in mk/clean.mk will need to be changed to account for the new extension.

@cnd
Copy link
Contributor Author

cnd commented Mar 11, 2013

rename is wrong solution...

>>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: File /usr/lib/librustdoc.so.dummy is empty, not checked.
/sbin/ldconfig: File /usr/lib/librusti.so.dummy is empty, not checked.
/sbin/ldconfig: File /usr/lib/librust.so.dummy is empty, not checked.
/sbin/ldconfig: File /usr/lib/librustc.so.dummy is empty, not checked.
/sbin/ldconfig: File /usr/lib/librustpkg.so.dummy is empty, not checked.

@cnd
Copy link
Contributor Author

cnd commented Mar 11, 2013

What about removing them after installation?

@brson
Copy link
Contributor

brson commented Mar 11, 2013

The intent of renaming them during the build is that the install script will then not install them (since it doesn't, or shouldn't, install *.dummy files). If you want to avoid hacking the makefiles then yes, deleting them should be fine.

@cnd
Copy link
Contributor Author

cnd commented Mar 12, 2013

Fine. Here is the ebuild (gentoo build script) then https://github.com/Cynede/gentoo-rust/blob/master/dev-lang/rust/rust-9999.ebuild

So I close this question because it's solved for myself even in hacky way.
Reopen if you prefer to keep it open to solve it in makefile.

@cnd cnd closed this as completed Mar 12, 2013
jhpratt pushed a commit to jhpratt/rust that referenced this issue Apr 20, 2022
…ust-lang#5217)

* fix(rustfmt): fix struct field formatting with doc comments present

Fixes rust-lang#5215

* fix review feedbacks

* add unit test without doc comment

* move tests to a seperate file

* add additional test cases

* reintroduce a newline at the of test/souce/structs.rs
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

No branches or pull requests

2 participants