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.

Sign up for GitHub

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

OSX CC wrapper issues (RPATH, dynamic libraries) #1576

Closed
k6project opened this issue Jul 27, 2016 · 4 comments
Closed

OSX CC wrapper issues (RPATH, dynamic libraries) #1576

k6project opened this issue Jul 27, 2016 · 4 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: bug

Comments

@k6project
Copy link

I have encountered a number of issues while building:

  1. Multiple RPATH entries: when buildind cc_library and linking it against several pre-built third-party libraries (each library is provided as a cc_library rule with lib binary in "srcs" attribute), multiple "-Wl,-rpath" options are generated, but the CC wrapper for OSX seems to consider only one
  2. CC wrapper seems not to look for .dylib files when searching libraries, only *.so
  3. When substituting install names for libraries, wrapper fails in case install_name is not a pathname (for third party libraries can be simply libSomeLib.so). (might be better to just use otool -D | tail -1)
@damienmg
Copy link
Contributor

  1. is a duplicate of cc_library with .dylibs #407
  2. is a known issue but weird enough I cannot find a bug for it.
  3. is new to me.

@damienmg damienmg added type: bug P2 We'll consider working on this in future. (Assignee optional) category: rules > C++ labels Jul 27, 2016
@hlopko hlopko self-assigned this Aug 21, 2017
@hlopko
Copy link
Member

hlopko commented Aug 30, 2017

  1. fixed in f426544

Next to come :)

@hlopko hlopko mentioned this issue Aug 30, 2017
Closed
bazel-io pushed a commit that referenced this issue Oct 11, 2017
@hlopko
Fix osx_cc_wrapper to also update dylibs
0257c29 
In f426544 I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.

Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576

RELNOTES: None.
PiperOrigin-RevId: 171683650
bazel-io pushed a commit that referenced this issue Oct 11, 2017
@hlopko
Automated rollback of commit 0257c29.
52f32bf 
*** Reason for rollback ***

I broke http://ci.bazel.io/view/Dashboard/job/bazel-tests/1079/testReport/junit/(root)/(empty)/test_osx_cc_wrapper_rpaths_handling/

*** Original change description ***

Fix osx_cc_wrapper to also update dylibs

In f426544 I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.

Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576

RELNOTES: None.
PiperOrigin-RevId: 171806769
bazel-io pushed a commit that referenced this issue Oct 13, 2017
@hlopko
Fix osx_cc_wrapper to also update dylibs
600ab49 
In f426544 I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.

This is roll-forward of 0257c29.

Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576

RELNOTES: None.
PiperOrigin-RevId: 171969333
@hlopko
Copy link
Member

hlopko commented Mar 20, 2018

I declare 2. fixed :)
3 coming as soon as I have a free evening :)

@hlopko hlopko mentioned this issue Mar 20, 2018
Closed
@hlopko hlopko added team-Rules-CPP Issues for C++ rules and removed category: rules > C++ labels Oct 11, 2018
@hlopko hlopko removed their assignment Nov 28, 2018
@dslomov dslomov removed the bazel 1.0 label Jul 24, 2019
@c-mita c-mita added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed P2 We'll consider working on this in future. (Assignee optional) labels Nov 24, 2020
@sgowroji
Copy link
Member

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@hlopko @k6project @damienmg @c-mita @dslomov @sgowroji