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

Wrong GCC configure flag #991

Open
damianam opened this issue Sep 13, 2016 · 5 comments
Open

Wrong GCC configure flag #991

damianam opened this issue Sep 13, 2016 · 5 comments
Milestone

Comments

@damianam
Copy link
Member

GCC's configure has an option called --enable-plugin. The easyblock has it misspelled as --enable-plugins.

@boegel
Copy link
Member

boegel commented Sep 13, 2016

I guess the confusion comes from the binutils configure option, which is --enable-plugins.

@damianam how did you hit this? Any relevant error messages?

@boegel boegel added this to the v2.9.0 milestone Sep 13, 2016
@damianam
Copy link
Member Author

Long story short: I have a binary package that fails with our EB compiled cURL (can't find a particular versioned symbol). I tracked down the issue to the compiler used to compile GCC. The system GCC produces a libcurl.so that works, the EB GCC doesn't. Compiler version is not the issue, so I am investigating how the compilers have been built. That's when I stumbled upon this. Depending on what else I find, you might get another open issue here :-P

@damianam
Copy link
Member Author

Further updates:

--enable-gold and --enable-ld are binutils options, not GCC options. GCC, GDB and binutils share the same top level configure script, which sucks if you ask me. I think we can safely remove these options from gcc.py

--with-plugin-ld=ld.gold defaults GCC to use ld.gold. However, in binutils.py the default linker chosen is GNU ld: --enable-ld=default. This seems like a contradiction between default behaviour for both packages. In most cases it doesn't matter I guess, and --with-plugin-ld=ld.gold takes precedence.

The issue I had with the aforementioned binary package seems to be related to the fact that the binary was linked with GNU ld, as well as the libcurl.so that came with the system. Linking libcurl.so with ld.gold seems to cause that symbol versioning incompatibility (libcurl.so.4: version 'CURL_OPENSSL_3' not found), but I don't fully understand why.

@boegel
Copy link
Member

boegel commented Sep 14, 2016

@wpoely86 thoughts on this?

@wpoely86
Copy link
Member

Yeah, I noticed the ld.gold weirdness too but haven't change it yet. We should default to gold everywhere. And drop the binutils flags. I will give it a spin and see if we end up with the binary binary.

@damianam It's know that ld.gold does not always produce the same results as bfd. There is already a code in EB that needs bfd to work.

@boegel boegel modified the milestones: v2.x, v2.9.0 Sep 16, 2016
@boegel boegel modified the milestones: 3.x, 4.x Feb 20, 2020
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

3 participants