Cross-platform support?



  • So, thought I'd be all fancy and set up a simple cross-platform project example. I tested QT first and found that, yes, it is possible to hate something so much your blood boils. So, since there was lots of smoke and mirrors in the IDE I thought I'd try GTK+, whose examples all come with Makefiles and work how I'd expect.

    Compile step is fine, then linking...

    main.c:(.text+0x11): undefined reference to `g_application_get_type'
    main.c:(.text+0x24): undefined reference to `g_type_check_instance_cast'
    main.c:(.text+0x35): undefined reference to `g_application_run'
    ... [moar linking errors]
    

    So, my linker can't find GTK, which Ubuntu presumably uses... I mean, GIMP starts, and it uses GTK, right?

    Either way, go cross-platform support. Apparently the platform I'm on doesn't even work. More after I update some libraries and reboot. Maybe I'm committing some kind of noob mistake and I'm just not seeing it. Even so, this seems pretty ridiculous to not be able to compile example code out of the box.

    [EDIT]

    Bonus WTF: this thread is not the fourth result in Google for "undefined reference to g_application_run". head->desk

    [EDIT 2]

    Closed as solved. The Makefiles in the GTK repo are broken; the linker flags have to be at the end of the command for whatever reason. Funny enough, either removing their manual recipe for the target or moving the flags to the end of the command fixed this, since apparently make is smarter than me and invokes the correct command.

    IE,

    $(CC) -o $(@F) $(LIBS) $(OBJS)
    

    to

    $(CC) -o $(@F) $(OBJS) $(LIBS)
    

    Was the fix for this. Maybe LD is the real WTF...



  • I don't know anything about GTK, but just because GIMP starts doesn't mean you can necessarily compile a GTK program without installing the development libs. You also may be using a different version than GIMP.

    I just got an example GTK app to compile after installing "libgtk-3-dev". I think it's the same package name on Ubuntu.



  • I have all the dev packages. They compile just fine; they do not link.

    A single-file example program works. Also, I have all the dev packages installed... unless there's one I'm missing that mysteriously is required to link properly. So far, I'm having plenty of fun trying to figure out what my linker isn't seeing, since the typical strategy with gtk is to pass whatever nonsense pgk-config prints out to the compiler and the linker. Oddly, I get the same errors in the linker when I pass none of that.

    gcc -W -Wall -o exampleapp main.o exampleapp.o exampleappwin.o
    

    and

    gcc -W -Wall -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12  -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0   -o exampleapp main.o exampleapp.o exampleappwin.o
    

    Both give me the same linker errors. Perhaps I've been working on web dev for too long, but this is baffling to me at the moment.



  • @VaelynPhi said:

    Closed as solved. The Makefiles in the GTK repo are broken; the linker flags have to be at the end of the command for whatever reason.

    Somehow I'm not totally surpised that GTK doesn't know how to Makefile.


  • :belt_onion:

    @VaelynPhi said:

    I tested QT first and found that, yes, it is possible to hate something so much your blood boils.

    Well, that's the first time I heard that reaction to Qt. I usually heard that about, ironically enough, GTK.

    If you'd spare a minute to satisfy my curiosity, what pissed you off that badly?



  • @VaelynPhi said:

    the linker flags have to be at the end of the command for whatever reason.

    The linker doesn't actually link anything from the lib unless something has asked for it. Since all the .o files were after the libs, the linker processes the libs, said "No, don't need anything from there," and moved on. The correct way, as you discovered, is to process the .o files first, which leave a bunch of dangling references for the linker to resolve using the libs.



  • @VaelynPhi said:

    simple cross-platform project

    I found TRWTF!


  • Discourse touched me in a no-no place

    @VaelynPhi said:

    Maybe LD is the real WTF...

    It is indeed, but it has a (minor) advantage that at least it is a predictable WTF and one that can be (and has often been) exploited to the programmer's advantage (e.g., partial overrides of what library provides what functions).

    Be aware that the order of the LIBS is going to be significant too. You typically need a partial order so that libraries only depend on libraries that come after them…



  • You have a hard time compiling GTK on Ubuntu? Shirley you've never tried to compile it on Windows.



  • There's a workaround by using the -( and -) linker arguments, which instruct the linker to iterate over the libraries (and maybe object files too) in between those two arguments until no new symbols are being added.



  • Compilers and linkers suck.


  • Discourse touched me in a no-no place

    @cvi said:

    There's a workaround by using the -( and -) linker arguments, which instruct the linker to iterate over the libraries (and maybe object files too) in between those two arguments until no new symbols are being added.

    That's not portable; it's a GNUism.



  • @dkf said:

    That's not portable; it's a GNUism.

    Is there some other implementation of ld than GNU ld?



  • OSX's dyld.o ( :grinning: ) , or Windows' link.exe?

    <!--(fun fact, the default Make toolchain on Windows SUA has a `cc` that just translates flags for MSVC's `cl`, and it works fine!)-->


  • @TwelveBaud said:

    OSX's dyld.o

    Isn't it for dynamic linkage? I.e., something very different from what ld is for?

    @TwelveBaud said:

    Windows's link.exe

    link.exe isn't ld, just like Gimp isn't Photoshop.



  • @Gaska said:

    Windows's
    Fun fact: My elementary school had a policy that any paper with the construction "s's" automatically received no credit.@Gaska said:
    Isn't it for dynamic linkage? I.e., something very different from what ld is for?
    Fun fact: It usually acts as the dynamic linker, but it's possible to invoke it in such a way that static linking is possible. I don't know how, not having developed on OSX, but my college roommate showed me one time.@Gaska said:
    link.exe isn't ld, just like Gimp isn't Photoshop.
    Just like Interix cc just calls MSVC cl, Interix ld just calls MSVC link, and all it does is massage the argument list a little. And technically it doesn't even have to do that.



  • @TwelveBaud said:

    Fun fact: My elementary school had a policy that any paper with the construction "s's" automatically received no credit.

    Fun fact: my elementary school English teacher didn't know the word "its". She also insisted on pronouncing the name Lucy as "lucky".

    @TwelveBaud said:

    Fun fact: It usually acts as the dynamic linker, but it's possible to invoke it in such a way that static linking is possible. I don't know how, not having developed on OSX, but my college roommate showed me one time.

    Still, it's not ld.

    @TwelveBaud said:

    Just like Interix cc just calls MSVC cl, Interix ld just calls MSVC link, and all it does is massage the argument list a little. And technically it doesn't even have to do that.

    If I made a Gimp skin that mimics Photoshop interface and has 90% of Photoshop's features, would the remaining 10% be non-standard extensions (a.k.a. "Adobe-isms")?


  • BINNED

    @Gaska said:

    She also insisted on pronouncing the name Lucy as "lucky"

    I had a lecturer at University who pronounced "Angle" as "Angel". Wouldn't have been too bad but he taught the module on vectors, where there was a lot of talk of the angel between two vectors and such



  • @Gaska said:

    link.exe isn't ld, just like Gimp isn't Photoshop.

    I'd rather have GNU ld than the MS linker for most things.

    There's also gold, but that should support the GNU ld command line syntax...



  • DON'T GO OFF TOPIC THIS ISN'T THE PLACE FOR ANOTHER FUCKING LINUX FLAMEWAR ARRRRRGH #blakey #thanksobama #yolo


  • area_deu

    But this isn't meta discussion!

    Also, shouldn't linkers and compilers be dead - at least for application software - according to him since managed code can do everything better?



  • But who manages managed code of managed code managers?



  • You can stop with your one-true-Scotsmanlinker pedantry. No, there is no ld besides GNU ld. But there are other linkers besides GNU ld, almost all of which take most of the same arguments; even pretty-little-princess MSVC supports most of the same settings even if they have different names. Microsoft even ships a program to do that translation, so you don't even need to touch your makefile.

    Bottom line, it is possible to change out which binary is actually doing the linking and have it Just Work, no matter which linker you use or OS you're on, and cvi's suggestion breaks that.



  • Except that link.exe doesn't care about the order(*), though. So a link.exe command line might not be compatible with the GNU ld, because linking will fail due to unresolved symbols because of a bad library order.

    (*) Unless there are duplicate symbols.


  • Discourse touched me in a no-no place

    @TwelveBaud said:

    No, there is no ld besides GNU ld.

    Old versions of BSD called and asked what they were using.



  • @TwelveBaud said:

    You can stop with your one-true-Scotsmanlinker pedantry.

    Never said anything like that.

    @TwelveBaud said:

    No, there is no ld besides GNU ld.

    Wow, thanks Captain Obvious! What other wisdom will you bestow upon us? That Windows programs can run on Windows?

    @TwelveBaud said:

    But there are other linkers besides GNU ld

    Yep. For example, FPC has its own linker integrated into compiler. But it's not called ld.

    @TwelveBaud said:

    almost all of which take most of the same arguments; even pretty-little-princess MSVC supports most of the same settings even if they have different names.

    If they have different names, they're by definition different arguments.

    @TwelveBaud said:

    Microsoft even ships a program to do that translation, so you don't even need to touch your makefile.

    And that program isn't ld. It just has command ld for compatibility.

    Look, all I was arguing about is that it's wrong to call any linker "ld", because "ld" isn't an abbreviation of "linker", but a specific program that's called ld and is a linker. There are other linkers - just like there are other compilers, other languages, other calendars, other cuisines. But only GNU ld is named ld. Get it?

    @cvi said:

    Except that link.exe doesn't care about the order(*), though. So a link.exe command line might not be compatible with the GNU ld, because linking will fail due to unresolved symbols because of a bad library order.

    QFT


    @FrostCat said:

    Old versions of BSD called and asked what they were using.

    Oh, turns out I was wrong. But don't blame me; I was born in 90s and old ld has terrible googleability (even the manpage says "GNU Linker"!) Still, link.exe isn't ld.


  • Discourse touched me in a no-no place

    @Gaska said:

    Still, link.exe isn't ld.

    True, but I didn't say it was so you should've attached that to someone else's quote. :smile:



  • If it makes you feel better, you can interpret it as general remark in topic we're discussing.


  • Discourse touched me in a no-no place

    @Gaska said:

    Is there some other implementation of ld than GNU ld?

    Yes. OSX's ld has BSD heritage; it can be considered to derive from a different inheritance line to the GNU one. It's also had quite a bit of tinkering done to it, but the key thing from discussion here is that it doesn't support -( and -) and never did.

    @TwelveBaud said:

    OSX's dyld.o

    That's something else. :facepalm:


  • :belt_onion:

    @TwelveBaud said:

    OSX's dyld.o

    Is it purple?



  • @Onyx said:

    Well, that's the first time I heard that reaction to Qt. I usually heard that about, ironically enough, GTK.

    If you'd spare a minute to satisfy my curiosity, what pissed you off that badly?

    Mostly the IDE. Also, the difficulty of finding documentation for someone who doesn't want to work in the IDE. Then, the difficulty of adding cross-compile support in the IDE. Their idea of cross-compile support seems to be, "Just copy it to Windows and compile there."

    @HardwareGeek said:

    The linker doesn't actually link anything from the lib unless something has asked for it. Since all the .o files were after the libs, the linker processes the libs, said "No, don't need anything from there," and moved on. The correct way, as you discovered, is to process the .o files first, which leave a bunch of dangling references for the linker to resolve using the libs.

    This is understandable, but a bit silly. I mean, perhaps there is some sophisticated technical reason for this, but wouldn't it make sense to build the symbol tables first, then search for them in the libraries regardless of the order those arguments are supplied to the linker on the command line?

    Of course, this still doesn't explain why GTK is releasing Makefiles that don't work because of something that almost everyone must know by this point.

    @Gaska said:

    You have a hard time compiling GTK on Ubuntu? Shirley you've never tried to compile it on Windows.

    Somewhat ironically, the exact same files compile just fine on Windows 8 with mingw. Maybe the GTK people are working in that environment... which would be the biggest WTF I've seen so far.

    @Jaloopa said:

    I had a lecturer at University who pronounced "Angle" as "Angel". Wouldn't have been too bad but he taught the module on vectors, where there was a lot of talk of the angel between two vectors and such

    The number of angels who can dance between two vectors is proportional to their curl...

    Funny you bring up MS, since the other option for the contract I'm starting is .NET, and that's looking better and better, even if it does mean ditching any notion of cross-compatibility.


  • Discourse touched me in a no-no place

    @VaelynPhi said:

    ouldn't it make sense to build the symbol tables first, then search for them in the libraries regardless of the order those arguments are supplied to the linker on the command line?

    The answer to that is likely to be a variation of "probably, but it would have been harder to implement 30 years ago due to memory constraints or something".



  • @VaelynPhi said:

    the other option for the contract I'm starting is .NET, and that's looking better and better, even if it does mean ditching any notion of cross-compatibility.
    System.Environment.Platform == PlatformID.Unix; //returns true



  • @VaelynPhi said:

    Mostly the IDE.

    But then you are happy trying GTK+ without one, because, well, it does not really have any. So go ahead and use Qt without their IDE too. It works fine with Eclipse or CodeBlocks or just VIM with youcompleteme.

    @VaelynPhi said:

    Their idea of cross-compile support seems to be, "Just copy it to Windows and compile there."

    I'd recommend using CMake like KDE does instead of the qmake kludge. CMake is mostly a kludge too, but it is more flexible and can be configured for cross-compilation. It's a bit of a hassle (you have to tell it some things it should be able to guess), but it works. In fact I'd recommend using it for GTK+ project too.

    The added benefit is it is natively understood by KDevelop4 and Qt Creator and can generate project files for CodeBlocks, CodeLite, Eclipse CDT, Sublime Text 2, Visual Studio on Windows and XCode on MacOS. And it can use the ninja builder; it's a lot faster than make.

    @VaelynPhi said:

    Also, the difficulty of finding documentation for someone who doesn't want to work in the IDE.

    There is a stand-alone documentation browser, the "Qt Assistant" or you can use the documentation on the web. Which is no worse than GTK+, it has the same two options.

    @VaelynPhi said:

    This is understandable, but a bit silly. I mean, perhaps there is some sophisticated technical reason for this, but wouldn't it make sense to build the symbol tables first, then search for them in the libraries regardless of the order those arguments are supplied to the linker on the command line?

    I'd say there is a historical reason. Back in the early days of Unix compilation and linking really stressed the computer, so both the compiler and the linker were designed to process things sequentially. And in the GNU ld it stuck. In a sense I actually like it; it forces programmers to actually think what depends on what.

    @VaelynPhi said:

    .NET, and that's looking better and better, even if it does mean ditching any notion of cross-compatibility.

    Mono is somewhat behind and lacks WPF, but some cross-compatibility is possible even then. In fact GNOME has some applications running on mono (but GTK+ UI; the basic WinForms are there too though, only WPF is not).



  • @TwelveBaud said:

    System.Environment.Platform == PlatformID.Unix; //returns true

    Technically, it evaluates as true, it doesn't return anything.



  • @chubertdev said:

    Technically, it evaluates as true, it doesn't return anything.

    In C++, it would.


  • Discourse touched me in a no-no place

    @Gaska said:

    In C++, it would.

    Only if you used a horrible #define. (The return keyword is absent; it's a fairly simple expression.)



  • Operator overloading anyone?


  • Discourse touched me in a no-no place

    @Gaska said:

    Operator overloading anyone?

    I don't think you can generate a return via overloading. I think that was a smart-ass trick too far even for Bjarne Stroustrop.



  • Pop quiz: what does abs(-2) return?


  • sockdevs

    assuming you have #included the standard math functions and not done an weird #defines

    it evaluates to the number 2



  • @VaelynPhi said:

    Maybe LD is the real WTF..

    Almost certainly ld is TRWTF.



  • @cvi said:

    There's a workaround by using the -( and -) linker arguments, which instruct the linker to iterate over the libraries (and maybe object files too) in between those two arguments until no new symbols are being added.

    Is that actually documented anywhere? I've been using gcc for decades and had always assumed that you needed to spam multiple instances of -lsamelibrary to get things to link in a satisfactory manner.

    This is worthy of further investigation when I get home...



  • @dkf said:

    That's not portable; it's a GNUism.

    #Awww :<sadnow>(



  • @Gaska said:

    Is there some other implementation of ld than GNU ld?

    LLVM/Clang has its own linker, doesn't it?



  • @FrostCat said:

    Old versions of BSD called and asked what they were using.

    ...because they went senile and forgot?



  • abs(-2)

    @accalia said:

    assuming you have #included the standard math functions and not done an weird #defines

    it evaluates to the number 2

    It'd return 2.0 (a 2 in double context), unless I am tripping my balls off.



  • @tar said:

    LLVM/Clang has its own linker, doesn't it?

    On my machine clang still uses the GNU one, but they are working on it: lld.

    @tar said:

    Is that actually documented anywhere? I've been using gcc for decades and had always assumed that you needed to spam multiple instances of -lsamelibrary to get things to link in a satisfactory manner.

    Should be in man ld. -(/-) are also aliased by --start-group and --end-group. If you invoke ld via gcc, you probably have to use something like -Wl,-( to pass the argument to the linker. You might have to escape the ( for your shell, so it becomes -Wl,-\( ... a thing of beauty. :-/


  • sockdevs

    ..... Shimata. you're right.

    i was close!


  • Discourse touched me in a no-no place

    @tar said:

    because they went senile and forgot?

    No, someone else upthread did, though.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.