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

Static linking? #13

Open
Mstrodl opened this issue Apr 5, 2021 · 5 comments
Open

Static linking? #13

Mstrodl opened this issue Apr 5, 2021 · 5 comments

Comments

@Mstrodl
Copy link

Mstrodl commented Apr 5, 2021

saldl -v

git @ 0926ac1

Describe the issue / How to reproduce

As far as I can tell, it doesn't seem possible to compile saldl statically... It would be really nice to have statically linked binaries available for download because the curl dependency can be hard to manage on some systems (particularly older Debians or even modern Ubuntu). Saldl is particularly useful to me as a time saver but I'm not sure there's much of a net gain if I'm spending all my time just trying to get it to compile...

log output (if needed)

My attempt seemed to almost work until I got to linking... Eek! image

@Mstrodl
Copy link
Author

Mstrodl commented Apr 5, 2021

Actually adding -fcommon made my (shared library) build at least work on alpine (turns out it was a shared library issue too)

@MoSal MoSal closed this as completed in 03acf11 Apr 6, 2021
@MoSal
Copy link
Member

MoSal commented Apr 6, 2021

Thank you for reporting this.

The -fcommon fix is pushed. Are there any other issues with static linking?

@Mstrodl
Copy link
Author

Mstrodl commented Apr 6, 2021

@MoSal I'm not sure, -static seemed to cause a bunch of issues... Ideally I think there should be a publicly available build statically linked available for download ^^

@Mstrodl
Copy link
Author

Mstrodl commented Apr 6, 2021

After looking at what you did: you REALLY should be using extern to fix the cases at the source rather than just forcing -fcommon....

@MoSal MoSal reopened this Apr 6, 2021
@Mstrodl
Copy link
Author

Mstrodl commented Apr 6, 2021

From the docs:

In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage.

The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit.

The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors.

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

No branches or pull requests

2 participants