none
Popper-glib on latest red hat RRS feed

  • General discussion

  • I know someone might want to tell me to ask Oracle or Redhat for that matter but they would say I should ask Mr. VS instead.

    I am deploying my software to many Linux (X) flavors, locally and on clouds with VS.

    It becomes a game of how fast I can take unknown instance be it LAN or WAN IP, and go through to the end.

    You get to meet many interesting blocks and after you meet them once, you learn forever your lesson.

    One block is the "linker dependency list" of libraries to link with on the instance. My list serves well with all X flavors. Some times it will pre exist and sometimes you just apt get or yum to have it and link to it.

    Having said that, I am quite proud to have worked it out with so many distros with a face and without a face. I have entered X programming very late in the game, just this year. Before that, I have to recall my Unix days with a VAX on campus. And I must say that in 2020 any Windows programmer is also an X programmer. And while most of them suffered development directly on X, I decided to wait until VS will do it, just the way they do it now - the greatest contribution in the history of FOSS. And X my friends, is mostly faceless for most of us..as we would not spend a second using X for our productivity.

    And having said all of that brings me to this particular block.....I can not link with lib popper-glib on latest Oracle Linux which is Redhat, locally  - on OCI no problems dudes !

    VS reports not found while I can see all the popper libs inside usr/lib64

    If you are just a Windows programmer without active cross pollination with X, please ignore this thread.

    • Changed type Ben4212 Sunday, December 15, 2019 4:25 PM
    Saturday, November 23, 2019 10:30 AM

All replies

  • When trying to help with any question, information is the key. Unfortunately I am unable to discern any real information beyond you getting a linker error.

    The issue here is that for Linux projects, Visual Studio copies the sources to the Linux machine/VM and then runs the compiler there. What this means is that if this fails when being built with Visual Studio then it shows that there is something wrong with the compiler on the Linux system. So it isn't Visual Studio reporting this as not found, it is GCC on the remote system reporting that this isn't found.

    So I would suggest that first you try building this locally on the Linux system. If this succeeds then you should check the logs to see what commands Visual Studio is sending to the remote machine.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, November 24, 2019 1:28 AM
  • I know someone might want to tell me to ask Oracle or Redhat for that matter but they would say I should ask Mr. VS instead.

    Don't listen to them all - go right to Stack Overflow. They got the answers.

    -- pa

    Sunday, November 24, 2019 1:53 AM
  • "try building this locally on the Linux system" -- not an option for me as I do not know how to do that.

    "there is something wrong with the compiler on the Linux system" -- The ld command comes back with poppler-glib not found. So compilation has ended successfully and we are now at link time over there.

    • Edited by Ben4212 Sunday, November 24, 2019 10:46 AM
    Sunday, November 24, 2019 10:28 AM
  • I do try to avoid SO like the plague....if I can.....I would use SO as last resort, provided I feel desperate. Which I am not in this case. I would just ditch the Oracle option for desktops and focus just on deb. For a year or two. Then I would try to fight it out again. Lets hope someone had this issue and could just show me what to do.
    Sunday, November 24, 2019 10:43 AM
  • The ld command comes back with poppler-glib not found. So compilation has ended successfully and we are now at link time over there.

    This kind of response shows that you are not used to using the Linux compilers.

    While with VC we often use the linker directly, if you don't pass the /c option to cl.exe then it will invoke the linker directly after the compiler finishes the compilation. You can also do this with VC:

    I didn't use the /nologo command line option here to show what was happening. But as you can see, the second invocation of cl doesn't have the /c option and a .obj file is passed in. The compiler front end sees this and invokes the linker.

    Now this model is much more common on Linux. If you check the Linux project's log, the command line that it uses to link is something along the lines of:

    g++ -o "/home/pi/projects/LinuxTest/bin/ARM/Debug/LinuxTest.out" -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack /home/pi/projects/LinuxTest/obj/ARM/Debug/main.o

    Yes, that is g++, the GCC c++ compiler front end. So it is using the compiler to do the linking. But before you think "aha, that's the problem" there is another big difference between Visual C++ and GCC.

    Visual C++ uses environment variables to set the location of library directories.

    The linker will look at the %LIB% environment variable and use this to search for library files. But the problem with this approach is that there are no default paths. However:

    GCC has these paths built into a spec file. To be honest, I'm not too sure if ld has this concept of default paths and I think GCC may pass these paths along to ld. I could be wrong on this point though.

    But either way on Linux the compiler front end is used to invoke the linker and the compiler front end has the default library paths set. So when I say that this is a compiler problem I actually mean compiler. But if you want to be really picky then I'll correct myself. This means that there is something wrong with the build tools on the Linux system.

    But there is one thing about the search directories that I noticed with the Debian system that I was using to test things out. It is also in the last screenshot above. Debian defaults to 64 bit, this means that the search paths that it printed out above was for the 64 bit builds. Notice how in the search paths there is no /usr/lib64? It sees /usr/lib as the 64 bit directory and if you check the paths for the 32 bit compiler:

    It uses /usr/lib32. So I'm not sure that this is the same with the Red Hat distros, but it is possible that /usr/lib64 is not in the path since it sees /usr/lib as the 64 bit library directory.

    Also finally:

    not an option for me as I do not know how to do that.

    It is always an option to learn something new. I am primarily a Windows developer and I only know what I know about GCC because I sat down and figured things out. If you want to keep developing for Linux then eventually you are going to be forced to learn about it.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Sunday, November 24, 2019 3:19 PM
    Sunday, November 24, 2019 3:08 PM
  • Not so fast Dylan. What on Earth in the above makes you think we got an answer? This is not a social network like SO.

    "but it is possible that /usr/lib64 is not in the path" -- we must think like detectives. Detectives do not complain there is not enough data. They take the data provided and infer from it. A detective could ignore the evidence -- we have solid rock deploy that deploys on many types of X. The very same VS is used and we get same results. The only type of CLI adjustment is sometimes using apt-get or yum. Now here we have this decrepit instance that refuses to link by just one lib. The answer must be done on Windows, either with putty if you know about some funky CLI that would resolve the situation on this fresh out the box instance...or we may need to modify some VS project options.

    Another thing, detectives, is that I have several libs and they link well, such as cairo, and just this one poppler is not found while it exists. Please stay within the bounds of remote X development on VS.

    • Edited by Ben4212 Wednesday, November 27, 2019 7:00 PM
    Monday, November 25, 2019 10:21 AM
  • Well, if you want to talk about detectives then I will mention that a detective is only ever as good as their ability to process information.

    As a detective I also can't help but see you as an unreliable witness because since the conversation was about /usr/lib64 then this means that we are talking about 64 bit builds of an application, but then you go and give the paths reported by gcc -m32. The -m32 command line option for GCC tells it to use the 32 bit compiler and so it would never look in /usr/lib64.

    Now I am forced to ask if you have set Visual Studio to build for x64. If it is building for x86 then you should be looking for the presence of that library in either /usr/lib or /usr/lib32 if the latter exists.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, November 25, 2019 3:24 PM
  • Darran can you erase your presence from this thread? People are mislead to believe it is handled when it is not, just because they see lots of words....Thank you.
    Sunday, December 15, 2019 4:23 PM