More questions regarding compiling extensions


Forum: Apps
Topic: More questions regarding compiling extensions
started by: b1ackmai1er

Posted by b1ackmai1er on Sep. 07 2007,16:00
Hello again,

I want to include some library files in an extension.

What directory should I compile these for?

By default they compile to /usr/local/lib and /usr/local/include.

Will my application find these automatically?

Would I be better of making these libraries seperate extensions? (There are four- freetype, jpeg, zlib, libpng)

Thanks Phil

Posted by lucky13 on Sep. 07 2007,16:27
What kind (dsl/unc, tar.gz/uci) of extension? If dsl/unc, you should compile with a suitable prefix for such an extension -- /usr. The default compile path /usr/local should be used for things exclusive to a local host; that's why binary distributions like Debian and RedHat install to /usr.

Edit (oops): The other two kinds of extensions should be self-contained, so whatever libs you add will need to go into the same /opt/extname prefix when you compile.

As for the libs you listed, aren't they already in DSL?
< http://damnsmalllinux.org/packages.html >
(remember to keep it damn small and don't duplicate what's already in it)

Posted by mikshaw on Sep. 07 2007,22:40
For uci/tar.gz:

I've noticed that some applications, depending on how they are compiled, will automatically find their needed libraries if those libraries are 1) pointed to by CFLAGS/CPPFLAGS and LDFLAGS when the application is compiled, and 2) those variables point to directories included with the application.

Some applications don't deal with this, though.  I really couldn't say why some do and some don't...I just see it work sometimes.

When compiling lighttpd into /opt/lighttpd after installing pcre to the same directory, and setting LDFLAGS=-L/opt/lighttpd/lib, PATH=$PATH:/opt/lighttpd/bin and CFLAGS=-I/opt/lighttpd/include, the app will automatically find pcre at runtime. Otherwise it would require LD_LIBRARY_PATH=/opt/lighttpd/lib before running the program if pcre is enabled.

Other applications seem to require the LD_LIBRARY_PATH to include the directory of the library at runtime regardless of whether or not it was specified when the app was built.  I assume this is due to the way the Makefile was created.

Posted by curaga on Sep. 08 2007,11:37
With a more permanent system, such as a debian-type or maybe frugal, you could add a new general library directory into /etc/ld.so.conf and all apps would find all libs in there automatically, but you must of course run "sudo ldconfig" after installing a library..

For example, I have qt in /opt/qt and have a line "/opt/qt/lib" in my ld.so.conf. No trouble compiling/running qt apps.

Posted by b1ackmai1er on Sep. 08 2007,15:51
Thanks guys for your help.

@lucky13: You are right, they look like they are built in. That makes my life alot simpler!

@mikshaw: I sort of understand what you mean but will have to work through it. My experience compiling at the moment is ./configure make make install!

The application I am working on (gnuplot) is compiled and running as a .tar.gz extension.

For simplicities sake, as a newbie, it seems that the simplest was to acheive what I want is to compile my library LibGD to /opt/gnuplot/lib and then recompile gnuplot telling it where the library is and rebuild my .tar.gz extension.

How does that sound?


regards phil

Posted by b1ackmai1er on Sep. 08 2007,16:27
Ok, so I have compiled my library so that it is now in /opt/gnuplot/lib/....

I gather I don't need the *.a files or the includes for a .tar.gz, just the libgd.so's

Now going to recopile gnuplot to see if can make it find the libraries.

Ok gnuplot now recognizes where the libraries are during the compile process but when I run gnuplot it can't find them.

Any feedback welcome

cheers phil

Posted by mikshaw on Sep. 08 2007,18:03
That's exactly the issue I was talking about. I'm sure there's a way to build the program to find the libs automatically at runtime, but I don't know how t do it. When I compile apps that need extra libs I just hope the program compiles that way, and if not i write a wrapper:
Code Sample
#!/bin/bash
export LD_LIBRARY_PATH="/opt/gnuplot/lib:$LD_LIBRARY_PATH"
exec /opt/gnuplot/bin/gnuplot

And then run the wrapper instead of directly running gnuplot

Posted by b1ackmai1er on Sep. 08 2007,18:33
Cool, thanks mikshaw, I will try that!

Yes! It works.

Ok, so now to use a wrapper I will have to move from a .tar.gz to a .UCI or .UNC?

Thanks heaps. Once again I can goto bed

Cheers Phil

Posted by b1ackmai1er on Sep. 09 2007,03:52
OK, I am awake again.

Still working through this issue.

Here are snippets of code from the 'make' output, with and without the library option.

More info: extraction from the make output with the --with-gd

g++  -g -O2  -L/opt/gnuplot/lib -o gnuplot  alloc.o axis.o breaders.o
bitmap.o color.o command.o contour.o datafile.o dynarray.o eval.o
fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o
history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o
plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o
specfun.o standard.o stdfn.o tables.o term.o time.o unset.o util.o
util3d.o variable.o version.o   -lreadline  -lncurses  -lz -lgd  -
ljpeg -lfreetype -lpng   -lm

extraction from the make output without the --with-gd

g++  -g -O2   -o gnuplot  alloc.o axis.o breaders.o bitmap.o color.o
command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o
getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o
interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o
pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o
stdfn.o tables.o term.o time.o unset.o util.o util3d.o variable.o
version.o   -lreadline  -lncurses  -lz   -lm

I was wondering if maybe the library command was not correct, maybe it should be


g++  -g -O2  LDFLAGS=-L/opt/gnuplot/lib -o gnuplot  alloc.o axis.o
breaders.o ect..

rather than g++  -g -O2  -L/opt/gnuplot/lib -o gnuplot  alloc.o axis.o
breaders.o etc..

Thanks Phil

Posted by b1ackmai1er on Sep. 09 2007,06:01
Nah, the LDFLAGS=-/L etc isn't right from what I can see in reference material on the web.

However, I did find that if I copy the files to the /opt/gnuplot directory, the program finds them when run from /opt/gnuplot/bin. Very strange.

Maybe I need to do something different when I compile the libraries?

I don't know ???

regards Phil

Posted by b1ackmai1er on Sep. 09 2007,06:07
BTW, whats the difference between EPREFIX and PREFIX?

cheers Phil

Posted by b1ackmai1er on Sep. 09 2007,06:58
Arrggghh, I think I have this figure out

When I compile my libraries I have to tell them where the library is.

i.e ./configure --prefix=/opt/gnuplot --libdir=/opt/gnuplot

Suddenly, my program works.

When I run LDD -v gnuplot to confirm the library path it displays:

libgd.so.2 => /opt/gnuplot/lib/libgd.so.2 (0x4008b000)

so it seems to be resolved.

However just looking in /usr/lib I found libgd.so.1 so maybe the library was there all along and I didn't need to compile it.

Arrrggghhh.

regards Phil

Posted by Juanito on Sep. 09 2007,07:43
Quote
BTW, whats the difference between EPREFIX and PREFIX?

This is so you can put the executable files in one place (eg /opt/app/bin) and other files in another place (eg /etc/app) - the readme, install or "./configure --help" will give a better explanation.

Quote
i.e ./configure --prefix=/opt/gnuplot --libdir=/opt/gnuplot

It might be better to use --prefix=/opt/gnuplot-1.2 or similar to avoid a clash when you submit an updated extension  :)

Posted by b1ackmai1er on Sep. 09 2007,12:19
Thanks for the explanation.

It seems I still have not resolved this. It seems it worked because I had previously set the environement variable for the path.

Back to the drawing board.

Posted by lucky13 on Sep. 09 2007,14:47
I've held back from posting because I'm not sure I understand what you're doing. The part where it appears you're redundantly adding --libdir to an identical --prefix makes me wonder if you understand what you're trying to do, too.

With the --prefix, you're already telling it to put its bin and lib and share and so on directories in /opt/gnuplot (so its lib will already be /opt/gnuplot/lib unless you tell it otherwise). If you're using those options for gnuplot that's telling it where to place its OWN libs if it has any, not your system libs (it should link to them automatically or you can force linking to them -- but you *won't* use --libdir to link to things already in the system). There's no need to duplicate what's in the system; you can link them with either --include-lib=path or --with-lib=path (read the documentation including ./configure --help) if they're not properly linked in your Makefile. If you're using those options for a non-system lib, just use the normal prefix without a --libdir (because it's going to put the lib in $prefix/lib).

I looked at gnuplot's faq yesterday and it says it's a standard ./configure; make; make install and I didn't see any quirky lib requirements listed. Paste in the line(s) you're using when you run configure for whichever libs (?) and gnuplot.

Posted by lucky13 on Sep. 10 2007,02:48
One more thing about the redundancy:
Quote
When I compile my libraries I have to tell them where the library is.

i.e ./configure --prefix=/opt/gnuplot --libdir=/opt/gnuplot

If that's what you're using for your libs (and not gnuplot), you're building a Makefile to install the lib in the parent prefix directory (e.g., /opt/gnuplot) rather than in lib directory (e.g., /opt/gnuplot/lib). There's really no practical reason to do that because you'll still have to link it (see below).

If you used that line to configure the Makefile for gnuplot, you're not telling it to LINK to existing libs in /opt/gnuplot, you're telling it to INSTALL gnuplot's libs (if it has any) there. That's what the libdir, mandir, bindir, etc., commands are for: to tell where to put those things.

If libgd is already in the system, it should be detected when you run configure. If it's there but not detected, modify the --with option below to suit your needs. If it's not already there, compile it first with the same prefix you'll use for your app. Leave the libdir option alone because libs should already install to /yourprefix/lib. Then when you compile gnuplot, link that --with-libgd=/prefix/lib (or however libgd is referenced -- there should be something in an INSTALL, README, or run ./configure --help | less).

Posted by b1ackmai1er on Sep. 10 2007,11:33
Hello Lucky13, I am glad you spoke up, I need all the help and advise I can get. Thanks for taking the time to do the research you did.

Yes, in principal I  realized that the --libdir was duplicating the --prefix option but I was trying everything I could do to force gnuplot to find the library I was compiling.

Basically compiling gnuplot out-of-the-box does not require this library. However, if I want to save a graph in jpeg, gif or png format I have to install the the "libgd" library and it's associated libraries that it uses.

i.e gnuplot-> libgd -> libpng, zlib, jpeg, freetype


DSL has the libpng, zlib, jpeg and freetype libraries built in, so I just need to compile the libgd library.

So I can compile the libgd with the standard ./configure --prefix=/opt/gnuplot/ and this will compile the libraries into /opt/gnuplot/lib without error

Then, I can compile gnuplot to /opt/gnuplot with ./configure --prefix=/opt/gnuplot --with-gd=/opt/gnu and it will recognize the switch and find the libraries and compile gnuplot into /opt/gnuplot/bin etc etc without error.

However, when I run the program it finds all standard libraries except the libgd one I just compiled. The --libdir stuff was just trying to find ways to get it recognize the library in /opt/gnuplot/lib.

The only two things that work are 1) adding /opt/gnuplot/lib to the library path via a script or 2) moving the libraries in /opt/gnuplot/lib to /opt/gnuplot.

So, I do have a solution that works but it is a compomise and accepting the compromise is hard to take.

Regards Phil

Posted by lucky13 on Sep. 10 2007,12:53
Another possible solution is offered in gnuplot faq #3.6: you can exclude libgd and save output as encapsulated postscript and convert separately (they suggest ghostscript, but imagemagick also converts ps to whatever image format you want).
< http://www.gnuplot.info/faq/faq.html#SECTION00056000000000000000 >

Posted by ^thehatsrule^ on Sep. 11 2007,16:47
It's not really a compromise to write a wrapper script -- many of the things used in a system are launched from another process.

I wonder why #2 works though...

For some configuration of apps, I've used `./configure --with-libs-from=<insert path(s)> ...` to hardcode the lib search path in the executable.  I'm not sure if this is similar to other flags?  It can be hard to understand so many options.  Essentially this will pass something like -Wl,"-R :<insert path(s)>:/usr/local/lib" to gcc.

edit: here's a snippet that might be helpful...
Quote
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use `-LLIBDIR'
flag during linking and do at least one of the following:
  - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
    during execution
  - add LIBDIR to the `LD_RUN_PATH' environment variable
    during linking
  - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
  - have your system administrator add LIBDIR to `/etc/ld.so.conf'

Posted by mikshaw on Sep. 11 2007,17:57
Quote
  - add LIBDIR to the `LD_RUN_PATH' environment variable during linking
 - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
hey now...that looks like a handy piece of info. I'm definitely going to need to try that next time I compile a uci

Posted by b1ackmai1er on Sep. 15 2007,17:44
Hi guys,

I have tried to convert my extension from a .tar.gz to a uci but the user.tar.gz section does not seem to work.

Is there anyway I can look into the uci to see what is inside it and the structure?

Thanks Phil

Posted by b1ackmai1er on Sep. 15 2007,18:51
I found the mistake I made.

Can I run a script automatically from the uci during installation to create my links in /opt/bin? If so what should the script be called and where do I put it?

Or do I have to include the link in the uci so it is automatically extracted to the correct directory.

Thanks Phil

Posted by mikshaw on Sep. 15 2007,19:29
You can't run a script during installation. Adding /opt/bin/mylink to user.tar.gz should be sufficient. A symlink is essentially only as large as the number of characters in its filename, so it won't affect the size of your package.
Posted by b1ackmai1er on Sep. 16 2007,10:56
Thanks, that is exactly what I needed to know

cheers Phil

Posted by b1ackmai1er on Sep. 16 2007,14:12
Guys, I can't work out the directory structure to I need to set up before I create the compressed uci filesystem

In /home/dsl/work/ I have

opt/gnuplot/bin ... lib etc (the main app and subdirectories)
opt/bin/gnuplot  (link to main executable)
opt/user.tar.gz (icon and menu command)

so in /home/dsl/opt/ I type

mkisofs -R -hide-rr-moved -cache-inodes -pad ./|create_compressed_fs - 65536 > ../gnuplot.uci

When loaded the icon appears on the desktop but the /opt directory structure is not right.

instead of /opt/gnuplot/bin etc I get /opt/gnuplot/gnuplot/bin

The other issue is that the user.tar.gz  appears in /opt/gnuplot/ and I am not sure this is supposed to.

Thanks again. Phil

Posted by mikshaw on Sep. 16 2007,14:47
try "-pad gnuplot" rather than "-pad ./"

Quote
The other issue is that the user.tar.gz  appears in /opt/gnuplot/
This is correct. When a uci is mounted, the user.tar.gz file is then opened from /opt/gnuplot as a tar.gz mydsl extension.

You should move this file to /home/dsl/opt/gnuplot before creating the extension.

Posted by b1ackmai1er on Sep. 16 2007,14:50
Ok, I tried it this way:

In /home/dsl/work I put

bin/ lib/ libexec/ share/ (all the application directories)
user.tar.gz (icon and menu link)
gnuplot (link to application executable)

With the same command this creates the /opt/gnuplot directory all correctly but does not put the application link /opt/bin

Ahh, maybe I should put that link in user.tar.gz

cheers phil

Posted by b1ackmai1er on Sep. 16 2007,15:30
Hi mickshaw, thanks for the reply.

The last method I tried beore your reply worked. Everything is where it is supposed to be, the icon and menu item work and the application is found from anywhere via the path.

I'm not sure that the application link is supposed to be in user.tar.gz but it seems to work.

Thanks for suggestion.

Regards phil

Posted by ^thehatsrule^ on Sep. 16 2007,17:02
Quote
I'm not sure that the application link is supposed to be in user.tar.gz but it seems to work.
Yes, the .lnk goes in there.  Good job on your extension :)

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.