I probably don't know enough about the event system to comment on your suggestion though I feel that there is likely an easier way.
With callbacks the simple method is to use global variables. A global variable can be accessed from anywhere. Global variables are more efficient but have the downside of overuse making code disorganised, difficult to maintain and those who read it call down curses on you and all your ancestry. For an example see one of my repositories.
Of course if taking the global variable approach you don't want 20 functions to work on box1-box20 when they do exactly the same thing; having a generalised function and box variable is much better.
For people that like neat well organised code, the passing a structure approach you mention is excellent. You do however, present a good problem with dealing with widgets outside the normal structure groupings.
In answering, I must ask:
How is this label in a different structure determined? It's obviously not any label but a praticular one. As such there must be a logical way of representing how the labels structure is related to the entry's structure. This relationship will define a natural structuring of your structures which can then be passed to the function (though you can only pass one pointer, you can pass a pointer to an array of pointers which is what you are doing with your structure, this just takes it one step further in terms of structures of structures).
An examples to come down from the abstraction: lets say you wanted to make a program to input someone's geneology. After putting a name into an entry, the next two entry's labels should say [name's] mother and [name's] father and so on. In this case structures grouping the entry and its assciated widgets could be organised in a tree hierarchy (don't know if glib actually has a data type for this one, but can be indexed in an array -- e.g. represent mothers fathers mother => MFM => x=010 [0s for Ms and 1s for Fs] then the index is [2^#digits]-1+binary value of x). You can then pass a pointer to this hierarchy and the widget that triggered the event/signal will index where in this hierarchy to work from. Ok I've gone rambling and you're unlikely to have this being the case, it's just to show that you can make a data model for virtually any situation.
Of course if there's only a few instances where you want more than one parameter you can just pass a pointer to an array that you've created just for that callback.
If you let us know more about how your GUI is set up and what buttons are used for editing which labels (andaccording to which entries) we might be able to give better direction.
There is really no standardisation as to the paradigm in which you program; some of course perform better than others, but if your code is error free I hardly see how anyone would label you as stupid.
By the way you should be setting up atk relationships for all labels and what they label e.g.:
atk_object_add_relationship(atk_label, ATK_RELATION_LABEL_FOR, atk_widget);
atk_object_add_relationship(atk_widget, ATK_RELATION_LABELLED_BY, atk_label);
so that assitive technology knows how things are related (I'm a little pissed off that this never gets mentioned in the official GTK tutorials). In this case you have no need for the structure you had originally set up as your callback could delve into atk to determine the label for any given entry or vice versa.