Thread: Do I really need to recompile ORBit2?

Issue history.

As I have found Valgrind far more useful in debugging than GDB, I looked for a way to reconcile them. The first thing I thought of was that a huge suppression file could resolve the readability issue. Google led me to http://live.gnome.org/Valgrind, which advises recompiling ORBit2 with the --enable-purify option (and only has an Edgy Eft suppression file which seems ineffective).

I'm just wondering if all GTK objects require this library; if not, do I really need to recompile? I'm not just asking because it's an inconvenience; I'd rather not work with the lower levels of my system until I can reinstall Ubuntu, because that kind of activity seems to trigger more system decay.

Thanks!

You should have at least two (two is enough) linux installs on your hard disk if you're programming; that way you can screw around with one and still have one to fall back on (plus, one can be repaired from the other). I say this because you ABSOLUTELY MUST get over your fear of building system essentials from source, albeit this fear is completely justified if you haven't done it much yet, which is why I recommend you have one system to experiment with and another one you don't (or you could alternate, so that once you are satisfied everything is fine, you do the same thing on the other side). I have one system (which I prefer) that is all hacked up and much built from source, and then because I'm writing software that's distributed, I have a stock, straight-off the dvd distribution as well to test things on. This is also good for catching memory segmentation problems, which sometimes do not show up until compiled on a third system! Since I don't have a forth, who knows what slipped by the first three...actually I occasionally hear rumours

Anyway, recompiling orbit should be no big deal. Here's a couple of things to take into account:

• build it first in /usr/local and run make check/test, but don't install it.
• drop out of X and into single user console mode (runlevel 3) since orbit involves internal networking upon which X depends. Then uninstall the orbit binaries you are replacing, that came with your distro. The packager (rpm or apt or whatever) will complain that you can't do that because other stuff needs orbit, but don't worry. In the future, it will also complain when you try to install a package that needs orbit, because you don't have the distro binary package installed, so you have to use some "force" option. But it is important to remove the old one, to ensure that your /usr/local version gets used (and it's much better to keep source built stuff in /usr/local than to try overwriting /usr).
• you are right to worry in so far as orbit may be configured in some particular way on your distro and your new version may be incompatible, however, it is easy to reverse the process; just leave the build directory intact and you can "make uninstall" (if you erase the build dir, you can also untar the source, re "make" and then "make uninstall" which if said source was previously installed, that will remove it). Then you just reinstall the distro packages.
• once the make is done and the distro binaries removed, "make install". VERY IMPORTANT: run "ldconfig". If you have not built any libraries (such as orbit) in /usr/local before, make sure /etc/ld.so.conf (or one of the /etc subdirs referenced by it) contains a reference to /usr/local/lib. Read the ldconfig manpage if you don't know what it does (it is run by your package manager automatically if you install a disto pack, but usually not by source compile installs).
• maybe reboot. I'm not sure if orbit has stuff controlled by init, hopefully that is taken care by the install but you may have to add something to an .rc script. Probably not.

I highly recommend learning to use "mc" or some file browser that works outside of the GUI (I actually prefer it in the GUI too), altho with most source builds you don't need to exit it. That's a lot to swallow, but again, you ABSOLUTELY MUST be competant with all this if you want to program for linux. There is no way around it. Leave your gtk project aside for a while and get dirty. I'll probably be here most of the afternoon if you need/want more advice from a kook, but like I said, I'm sure recompiling orbit is no big deal and should be painless.

Another great way to learn and get comfortable is to try "Linux From Scratch"; building bootable floppies was great too but harder now and most computers don't even have a 3.5"

ps. the absolute worst thing I have ever done was destroy the GNU C library itself, which left the system totally scrapped, but it was still easy to salvage data from the filesystem -- providing you have another linux system from which to do that.

I don't currently have any writable CDs available or I would have already reinstalled Ubuntu to reverse the decay I mentioned. Should I use the Ubuntu 7.10 CD I still have from my first install?

I'll ask a lot more questions once I have that second Linux installed.

EDIT: And the reconciliation I mention in the first post is between GTK+ and Valgrind... I obviously didn't proofread enough.

You might as well use the same disto twice if that's what you have at hand and are comfortable with, I guess. There is always something to glean by contrasting two similar but different things (eg, programming languagues), the question is how much difference you are willing to deal with. Just make sure you can boot into both of them, and mount one from the other. Eventually you may want to look at chroot, which will allow you to mount the other filesystem and run commands inside that from it's own tree.

I forgot to mention before that you can easily pthread gtk's main loop (ie., "gtk_init" does not actually have to be in main(). I say "easily" because that is the only thing I have used pthreads for and it required about four lines of code, eg.

Code:

in main:
        pthread_t gtk;
        if (pthread_create(&gtk,NULL,gtkloop,(void*)titles[0])) puts("ERROR");
        pthread_detach(gtk);

then somewhere:

void *gtkloop (void *title) {
        GtkWidget *window, *frame[2], *vbox[2], *hbox[1], *info, *slide[4], *speed, *follow;
        printf("gtkloop()...\n");
        
        gtk_init(NULL,NULL);

        window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
...etc.

which might be a possibility if you want a CLI that uses an extiguishable gtk process, and you have already used pthreads. In truth tho, I have not done this much, so there may be complications I have yet to face.

I was also just glancing back at your last thread. Admittedly, it is not clear to me what you're doing and I'm only posing as a guru, but

Code:

if(o != (struct outline *)NULL)
		o->free(o);

You do realize that you don't need to free things at the very end of a program, right? The OS cleans up everything when the execution is finished (free is for preventing leaks while the program is still running).

Originally Posted by Jesdisciple

OK, just to make sure... I don't need to back up my data before mounting a second Linux, right?

If you've got it all installed now, you can boot one without affecting the other. To mount the other one, create a mount point and use something like "mount -v -t ext3 /dev/hda1 /mnt/other". You can now access the other filesystem through the mount point (you can add a line to /etc/fstab too*). I guess a good idea at that point would be to copy all your crucial stuff into the new partition. Again, don't worry too much, there is no risk of filesystem corruption in all this, the risk is that one system won't run properly after you tinker with it, so you just want to make sure:

1. at least one system can be booted in good working order
2. you know how to mount and access the other filesystem (easy)

I've never used Ubuntu but apparently it uses grub, so it should have modified your menu.lst properly. If not, you might end up only having one boot option, which is just a hassle you can fix (unless you were REALLY dumb and installed fresh onto the old partition). Sometimes the disk partition tool on the install CD's can get confusing because of Logical Volume Management, which most people don't need on their home desktop but get subject to anyway.

If worst comes to worst and nothing boots, don't panic and figure you have to reinstall and cannot save anything! There are options even then...the Ubuntu bootable CD almost certainly has a rescue mode where you can get a command line and use bash + things like mkdir and mount (you can mount a non-functional windows partition under linux, b.t.w, which it is a shame you didn't know that before, you probably could not have repaired it**, but you could have gotten your stuff off).

ps. get yourself a cheap 1-2 gig USB key and format it ext2 for backing up important stuff independent of the box! I think they are about $5 now.

*in which case use "noauto" to prevent Ubuntu from always mounting the other partition.
**it was not actually damaged, to be sure, it's just you overwrote the boot sector; grub sometimes needs help w/ windows

Originally Posted by Jesdisciple

But isn't gtk_init supposed to receive the arguments passed to main?

It doesn't have to:

Code:

gtk_init(NULL,NULL);

also, you can pass them around:

Code:

#include <stdio.h>

void func (int argc, char **argv) {
        int i;
        for (i=0; i<argc; i++) {
                printf("%s\n",argv[i]);
        }
}


int main (int argc, char *argv[]) {
        func(argc, argv);
        return 0;
}

I'm at least glad you're back! I was fearing the worst!

Like I said, I haven't used Ubuntu, so I can't say for sure that the live CD has a rescue mode -- you shouldn't need it anyway, it's a last resort.

So, does this mean that you did another install, or no?

Hmmm...no, the grub on your hard drive will not boot the CD (??hard to tell what you mean). You need to boot directly from the CD, which means switching the boot device in your BIOS -- I presume you know that.

If you are booting the CD, and you say it checked the drives and then "nothing unusual happened", where are you then?

Lemme just make sure we're on the same page: is there room on your hard drive for another partition?

Cancel that! I was entering the wrong setup program... I needed to push F2 for BIOS a little before I was pushing Esc for GRUB.

Alright, I chose manual partitioning, and I think my existing partition needs to be smaller: 19.1 GB (17900 MB) used, 51.4 GB (59047 MB) free. Interestingly, those figures seem incorrect if 1 GB = 1024 MB...

Anyway, I don't see how I can make a new partition... EDIT: Oh, I was in the installer not the partition editor.

Originally Posted by Jesdisciple

Anyway, I don't see how I can make a new partition...

The way I do it, to avoid idiosyncrasies in the CD installer software, is to use fdisk from within your existing installation. fdisk is CLI and fairly straightforward; you start it

Code:

fdisk /dev/hda

notice this is not "hda1", it's the whole physical disk. Press "m" to see the options menu and relax, you can create a whole "partition table" but fdisk won't commit anything until you choose "w" and confirm. The first thing you want to do is look at what already is ("p"). Then you create (again, it's not commited) "n"; you want a primary partition, presumably number 2 if there is 1 already*, altho you probably have a swap too so maybe 3 (you should have already seen everything with the first "p"). You pick the default first cylinder (just hit enter), then decide how big it should be (eg, "+20G"). Then you can look at the new proposed table with "p" (for print table to console). Probably the new partition will automatically be type 83 (Linux); if not use "t" to change the appropriate partition type. After that, you can just hit "w" to commit and exit or "q" to cop out.

DO NOT RESIZE OR MODIFY THE LISTING FOR YOUR EXISTING PARTITION!!!

You don't need to format anything any further, that will get done by the install. Now just use the boot CD again, and it will give you a choice of partitions to install into. If it ends up being not big enough or something, you can go back and delete and recreate with fdisk again; as long as there is nothing on the new partition you care about, obviously, since deleting/resizing/creating a partition is guaranteed to destroy the filesystem ON THAT PARTITION ONLY.


*hey! the windows partition you thought you lost might still be there...

Originally Posted by MK27

The way I do it, to avoid idiosyncrasies in the CD installer software, is to use fdisk from within your existing installation. fdisk is CLI and fairly straightforward; you start it

Code:

fdisk /dev/hda

I tried that and it said it couldn't open it; then I noticed that GParted had opened /dev/sda but that got the same result. But I was still on the Live CD and realized you wanted me back in the old install. It failed there too until I used sudo.

Originally Posted by MK27

DO NOT RESIZE OR MODIFY THE LISTING FOR YOUR EXISTING PARTITION!!!

I read a similar message at Ubuntu's how-to, but I didn't think I had room for anything more. And I got my suspicions confirmed by fdisk...

Code:

Command (m for help): p

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf404143b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        9355    75144006   83  Linux
/dev/sda2            9356        9729     3004155    5  Extended
/dev/sda5            9356        9729     3004123+  82  Linux swap / Solaris

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
p
Partition number (1-4): 4
No free sectors available

Originally Posted by MK27

*hey! the windows partition you thought you lost might still be there...

Nah... I think I resized it and that's where the problem came from, but either way I overwrote the whole drive with the current install.

Maybe time for a new hard drive! You could fit two installs on there (I dunno how much Ubuntu wants, probably at least 20-30 G), but that means resizing, and I can't give you any advice on that one. Or saving your critical stuff and reformatting the whole thing. In any case nothing you can do right now.

w/r/t ORBit, you can still try what I first advised anyway. The problem will be that working in console mode can be awkward if you are dependent on the GUI, so before you try it make sure you are comfortable with the command-line tools you need to use -- especially the package installer, which I think for Ubuntu is probably "apt". As long as you can uninstall and install the ORBit package that's on that CD in console mode, it's all good. That means mounting the CD with mount, finding the package with cd and ls, and then using apt. Like I said initially, you really have no choice -- sooner or later you will have to get comfortable with it. Really, the truth is that if this is a recommendation from GNOME, you are unlikely to break GNOME by doing it (but never say never!).

And, finally, I gotta say, In My Personal Opinion, you don't need to be sweating it out with valgrind and gdb so much, esp. with the gtk. There are no serious problems that you can't solve yourself** with a few well placed "printf's", and your awareness of memory issues etc. will develop as you gain experience programming. As long as you are aware of the issues, don't get excessive with the perfectionism. A bad program is just a bad program; it won't hurt you, your computer, your system, or cause the shuttle to crash. Sometimes you can leap as you look, fly by the seat of your pants, etc, see?

I'd been using linux for years before I started taking programming seriously*. That's a lot to tackle all at once, but do be sure to keep putting some time in getting to understand the OS on a raw level (like get some harddrive space to safely screw around in). Back your stuff up and don't be afraid to fail or else the Operating System will just become more and more of an "untouchable" to you. Which if you are programming a computer, that's gonna be real sad. Hack!

*I'm sure it was easier back then too, because in the "early days" linux was much much less user-friendly, meaning you really had to learn tish because there were no simple interfaces. Just booting straight into the GUI is actually a development (I still prefer not to). Sink or swim!
**and there's plenty that neither valgrind nor gdb will help with anyway