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

cmd/go: remove -buildmode=shared (not c-shared) #47788

Open
rsc opened this issue Aug 18, 2021 · 16 comments
Open

cmd/go: remove -buildmode=shared (not c-shared) #47788

rsc opened this issue Aug 18, 2021 · 16 comments

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Aug 18, 2021

-buildmode=shared has been broken since modules, and it is apparently unused.
See #47257 (comment).
Let's remove it.

@gopherbot gopherbot added this to the Proposal milestone Aug 18, 2021
@rsc rsc added this to Incoming in Proposals Aug 18, 2021
@rsc
Copy link
Contributor Author

@rsc rsc commented Aug 18, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc rsc moved this from Incoming to Active in Proposals Aug 18, 2021
@electricface
Copy link

@electricface electricface commented Aug 19, 2021

I really want to use this buildmode=shared mode.

@scott-cotton
Copy link

@scott-cotton scott-cotton commented Aug 19, 2021

@rsc how has it been broken since modules?

@ainar-g
Copy link
Contributor

@ainar-g ainar-g commented Aug 19, 2021

Just to clarify, this is not related to --buildmode=plugin, right?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 19, 2021

@electricface Why do you want to use it? Are you using it today?

@scott-cotton You can't use -buildmode=shared with a module and then use -linkshared to link against it from other modules. The whole idea of -buildmode=shared doesn't fit very well with modules. Each separate program can be linked against different versions of dependent modules, so if it did work people would in practice wind up with many different versions of the shared libraries of the same modules.

@ainar-g Correct, this is not about -buildmode=plugin, although plugins have their own, different, problems.

@electricface
Copy link

@electricface electricface commented Aug 20, 2021

@ianlancetaylor
I am a debian-baseed Linux Desktop Environment developer. Our team have developed lot of daemon programs with golang. But these programs have significantly larger binary file size and use more ram than C or C++ programs. We currently working on these two problems. An idea is making some modules pluggable, which means only load modules that we need.

As other C or C++ programs are using shared-library, we are researching on some shared-library-like mechanism of golang. Inspired by buildmode=plugin and goloader, we found a way that bases on buildmode=shared to make modules pluggable recently, you can found a demo here. This solution has not been using in production environment, because of some problems hasn't been solved yet. I found out that programs built with -linkeshared can not be debugged using gdb and dlv.

After this commit, our "unoffical plugin" solution can work fine with go 1.14.9~1.16.7. Programs built in this way can run stably. But this won't work on go 1.17. Program will exit with a "fatal error: unreachable method called. linker bug?"

Plan of remove buildmode=shared make me feel bad.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 20, 2021

@electricface It sounds like you want plugins, which are supported (though not very well) by -buildmode=plugin. We aren't going to support -buildmode=shared just to support plugins, since we already have -buildmode=plugin.

@electricface
Copy link

@electricface electricface commented Aug 21, 2021

@ianlancetaylor
I know that using static linking can eliminate the problems caused by the mismatched version of the dependent dynamic library.
But in the linux desktop system ecosystem, C or C++ languages are mostly used. These languages generally use dynamic libraries to save memory. The main reason for not using -buildmode=plugin is that static linking cannot save memory. For example, if the modules are divided into smaller ones and a lot of modules are added, each module occupies a relatively large amount of memory, and the overall occupancy will eventually become unacceptably large. Compared with C or C++ languages, they only use less memory to implement these functions, while the golang implementation uses several times the memory.
There is even an idea in our team that we must change the development language if we can't reduce the memory. I personally like to use golang for development, so I plan to study this part of the technology.

@rsc
Copy link
Contributor Author

@rsc rsc commented Aug 25, 2021

"I want to use it" is different from "I am using it today".
We believe that it is not possible to use it today, and furthermore it is difficult to provide.
We shouldn't advertise something that doesn't actually work.

@rsc rsc moved this from Active to Likely Accept in Proposals Aug 25, 2021
@rsc
Copy link
Contributor Author

@rsc rsc commented Aug 25, 2021

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

@mewmew
Copy link
Contributor

@mewmew mewmew commented Aug 25, 2021

Just to confirm, this proposal suggests to remove --buildmode=shared while keeping --buildmode=c-shared? I am using --buildmode=c-shared for a number of projects and would be very sad to see it go.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 25, 2021

This proposal is only about -buildmode=shared.

@rsc rsc changed the title proposal: cmd/go: remove -buildmode=shared proposal: cmd/go: remove -buildmode=shared (not c-shared) Sep 1, 2021
@rsc rsc moved this from Likely Accept to Accepted in Proposals Sep 1, 2021
@rsc
Copy link
Contributor Author

@rsc rsc commented Sep 1, 2021

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc rsc changed the title proposal: cmd/go: remove -buildmode=shared (not c-shared) cmd/go: remove -buildmode=shared (not c-shared) Sep 1, 2021
@rsc rsc removed this from the Proposal milestone Sep 1, 2021
@rsc rsc added this to the Backlog milestone Sep 1, 2021
@bcmills bcmills removed this from the Backlog milestone Sep 1, 2021
@bcmills bcmills added this to the Go1.18 milestone Sep 1, 2021
@rasky
Copy link
Member

@rasky rasky commented Sep 2, 2021

@rsc not sure if this is a good place to give feedback about the proposal process, but this is the first time (since the proposal process exists) that I missed an issue. I was mildly interested in this (not enough now to vehemently protest), but even if I'm subscribed to the proposal process issue and I normally read minutes every week, I missed this. I took 10 days off for vacation, and those 10 days covered the only 2 emails where this issue was mentioned, before today when it was approved. Again, I don't mind about this specific issue at this point but I wanted to raise a general point.

Maybe a proposal should stay a minimum time in the proposal process before being closed, so that even people that don't work on Go full time have time to notice and react even with personal life happening in-between.

@zhouguangyuan0718
Copy link
Contributor

@zhouguangyuan0718 zhouguangyuan0718 commented Sep 9, 2021

To limit binary file size, I use command go install -buildmode=shared std to install libstd.so. And I build my application by go build -linkshared. I have been using this in production environment for a long time. I hope I can still use it in the furture.
Can we keep -buildmode=shared std, it's useful.

@Jason7602
Copy link

@Jason7602 Jason7602 commented Sep 9, 2021

Our company has been using the shared mode to reduce the binary size for a long time. The plugin mode is not useful in some scenarios cause the entire runtime package needs to be compiled and packed. So we strongly hope that shared mode can be reserved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Linked pull requests

Successfully merging a pull request may close this issue.

None yet