Is the choice meaningful? Or just something you have to type out?
In the casting example, it's meaningful: there are several ways to "round" a float, each having different consequences. As a programmer, you have to make a choice driven by some business requirements, and encode it (preferably only once for a given business concept).
Sometimes, however, you can modify the source of the float - push the decision upstream, so that your code always gets an int the way you like. This is one way of reducing glue code, but it's not always available.
Anyway, a different type of glue code - I think the most common one, one I call "code bureaucracy" - is reconciling concepts between systems/modules. One system produces data that's almost, but not quite, like what the other system wants to consume. Sometimes it's literally the same data, but named as two separate concepts with separate ownership. This kind of glue code can grow in size rapidly as a consequence of following seemingly good design practices, and often feels pointlessly wasteful.
Imagine you're writing a 3D video game. You decide to use a library to load 3D models. You give it a data stream, and get back a list of (x, y, z) points. Unfortunately, despite containing exactly the same data, perhaps in exactly the same memory layout, that list of points is not a proper "list of points" as the rest of your game logic understands it. You're faced with 3 options:
1. Change your game to use library's format for representing 3D data. You're reluctant, because it would tie your system to the API of a third-party component. It would also be difficult if you used another library (perhaps for physics handling) that used its own "list of points" representation.
2. Change the library to use your game's format. Not the work you wanted to do, and the library author won't be interested in it anyway.
3. Write glue code to convert between the formats. Can be as simple as switching out typesystem labels, or as complex as translating each point in a loop.
For obvious reasons, everyone will choose option 3. What's curious is, though, that the reasons are more social than technological. You don't want 1. because it will make you dependent on a third-party system. That system's author won't accept 2., because it'll make them dependent on you. Hence, option 3.
The exact same thing happens internally, within subsystems developed by different people, and even with code of a single author, across abstraction boundaries. It's an ironic example of Conway's law: system design reflects social structures designers live in. After all, there is another option - one that is rarely thought about, one that's sometimes considered a violation of good design - one that's socially expensive:
4. Get together with the other system's author (and possibly with other users) and agree on a common representation you'll both use.
It breaks abstraction layers. It breaks ownership separation. It breaks responsibility division.
It also eliminates hell of a lot of glue code.