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

please provide a SONAME #29

Open
GoogleCodeExporter opened this issue Jul 6, 2015 · 13 comments
Open

please provide a SONAME #29

GoogleCodeExporter opened this issue Jul 6, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link

Can you please provide a SONAME for the library?

Installing something in usr/lib without a SONAME is so painful.

Original issue reported on code.google.com by costamag...@gmail.com on 10 Feb 2015 at 3:37

@GoogleCodeExporter
Copy link
Author

thanks

Original comment by costamag...@gmail.com on 10 Feb 2015 at 3:37

@GoogleCodeExporter
Copy link
Author

This is committed, along with some other minor tweaks (warning messages and the 
CFLAGS bits you asked for in issue 28) in r194.

I gave the libraries identical names to the files that the build system creates:
libcld2_dynamic.so
libcld2_full.so
libcld2.so

Original comment by andrewha...@google.com on 12 Feb 2015 at 11:27

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

nope, you should give something like 0.0.0

something like this :)
gcc -shared -Wl,-soname,libmystuff.so.1 \
    -o libmystuff.so.1.0.1 a.o b.o -lc

(cmake handles it automatically, I'm trying to port the build script right now)

BTW not only chromium is using it, now also poedit!

thanks for the fixes so far!

Original comment by costamag...@gmail.com on 12 Feb 2015 at 11:38

@GoogleCodeExporter
Copy link
Author

So, CLD2 doesn't have release versions like this. The closest that we have is 
the date of the data files, generally speaking. We could add a ".1" to make 
things happy, but that's really about the only sensible thing at the moment 
without actually having a "x.y.z." versioning scheme, which the project 
currently lacks.

I didn't mean to imply with my comments in issue #28 that *only* Chromium uses 
CLD; it's certainly not intended to be just for Chromium. The metapoint is that 
most of the projects that incorporate CLD that I'm currently aware of compile 
it at the same time as everything else, meaning they don't end up with a 
standalone CLD library to link at runtime. It's a totally valid use case, 
though, which is why I'm happy to take a makefile improvement :)

I'd like Dick's thoughts on versioning before committing to make it a ".1", 
because we're likely stuck with whatever we do there for the forseeable future. 
I'd hate to cause pain for the consumers of the library by mangling the version.

Original comment by andrewha...@google.com on 12 Feb 2015 at 12:12

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Ok, I fixed some issues, and created the cmake file.

It wasn't trivial, since your build scripts are *far* from ideal.

Now the cmake is *exactly* as the build scripts, just I avoided inclusion of 
headers files, since when you build the corresponding cc file the correspondant 
header is already included in the #include directive.

Now of course it is working, just with a *FULL* explanation about your system, 
I'll be glad to reduce it a lot, by using the created libraries for testing, 
instead of rebuilding everything again from scratch.

this will simplify a lot the CMake file. 

Original comment by costamag...@gmail.com on 12 Feb 2015 at 4:27

Attachments:

@GoogleCodeExporter
Copy link
Author

oops, I did a typo

to build you can just
mkdir build
cd build
cmake ..
make -j whatever

of course we can add flags to build only parts of the cld2, like
-DENABLE_TESTS=ON or something like this.

tests still need to be run manually (I don't know how to handle pipes with 
cmake)

Original comment by costamag...@gmail.com on 12 Feb 2015 at 4:33

Attachments:

@GoogleCodeExporter
Copy link
Author

ping :-)

what about providing a soname just if some cmake flag is enabled?

Original comment by costamag...@gmail.com on 3 Mar 2015 at 6:54

@GoogleCodeExporter
Copy link
Author

changing SHARED to STATIC in CmakeLists.txt makes cmake build static libraries

Original comment by costamag...@gmail.com on 4 Mar 2015 at 4:37

@GoogleCodeExporter
Copy link
Author

Ping again, can you please just provide a SONAME like the svn revision? 1.0.194 
for svn revision 194 for example.

You can change it at each commit, so everyone is happy (and I can create some 
cmake stuff to automatically add it)

let me know, thanks

(this is a showstopper for Debian packaging)

Original comment by costamag...@gmail.com on 26 Mar 2015 at 4:41

@GoogleCodeExporter
Copy link
Author

Adding a new cmake file version, building faster (I link libraries rather than 
rebuilding the all files each time for the testsuite) and adding a SONAME like

0.0.194 where 194 is the svn revision

Original comment by costamag...@gmail.com on 30 Mar 2015 at 2:45

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for the cmake file.  It's possible to actually build this project now.

Original comment by s...@broala.com on 29 May 2015 at 2:22

@GoogleCodeExporter
Copy link
Author

Jason, can you take a look at what it would take to add this in? I don't have 
any experience with CMake but it sounds like it's useful.

Original comment by andrewha...@google.com on 29 May 2015 at 2:49

@GoogleCodeExporter
Copy link
Author

Actually this is part of Debian already, but I changed the cmake to use only 
once the svn version
https://sources.debian.net/src/cld2/0.0.0~svn194-1/CMakeLists.txt/

Original comment by costamag...@gmail.com on 29 May 2015 at 4:16

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

No branches or pull requests

1 participant