Got some bug reports but first...
Build 32-bit libs and apps on a 64-bit machine. Don't mess with
./configure. It'll likely get you nowhere.
_*This is for Linux.*_ I don't write spyware and I don't write apps
that run ON spyware.
*One of the nice features of fltk is the makeinclude file. It keeps all
the variables in one place. So this is going to be (relatively) quite
easy. Try it my way first, then vary it to your liking. Uninstalling
is as simple as deleting the folders and possibly deleting two paths
which we'll get to in a moment.
*
Here's a step-by-step I wrote as I actually did this just moments ago.
1. Create folders (at *least* the lib folder) under your home ~/usr32
folder.
*~/usr32
|-- bin
|-- include
|-- share
`-- src
*
2. run make
This is just to create initial configuration that can be modified. We
don't even care if it chokes as long as it creates the makefiles and
especially the file named 'makeinclude'.
3. Change flags in makeinclude... keep it static linked for now. The
-m32 flag compiles for a 32-bit machine, the -g3 is for debugging info
which can be stripped later... use -O2 if you don't want it.
* # flags for C++ compiler:
was #OPTIM = -O2 -Wall -Wunused
is OPTIM = -m32 -g3 -Wall -Wunused
*
*Be careful when using the tilde macro for your home directory.* You
NEED the space between the -L and the ~/ so the interpreter doesn't
think the tilde is an alpha character. Other than that... it's fairly
simple to add the new lib folder to the search paths.
* # libraries to link with:
add LDLIBS = -L ~/usr32/lib ...
add GLDLIBS = -L ~/usr32/lib ...
*
4. run 'make clean' and 'make' again.
At this point you should get some error messages about missing libs.
They may in fact be on your system but with an extension that LD can't
understand.
For example, the first missing 32-bit lib the linker complained about
in my case was:
* ld: skipping incompatible /usr/lib64/libGLU.a when searching for -lGLU
ld: cannot find -lGLU
*
We expect the extension is *.so.1* or .*so.1.2.xyz*, so we look for it
this way.
find /* -name libGLU.so* <--<< works but kinda overkill and harder
to use right.
Or maybe better yet, and certainly faster, iteratively insert '/*' in
the path until you get a hit.
* ls /lib/libGLU.so*
ls /*/lib/libGLU.so* <--<< mine hits here in less than a second.
ls /*/*/lib/libGLU.so*
*
So I got it. Here's what ls (and find) found.
* /usr/lib/libGLU.so.1.3
/usr/lib/libGLU.so.1
*
These are both the same file. The so.1 links to the so.1.3 and we
need a generic so with no extension.
5. Back at step 1, we created a lib folder. Link the allegedly missing
<libname>.so.<ext> as <libname>.so in the new ~/usr32/lib folder.
For example to link in my missing libGLU
* pushd ~/usr32/lib # changes dir and saves our
old place
ln -s /usr/lib/libGLU.so.1 ./libGLU.so
popd # return to where we're working
*
That was all it took to get mine up and running, but if you have more
32-bit libs that need to be renamed...
6. Repeat from step 4 until you know what they are and where they are.
There's a fair chance you won't have to download a thing, but if you do,
try to install them in the same !/usr32/lib folder and you can play with
it as much as you like without messing with the main system at all.. and
*NONE of this requires SUPER-USER privileges.*
Nice? :-)
Ok, but what have we got now. I have a static lib loaded with debug
info that I don't want to use. I want a dynamic/shared lib.
Step number 7 coming up. This is best done as a script so you can edit
it easily.
7. Go into the installation lib folder (not the ~/usr32/lib folder) and
create this script. It doesn't have to be executable. We'll run it
with bash manually.
file: mk-dso ------->
* # a subroutine to handle the nuts and bolts.
mk_dso() # base_name
{
LIBNAME=`basename $1 .a` # remove the file extension for the name
rm -rf tmp # make sure we start clean
mkdir tmp # make a new one
cd tmp # go there
ar -x ../$LIBNAME.a # explodes the lib into all the object files
# this line compiles it all to a shared library in the lib folder above.
g++ -m32 --shared -fPIC -o ../$LIBNAME.so *.o
cd .. # go back up a dir.
cd lib 2>/dev/null # this should fail, but we need to be in 'a' lib
rm -r tmp # cleanup
}
mk_dso libfltk2.a
mk_dso libfltk2_gl.a
mk_dso libfltk2_glut.a
mk_dso libfltk2_images.a
* <-----------
This file can be run from the commandline as 'sh mk-dso'
Initially you may want to add some 'read key' commands to stop every
once in a while to make sure it's doing what you expect since bash can
be very precise even when we aren't. ;-)
When you're finished you'll have four dso's named...
*> ls *.so
libfltk2_gl.so libfltk2_glut.so libfltk2_images.so libfltk2.so
*
They are usable, but they aren't yet known to your linker.
8. Move the dso's (the shared libs you just built) into your ~usr32/lib
folder and add the following to your .profile file or to .bash.rc so
that when you log back in the paths will be set up.
* export LD_LIBRARY_PATH="$HOME/usr32/lib":$LD_LIBRARY_PATH
export PATH=.:$HOME/usr32/bin:$PATH
*
The dot+colon at the start of the PATH export (see above) allows you to
run apps in the current folder without the dot+slash. Remove it if you
prefer global-ism. ;-)
9. Move other required files too!
a. fluid goes in ~/usr32/bin
b. COPY don't move, fltk/include to ~/usr32/include (If you remove
them from their original location, the debugger can't find them.)
c. If you want to use the fltk2-config file which is likely to be
useful when working with other folks stuff, copy that to the ~/usr32/bin
folder as well, then
1. edit it to change all the lib names from *.a to *.so
2. change all the /usr/local paths to ~/usr32
10. Ready to test?
Log back in and see if it works.
Anywhere in your folders, using the commandline or the Run dialog,
type fluid2
It should launch fluid. If it doesn't your paths may not be getting
set right.
Go into a folder and create a ui with fluid.
Finishing touches?
Move the docs to ~/usr32/share
Anything else you think you need should end up somewhere in there
too... would be my guess. ;-)
Actually, those paths might be possible to set up in the makeinclude
file and installed by 'make install' but I'm not going to get into that
myself.
I really only wanted to show how easy it is to get this stuff to compile
for 32-bits on a 64-bit brain-dead system so that the code might be
usable on a stack-based system such as Forth. I could have stopped at
around step 2...
:-)
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
