I'm in the processes of building tilp2 for puppy and I need to compile a bunch of dependencies: libticonv, libtifiles, libticables, and libticalcs. Rather than build one, create a pet, install the pet, ...etc then go back and combine everything into one big pet, I would rather just build everything, combine everything into one directory and run dir2pet. The problem is I don't know how to link the dependencies without installing each one and using pkg-config. For example, I built libticonv ok because it didn't depend on any other tilibs. I used 'new2dir make install' and it created a directory libticonv-1.1 with all the files. I then started on libtifiles but it depends on libticonv. Since I did not install ticonv I don't know how to show make where the files are. The configure --help shows

I use a throw away save file so I can install the needed things to build. Then when I'm done making the pets, I test them on a clean save. It's a lot less of a headache then trying to get configure to find things in nonstandard locations.

Also when I'm building, I just use regular make install, because sometimes the new2dir script screws up. It's easier to find the problem when you know your program worked before you ran the packaging scripts on it.

Hmmm, that sounds like a good idea, I will give it a try. Sometimes I fail to realize that I can do stuff like that with puppy. Although I am still curious how to do it with the configure script in case I'm in a similar situation on a non puppy machine.

So do you create the pet without the new2dir script? Or do you use make install to test the program, then go back and use new2dir?

or better yet, since all of those libs are highly unlikely to be used by anything else, they should probably be compiled statically (then you won't have to combine all of the libs)
the common ./configure options are:
--enable-static --disable-shared --without-pic

(granted not all libs have a capable configure script)

(here is what I used as a first run for all libs and the binary -- if it fails I start eliminating flags starting with *sections)
CFLAGS=" -pipe -combine -Os -momit-leaf-frame-pointer -fomit-frame-pointer -ffunction-sections -fdata-sections -fmerge-all-constants -mpreferred-stack-boundary=2 -march=i386 -mtune=i686 " LDFLAGS=" -Wl,-O4,-Os,-relax,--sort-common,--gc-sections,-s " ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-t2-linux-gnu --enable-static --disable-shared --without-pic

otherlibs.png

Description

note that no libti* appear since they are statically linkedalso shows what others you may need (all are in 431)

Thanks technosaurus! I gave it a quick try with my ti8-83+ and it seemed to connect fine but the gui didn't respond when I tried to browse files, dump rom, etc. The terminal output had a bunch of glade glib warnings. I will try your instructions later when I get home and see if I can get it to work.

Just out of curiosity, why do you use -march=i386 -mtune=i686? I used -mtune=generic in the past bc I thought mtune implied march.

That is a common problem with glade and optimization if precautions are not taken within the code. Since the code is not used within the binary (it is called via glade) it gets eliminated by the linker as unused code. There is a flag (or flags) that you can pass to prevent that behaviour, but I can't remember (something allong the lines of -fno-*dce or -fno-*dse ??); however, since it negates a lot of optimization anyways, removing the -Os and the *sections flags should fix it and yield similar results. The alternative would be to patch that portion of code so that it isn't eliminated (probably too much work unless you want to be the new maintainer)

-march=i386 uses only 386 instructions which allows the compiler to find more patterns and generally produces smaller code that will work on more machines

-mtune=i686 will just format it to load better on 686 systems (assumes larger stack,register,cache...) but it will still run on older systems_________________Check out my github repositories. I may eventually get around to updating my blogspot.

big_bass: Thanks for the link, I already have tilp installed so I didn't try it yet. The next time I need to build something I will go there first though (most likely grass GIS). It seems like it would be way easier. I wonder how hard it would be to build a 'Master script' that could download all of the components, run the **.SlackBuild script, new2dir, and then dir2pet?

most common reason for me is a typo, usually --enable-static--disable-shared (missing a space between tags)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

I still gave it another shot anyway building without kde and static
just so you know there are several ways to solve the same problem
depending on who you ask

I normally don't build static but for this type of small app with many required libs it ok to do so

I made a desktop
and icon that is displayed in the menu
also its all combined in to one package with docs for each package
I also made a slack-desc so its an official package
there is also an install script that makes the symlinks for you all combined

even though I spent much time trying to build puppy packages from source using scripts if you search back a few years starting with getting src2pkg working on puppy 3.01 there has not been much interest from developers... so I now build all my packages from source
as slackware compatible packages this way
anyone that does use linux could easily adjust the package to work
for their version

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum