Asked  7 Months ago    Answers:  5   Viewed   31 times

I'm trying to compile my program and it returns this error :

usr/bin/ld: cannot find -l<nameOfTheLibrary>

in my makefile I use the command g++ and link to my library which is a symbolic link to my library located on an other directory.

Is there an option to add to make it work please?



If your library name is say and it is located on path say:


then to link it to your program:

g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
Tuesday, June 1, 2021
answered 7 Months ago

Sometimes there is issue while parsing google-services.json. I have reported this issue with to concerned team.

Meanwhile follow below step to fix this issue to get going further -

1) Open google-services.json file -> client -> oauth_client -> client_id

2) Copy this client ID and hardcode this .requestIdToken("your ID")

It would allow to request "IdToken" via GoogleSignInAccount post successful google login and to authorize your credential with firebase.


Try deleting and recreating the project and re-importing new google-service.jsonin your Android project

Monday, September 6, 2021
answered 3 Months ago

Symlinks on libraries work fine, as long as the final target they trace to exists and is accessible.

You have built a dynamically-linked executable, that wishes to be linked against at execution time. This was likely linked during the build phase with something like -L/path/to/libid3/directory -lid3.

You have a few options to make libid3 available, in generally decreasing order of preference (since you didn't mention where the file was, I can only be general):

  • Create a symlink to libid3* in a directory listed in /etc/ (or /lib or /usr/lib)
  • Copy libid3* to a directory listed in /etc/ (or /lib or /usr/lib) (defaults)
  • Add the directory containing libid3* to /etc/
  • Set LD_LIBRARY_PATH=/directory/path/to/libid3* before running your id3v2 executable.
  • Recompile id3v2 statically. (It will work, but don't bother.)

After any of the first 3, rerun ldconfig so the linker cache is updated. (You can then run ldconfig -v to verify it's resolvable.)

Note those aren't steps, they're options. You only need to do 1 of them.

Glad you updated the title. #include directives have nothing to do with linking.

Monday, September 20, 2021
answered 3 Months ago

One of your comments betrays that you are not using bash. You're using csh or tcsh. In that case, you can redirect all output (including standard error) like this:

g++ -c Algorithms.cpp >& output

For more csh redirection syntax, I have a useful link bookmarked. Note that csh redirection syntax is not as fluent as bash syntax. You can do more in bash than you can in csh.

Thursday, October 14, 2021
answered 2 Months ago

The FindControl method only looks in the current control for children.

If you don't know where in the page hierarchy the controls are, you'll need to do a recursive search - which is likely if you're using a templated control such as the TabContainer.

As I've posted previously to a similar answer:

private Control FindControlRecursive(Control rootControl, string controlID)
  if (rootControl.ID == controlID) {
    return rootControl;

  foreach (Control controlToSearch in rootControl.Controls)
    Control controlToReturn = 
      FindControlRecursive(controlToSearch, controlID);
    if (controlToReturn != null) { 
      return controlToReturn;

  return null;

Once you've got your control, you should cast it using as and then check for null just in case it's not quite what you were expecting:

var tabContainer = FindControlRecursively(myPage, "Workflow_TabContainer")
                 as AjaxControlToolkit.TabContainer

if (null != tabContainer) {
  // Do Stuff
Saturday, November 27, 2021
answered 3 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :