Есть ли способ разделить исполняемый файл Go на несколько файлов?

Question

Я отправляю несколько исполняемых файлов, скомпилированных с Go. Каждый исполняемый файл сам по себе не содержит большого количества кода, но каждый из них использует общую библиотеку, которая включает ведение журнала, управление конфигурацией, уровень связи и т. Д. *

Это приводит к тому, что каждый исполняемый файл занимает от 15 до 20 Мб, иногда для всего лишь 1000 собственных строк кода.

Есть ли в Go способ (в настоящее время доступный или запланированный для будущей версии), который позволит разделить приложение на несколько файлов (например, dll в Windows, .so Linux / Mac)?

Я знаю, что могу скомпилировать библиотеку и затем использовать ее как внешний двоичный файл, но тогда я не получу преимуществ от системы типов и оптимизации компилятора Go. Я здесь не прав, и есть способ сделать это?

Answer 1

Вещи, которые вы отправляете, тесно связаны друг с другом? Если это так, то может иметь смысл объединить их в один исполняемый файл, который принимает команды в командной строке, чтобы решить, какой «исполняемый файл» начать выполнять.

Таким образом, вместо отправки 'cmd1' и 'cmd2' и 'cmd3', вы просто отправляете одну программу, которая может быть вызвана таким образом

$ prog cmd1

$ prog cmd2

$ prog cmd3

Вам нужно проделать дополнительную работу, чтобы разобрать первый аргумент и решить, какую подкоманду запустить.

Answer 2

Краткий ответ: Вид?

Звучит так, как будто вы пытаетесь создать общую библиотеку.

Компилятор Go может создавать общие библиотеки с 1.5 с флагом сборки -buildmode=c-shared:

go build -o helloworld.so -buildmode=c-shared

И, начиная с Go 1.10 , эта функциональность дополнительно поддерживается в Windows

Итак, компиляция в DLL тоже однострочная:

go build -o helloworld.dll -buildmode=c-shared

Проблема, с которой вы столкнетесь, на самом деле с использованием этих библиотек, особенно в кросс-операционной системе:

В * nix вы можете использовать CGO для этого:

package example

// #cgo LDFLAGS: -lfoo
//
// #include <foo.h>
import "C"

func main() {
    C.bar()
}

Windows получает свой собственный Wiki (кто удивлен?).

Я оставлю вам несколько мыслей по этому поводу:

1. Там ничего неправильно с бинарным файлом 15-20 Мб (хотя, вы должны попробовать upx , чтобы сбрить часть этого жира, потому что почему бы и нет?), Вы должны быть обеспокоены, когда вы Нажимаем 10-е из 100-х концертов. Пространство дешево в наши дни.
2. Запись чего-то, что может быть скомпилировано в один двоичный файл, независимо от ОС, является одним из лучших преимуществ Go.
3. CGO_ENABLED=0 экономит массу места в ваших двоичных файлах. Включение его (что необходимо для использования этих функций) не оказывает вам никакой пользы.
4. Вы правы, предполагая, что, поскольку компилятор не может оптимизировать для включенных библиотек, в конечном итоге вы не сэкономите много, если вообще места, в небольших случаях использования.

Мое последнее замечание, тогда я перестану проповедовать вам: сосредоточьтесь на написании кода. Двоичный размер не должен беспокоить вас, если вы не пытаетесь установить его на встроенные устройства.

Удачи, друг.