-
-
Notifications
You must be signed in to change notification settings - Fork 306
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
Blacklist executables #320
Comments
Hey @smhc , thanks for the extensive testing of this tool. I really appreciate it! As far as I know, wine is a 32 bit executable. And the dynamic linker error message is about that you want to LD_PRELOAD a 64 bit library. This was a known issue with the earlier releases. And there was a recipe to build both 32bit and 64bit libraries and use the one which is appropriate... The 3.0 series is not that mature yet. I would re-phrase this ticket as "support multilib builds". (Or we can create a new ticket.) But I am interested how is your build would work? Is it calling wine in the middle of the build? And compiles some source files to Windows and then it continues on Linux? And I am also interested how would you imagine to stop intercepting the command executions in the middle of the build. Are we talking about a call like |
I have a build script that compiles many projects in parallel. It uses make/gcc to compile 64bit Linux binaries, but it also calls wine to run a Windows compiler to compile Windows exectuables. I use bear on this top level wrapper script and it augments all the compilation appropriately. I could call bear separately for each module and skip the wine projects - however there would be a lot of contention given that the modules are built in parallel. Ideally I'd like to tell bear not to use LD_PRELOAD when compiling those problematic modules - or alternatively, blacklist particular executable names.
Yes something like that. However it doesn't need to 'stop' and 'resume'. It just needs to not add the LD_PRELOAD env variable when starting a new exectuable of an ignored name. Obviously you would lose the ability to hook exec calls from that point onwards in that process tree - but I think that is desired behaviour. I envision this line:
would have an if condition to remove the LD_PRELOAD environment variable rather than add it in when it matches a particular exe name. |
Describe the bug
Some executables are problematic with LD_PRELOAD and will log errors (or potentially fail?). This can be avoided by using the wrapper compilers, or avoiding using bear for those exectuables, but the ability to blacklist them would be easier.
To Reproduce
The 'wine' executable cannot use the LD_PRELOAD system. If your build uses wine and a windows compiler as part of the build there will be excessive errors. e.g
Expected behavior
The LD_PRELOAD should not be set for exectuables that have known problems, or explicitly listed as being problematic. This could also be used to avoid processing large parts of a build that are not expected to perform c/c++ compilation.
Environment:
Additional context
Before you send...
README.md
file orman bear
? YThe text was updated successfully, but these errors were encountered: