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

Jump to bottom

Use static linking against protobuf even for Linux version of Mozc #14

Closed
GoogleCodeExporter opened this issue Apr 22, 2015 · 1 comment
Closed

Use static linking against protobuf even for Linux version of Mozc #14

GoogleCodeExporter opened this issue Apr 22, 2015 · 1 comment
Labels
auto-migrated OpSys-Linux Priority-Medium Type-Defect

Comments

@GoogleCodeExporter
Copy link 

In related to the previous issue #13, please consider using statically linking 
with protobuf even for the Linux version of Mozc.

I request this because of the design of protobuf not to handle "bundle modules 
linking with protobuf" by dlopen(3) decently (related to issue #128 of 
protobuf).  Specifically for mozc_tool in Linux, which uses Qt4 library as a 
GUI frontend and of course linking with shared protobuf library, it loads 
bundle modules with dlopen(3) when creating a input context.  And as input 
module of uim for Qt do dlopen uim-mozc bundle (which is also linking with 
shared protobuf library dynamically) at that time, it will cause crash of 
protobuf as follows.

    libprotobuf ERROR google/protobuf/descriptor_database.cc:56] File already exists in database: session/config.proto
    libprotobuf FATAL google/protobuf/descriptor.cc:857] CHECK failed: generated_database_->Add(encoded_file_descriptor, size):

I think this can be solved by using mozc_tool with protobuf library linked 
statically.

Cheers,

Original issue reported on code.google.com by ek.k...@gmail.com on 17 Jun 2010 at 3:44
@GoogleCodeExporter
Copy link
Author 

Thank you for the report and sorry for our late response.
In r96, we changed DEPS file and common.gypi so that protobuf can be statically 
linked to Mozc's executables and loadable modules.
I hope this helps you and users who suffered from this problem.

Another news is that we have recently fixed Issue 115 on our internal 
repository and are planning to ship it as a part of next push. If I understood 
correctly, all the remaining issues around dlopen(3) should be resolved in the 
next release. Thanks again for your reports.

Just FYI, people who want to continue to use libprotobuf.so can override the 
'use_libprotobuf' defined in common.gypi as follows.
% GYP_DEFINES="use_libprotobuf=1" python build_mozc.py gyp
Basically you need not to directly patch common.gypi to override gyp variables 
as long as the variable is defined with "default value". 
(http://code.google.com/p/gyp/wiki/InputFormatReference#Providing_Default_Values
_for_Variables_(%) describes the details)
Actually, overriding gyp variables through GYP_DEFINES is a common technique 
used in Chromium development.
  http://www.google.co.jp/webhp?ion=1#hl=ja&output=search&q=GYP_DEFINES%20Chrome
I also hope this helps you when you need to tweak our common.gpyi file.

Original comment by yukawa@google.com on 7 Mar 2012 at 5:02

  • Changed state: Fixed
  • Added labels: OpSys-Linux

@yukawa yukawa mentioned this issue Sep 27, 2016
Closed
shitamo pushed a commit to shitamo/mozc that referenced this issue Jun 4, 2022
@wengxt
Use a different icon for ui-direct.
444a7e1 
Fix google#14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated OpSys-Linux Priority-Medium Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter