Hopefully not too obvious

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • mijte
    New Member
    • Feb 2008
    • 3

    Hopefully not too obvious

    Hello everyone, I will state right from the beginning I am not a trained programmer and I am trying my best to learn as I go. Anyway, I have an application that I am trying to compile for distribution across a few distributions of Linux. I am running into problems with dependencies on particular libraries. If I compile the application normally it links (forgive me if I mix up the terms) against the libraries on the system I am compiling on. For instance here is an ldd of the application on the compiler system:

    ldd vtpos
    libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4002e000)
    libXm.so.2 => /usr/X11R6/lib/libXm.so.2 (0x400f8000)
    libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40274000)
    libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x402c5000)
    libfreetype.so. 6 => /usr/lib/libfreetype.so. 6 (0x402d7000)
    libz.so.1 => /usr/lib/libz.so.1 (0x40341000)
    libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40352000)
    libm.so.6 => /lib/libm.so.6 (0x4035a000)
    libc.so.6 => /lib/libc.so.6 (0x4037e000)
    libdl.so.2 => /lib/libdl.so.2 (0x4049b000)
    libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4049f000)
    libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x404a7000)
    libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x404bf000)
    libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x404c7000)
    libfontconfig.s o.1 => /usr/X11R6/lib/libfontconfig.s o.1 (0x404d6000)
    libexpat.so.0 => /usr/lib/libexpat.so.0 (0x404fd000)
    /lib/ld-linux.so.2 (0x40000000)

    In particular the box I want to distribute this to lacks libXft.so.2, it has libxft.so.1 on it. Initially when I tried to distribute this to the other system there was an issue with libstdc++.so.5, but I was able to solve that by statically linking the binary by adding the following to my "LINK" line in the Makefile after creating a symlink for libstdc++.a "-static-libgcc -L.". Now the box that I am compiling on has libxft.so.1 and libxft.so.2, so my question is how do I get this application to either link against .so.1 or statically compile it? I have tried a bunch of methods but I am just so lost. I know this application can be compiled without the need for libxft.so.2 since I have a pre-compiled version from the same source code that does not depend on it that was created by a former programmer that we no longer employ. Please help?
  • edwardrsmith
    New Member
    • Feb 2008
    • 62

    #2
    Have you tried compiling your code without linking it and then having linking all the files on the target machine using the make file. This should allow you to specify which source files to use and could possibly solve your problem.

    Comment

    • mijte
      New Member
      • Feb 2008
      • 3

      #3
      Originally posted by edwardrsmith
      Have you tried compiling your code without linking it and then having linking all the files on the target machine using the make file. This should allow you to specify which source files to use and could possibly solve your problem.
      This is where I get lost and I apologize for doing so. I wouldn't even know how to compile without linking. Further I wouldn't know how to link once I get to the source machine. If I cannot figure this out I would definitely like to contract someone to help me through this so I can carry it forward.

      Comment

      • mac11
        Contributor
        • Apr 2007
        • 256

        #4
        I'll try to help...

        Now the box that I am compiling on has libxft.so.1 and libxft.so.2, so my question is how do I get this application to either link against .so.1 or statically compile it?
        Somewhere in your makefile it's being told to use libxft.so.2 instead of .so.1. Do you know how the makefile knows to link libxft? (for example, you might be using pkg-config). I can't tell you right off the top of my head how to change it. Maybe you can post a section of your makefile?

        Also, you can link things statically using "-static" according to the documents at http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

        Comment

        • mijte
          New Member
          • Feb 2008
          • 3

          #5
          Originally posted by mac11
          I'll try to help...



          Somewhere in your makefile it's being told to use libxft.so.2 instead of .so.1. Do you know how the makefile knows to link libxft? (for example, you might be using pkg-config). I can't tell you right off the top of my head how to change it. Maybe you can post a section of your makefile?

          Also, you can link things statically using "-static" according to the documents at http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
          I can elaborate a little, there are actually a few seperate programs in my source code that compile, I will focus on one in particular, the Makefile sections that seem relevant are:

          CC = g++ $(DBGFLAG) -c -o $@ $(INCDIRS) $(CREDIT_INC)
          LINK = g++ $(DBGFLAG) -o $@

          LIB_PATH = -L/usr/local/lib -L/usr/lib -L/usr/X11R6/lib

          LOADER_OBJS = loader/loader_main.o debug.o main/labels.o generic_char.o \
          logger.o

          vtpos: $(LOADER_OBJS)
          $(LINK) $^ $(LIB_PATH) -lX11 -lXm -lXt -lXft -lfreetype -lz -lfontconfig -lXrender $(CREDIT_LIB) $(MALLOC_LIB)

          Therefore when I "make vtpos" it first compiles .o files for the LOADER_OBJS (loader_main.o, labels.o) etc and then links them into the final vtpos. I really cannot see anywhere in the Makefile where it is specifically mentioning libXft.so.2 versus libxft.so.1, I think it is by default linking to the most recent although I really cannot be sure. I have also tried various combinations of -static all resulting in miserable failure.

          What I did try was to remove the linking against libXft.so.2 all together by changing the Link line to:

          LINK = g++ $(DBGFLAG) -Wl,-Bstatic -Xft -Wl,-Bdynamic -static-libgcc -L. -o $@

          Also removing the -lXft from the vtpos definition and the compilation blew up completely with:

          loader/loader_main.o(. text+0x8d): In function `ExitLoader()':
          : undefined reference to `XftColorFree'

          And so on, therefore I suppose I cannot do it that way.

          Comment

          Working...