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

Snowball as a shared library #34

Open
Sufrostico opened this issue Feb 21, 2016 · 13 comments · May be fixed by #160
Open

Snowball as a shared library #34

Sufrostico opened this issue Feb 21, 2016 · 13 comments · May be fixed by #160

Comments

@Sufrostico
Copy link

Hi there,

Is there a way to compile snowball to a shared library?

Generating something like libsnowball.so ? or libsnowball.dll?

@Sufrostico
Copy link
Author

Hi there, any news on this?

@ojwb
Copy link
Member

ojwb commented Mar 1, 2016

Please have patience, it's barely been a week since you opened this.

@Sufrostico
Copy link
Author

oks, thanks for the answer

@mitya57
Copy link
Contributor

mitya57 commented Mar 1, 2016

FWIW Debian also ships a patch to use shared library.

@Sufrostico
Copy link
Author

@mitya57 can you provide a link, can't find it in alioth

@mitya57
Copy link
Contributor

mitya57 commented Mar 2, 2016

@Sufrostico It is here. It doesn't apply cleanly to the latest snowball git, but in September I have made an attempt to rebase it against the current git master. My attempt is here — maybe not thoroughly tested.

@Sufrostico
Copy link
Author

@mitya57 Nice!

I also made one a few days ago, but yours looks way better.

@ojwb
Copy link
Member

ojwb commented Mar 30, 2016

There are really two things that need doing to have snowball as a good quality shared library.

The obvious one is to make the build system build a shared library.

The other (which hasn't been addressed here) is that the C code snowball currently generates contains a lot of relocations due to the many arrays of string literals. These result in a load time penalty (as the dynamic loader has to perform these relocations), and a memory overhead (as the pages containing these relocations can't be shared between different processes which have the snowball library loaded). And the problem gets worse for each new stemmer that is contributed.

For more details of these relocations, see section 2.4.3 of this document:

https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf

I actually solved this in a somewhat primitive but effective way many years ago for the fork of snowball we use in Xapian (the reason why we ended up with a fork was that it was sometimes hard to get Martin to accept patches, especially as he was often very busy with other things).

Since I took over as maintainer I've been gradually merging changes from the fork back in to the main tree, with the hope that eventually Xapian could just use upstream snowball, but this one is still to do.

@emirotin
Copy link

Looks like this is related: abiliojr/fts5-snowball#4
I managed to compile it (the downstream sqlite ext which first requires the snowball to be compiled) into an .so which seems to work fine for me

@dvershinin
Copy link

FYI, for RedHat Enterprise Linux 7 based systems, there is libstemmer in EPEL repository.
Which installs the shared library /usr/lib64/libstemmer.so.0

@amirouche
Copy link

Any update on this?

@amirouche
Copy link

a pkg-config .pc would be nice too.

@amirouche
Copy link

I packaged snowball stemmer for guix (not yet in official tree). You can find the package definition at https://git.sr.ht/~amz3/guix-amz3-channel/tree/master/amz3/language.scm#L71

            (apply invoke "gcc" "-o" "libstemmer.so"
                    "-shared"
                    "libstemmer/libstemmer.o"
                    (append
                     (find-files "src_c"  ".\\.o$")
                     (find-files "runtime"  ".\\.o$")))

algitbot pushed a commit to alpinelinux/aports that referenced this issue Nov 1, 2020
The included patch for enabling dynamic lib is an upstream issue:
snowballstem/snowball#34
arkamar added a commit to arkamar/gentoo that referenced this issue Nov 10, 2021
It was necessary to rebase shared-library patch due to changes in
snowball-stemmer GNUmakefile.

Upstream-issue: snowballstem/snowball#34
Signed-off-by: Petr Vaněk <[email protected]>
arkamar added a commit to arkamar/gentoo that referenced this issue Nov 10, 2021
It was necessary to rebase shared-library patch due to changes in
snowball-stemmer GNUmakefile.

Upstream-issue: snowballstem/snowball#34
Signed-off-by: Petr Vaněk <[email protected]>
gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Nov 22, 2021
It was necessary to rebase shared-library patch due to changes in
snowball-stemmer GNUmakefile.

Upstream-issue: snowballstem/snowball#34
Signed-off-by: Petr Vaněk <[email protected]>
Closes: #22880
Signed-off-by: Sam James <[email protected]>
a16bitsysop added a commit to a16bitsysop/snowball that referenced this issue Dec 18, 2021
@a16bitsysop a16bitsysop linked a pull request Dec 18, 2021 that will close this issue
a16bitsysop added a commit to a16bitsysop/snowball that referenced this issue Dec 18, 2021
a16bitsysop added a commit to a16bitsysop/snowball that referenced this issue Dec 18, 2021
a16bitsysop added a commit to a16bitsysop/snowball that referenced this issue Dec 20, 2021
@ankane ankane mentioned this issue Mar 21, 2023
1 task
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 a pull request may close this issue.

6 participants